Gitless: an experimental version control system built on top of Git

http://people.csail.mit.edu/sperezde/gitless/

by rrrrtttt • 13 years ago

67 46 13 years ago

people.csail.mit.edu

dominotw• 13 years ago

I don't understand what it is supposed to do.

Check out the documentation section to get started.
Documentation: TODO.

skrebbel2• 13 years ago

There must be a dead link somewhere. If I follow the documentation link in the top menu, I get to docs.

odonnellryan2• 13 years ago

I see the documentation.

Seems to be Git without Commits - kind of. It seems to be better described here:

Unlike traditional version control systems (such as CVS and Subversion), Gitless is distributed. Rather than having a single, centralized repository, each user has her own repository that is synchronized with other repositories.

quarterto2• 13 years ago

That quote can be applied verbatim (but for s/Gitless/Git) to Git itself.

orclev• 13 years ago

Near as I can tell, the only difference is that they added this concept of tracked vs. untracked files. When you do a commit, everything that's currently tracked gets included in the commit unless you specifically list a set of files to include or ignore when you make the commit. As a side effect they seem to have removed the concept of a staging area.

Functionally it's a lot like every commit has the -a flag set and anything that's "untracked" is in your .gitignore file. I've not seen any other differences, although some other comments have mentioned some difference with regards to the way branches are handled.

quarterto2• 13 years ago

So... what advantages does this provide over straight Git? Reading the docs, it doesn't appear to abstract over Git at all.

skrebbel2• 13 years ago

From what I can see: easier control over tracked/untracked status of files; no stage (might be considered a disadvantage, though I'll wager a good interactive commit feature would render a stage unnecessary), automatically commit everything by default, much simpler concept of what a branch is and isn't; no fetch at all, just merge.

I like this experiment quite a lot. It's clearly very incomplete and lacking of features, but I feel that it gets the basic concepts more right than Git does. For example, the idea that merging from a local branch or merging from a remote branch is the same, is very nice and simple. Sure, it's not like 'git pull' vs 'git merge' is a lot more work, but still, I'd like to not be bothered by the difference.

There's a whole bunch of edge cases still missing here, I fear, but I really like where this is heading. Would use.

hosh• 13 years ago

I see, so they are experimenting with the user experience, probably by examining assumptions and see how much can be cut away and still be functional.

Peaker2• 13 years ago

The staging area is sort of a UI for "interactive" commit. But one that can persist the partial commit state across multiple commands, or until you can finish the work tomorrow.

An interactive commit interface which loses the accepted/rejected changes if you have to close it for one reason or another is going to be worse than the git UI for interactive commits.

Alphasite_• 13 years ago

Wasn't Git conceived as an api instead of a straight up all-in-one VCS?

saraid216• 13 years ago

There is a one-off line from Linus in the early days, and some interpretable evidence in its design, that suggests this is true.

It's not what I would call strong evidence, but then again: if you're building an API without a clear consumer, it'd be worthwhile to build your own consumer too. Especially if you're your own market.

aidenn0• 13 years ago

My understanding from reviewing the history is more that Linus wrote enough of git for him to be able to use it himself and then said "If other people want to use this, they may need to add some porcelain on top of it"

There then were a couple different porcelains written and discarded in favor of what we have now.

saidajigumi4• 13 years ago

It removes the staging area, which also removes one of the more powerful tools in git for teasing apart work into distinct ideas, whether for creating a sensible commit history, or to separate "tangled" work into different branches. For example:

    1. Write code
    2. Realize it's more than you want to commit at a go
    3. Stage just the files (or hunks, using `git add -i`) you want
    4. git stash
    5. confirm tests still work
    6. git commit
    7. git stash pop
    8. continue working, committing, etc.

I certainly understand the desire for cleaning up Git's CLI[1], but the staging area is one of those truly new offerings in Git w.r.t. legacy VCS. One that requires cognitive effort to learn but becomes a very useful tool in practice.

[1] Cf. Steve Losh's infamous "Git Koans": http://stevelosh.com/blog/2013/04/git-koans/

Guvante• 13 years ago

I once recovered a commit that someone had staged and reverted.

Even though he had never checked in code it was still saved into the VCS. That is pretty powerful.

egork8n3• 13 years ago

Except that in practice people tend not to perform steps 4, 5 and 7. They then commit non-working code and honestly believe that their commit is OK, because they saw all tests pass.

hyp0• 13 years ago

Having untangled ideas using hunks, when diff doesn't choose the desired boundaries I'm not quite sure it's worth it. Certainly an engaging exercise.

pwpwp• 13 years ago

You mean git stash --keep-index in 4) right?

waqf• 13 years ago

The staging area is only a powerful and necessary tool if you believe in the Commits Are Immutable rule (i.e. "don't rewrite history"). If you believe in that rule then you have to have a special mutable commit called the staging area, for when you're halfway through creating a commit.

But if you believe in rewriting history, then you can just use the tip of the working branch as a staging area. This would eliminate a whole slew of nonorthogonal git commands.

Personally I believe that branches should be explicitly designated as mutable (private "work" branches) or immutable (published branches): this gets you the best of both worlds. It's a shame Git doesn't have any tools to enforce that distinction.

couchand• 13 years ago

It looks like there's no concept of a stage, which would imply that commits can only be made at a file level. This nerfs the single greatest feature of git: git add -p

michaelmior• 13 years ago

git add -p could just be replaced with git commit -p without adding a stage. Although it doesn't seem like this is what Gitless does at the moment.

StavrosK• 13 years ago

I would think that this is exactly what's expected in an experiment like this.

justinsb• 13 years ago

A nice project: Git is a wonderful version control system, but the git cli (the porcelain) definitely has some annoyances. I think submodules, for example, are completely broken at the CLI level.

I don't think this project necessarily goes far enough though; the biggest change I saw was getting rid of the staging area. Whether or not that's a good idea, I was hoping for crazier ideas!

For example, how about something that is more aware of github, where my github branches auto-update, and works nicely with forks, pull-requests and issues. The git-review integration for gerrit is interesting along those lines: https://pypi.python.org/pypi/git-review

ash• 13 years ago

I think git-subtree is a better approach than what submodules are doing. Adding a submodule breaks things. E.g. `git clone` stops working as it should. In contrast, git-subtree doesn't break anything, because it just merges another repo history into the main repo:

https://github.com/apenwarr/git-subtree

(also in git contrib/)

graywh• 13 years ago

Github released a tool called "hub" that you might be interested in.

https://github.com/github/hub

girvo• 13 years ago

Hah. This makes me think of a quote I remember: Git is an excellent library for building a DVCS. ;)

michaelmcmillan• 13 years ago

If Linus gets a hold of any of you guys, for just a second..

alerkay• 13 years ago

I thought Linus had mostly worked on the inner workings of Git (the "plumbing"). These are awesome. But the CLI part is not straightforward at all. I keep seeing people new to Git having great pain to use it.

So, if some new folks come up and expose clearer CLI concepts than Git does, then I completely agree with their initiative. On top of that, if it remains compatible with existing Git repositories, then I will surely give it a try and maybe use it regularly.

farginay• 13 years ago

I wish the page described what the goal actually is - and what gitless is.

This is very hard to parse: "We are exploring what conceptual integrity means with the goal of building a rigorous foundation for concept design."

Huh?

Fomite• 13 years ago

Looks interesting, but front page doesn't do a great idea with selling me on why I should spend a couple hours of my day experimenting. What will this do for me?

js2• 13 years ago

See also EasyGit - https://people.gnome.org/~newren/eg/

ealdent• 13 years ago

Should be renamed Pointless.

We challenge all the basic assumptions of VCS and conclude ... git was right all along it just needs some syntactic sugar.

dack• 13 years ago

I'm all for reimagining the concepts that go into version control, standing on Git's shoulders. However, I think this is way too close to normal git for me to think it's useful. It might be simpler in ways, but it feels more complicated in others. For example, branches are pretty much the simplest concept you can think of in Git currently - just pointers to commits (referenced by name). Trying to think of them as separate lines of development actually makes me a little nervous that I would clobber some history somehow.

Anyway, that's not to discourage the effort - this is how we move development forward.

4ad• 13 years ago

I wish people compared new DVCS with git and mercurial, not with svn and cvs. That's incredibly unhelpful now that everyone is familiar with DVCS.

CodeMage• 13 years ago

"if we were to challenge the very core concepts in version control systems, what would version control look like?"

I looked at the documentation and I see nothing that challenges the very core concepts in version control systems. Did I miss something?

Gitless: an experimental version control system built on top of Git

Related Stories