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.
Gitless: an experimental version control system built on top of Git
21–30 of 48 posts
Re: Gitless: an experimental version control system built on top of Git
#22I'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.
Re: Gitless: an experimental version control system built on top of Git
#23So... what advantages does this provide over straight Git? Reading the docs, it doesn't appear to abstract over Git at all.
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.
[1] Cf. Steve Losh's infamous "Git Koans": http://stevelosh.com/blog/2013/04/git-koans/
Re: Gitless: an experimental version control system built on top of Git
#24So... what advantages does this provide over straight Git? Reading the docs, it doesn't appear to abstract over Git at all.
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.…
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.
Re: Gitless: an experimental version control system built on top of Git
#25A 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…
Github released a tool called "hub" that you might be interested in.
Re: Gitless: an experimental version control system built on top of Git
#26So... what advantages does this provide over straight Git? Reading the docs, it doesn't appear to abstract over Git at all.
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.…
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.
Re: Gitless: an experimental version control system built on top of Git
#27I 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.
Re: Gitless: an experimental version control system built on top of Git
#28Earlier quoted context omitted.
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.…
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.
I think the people well-versed enough in git to use "git add -p" to review their own changes, and commit them separately, are the same people that would correctly test their commits.
At least from my small sample size of people, that is true.
Re: Gitless: an experimental version control system built on top of Git
#29So... what advantages does this provide over straight Git? Reading the docs, it doesn't appear to abstract over Git at all.
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 featur…
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.
Re: Gitless: an experimental version control system built on top of Git
#30So... what advantages does this provide over straight Git? Reading the docs, it doesn't appear to abstract over Git at all.
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.…
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.