Live data from Hacker News

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

people.csail.mit.edu

31–40 of 48 posts

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

#31
post #30

Earlier 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.…

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.

You can split hunks down to individual lines.

Also git-gui can stage individual lines.

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

#32
post #28
post #26

Earlier quoted context omitted.

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.

This is definitely not true for the outsource companies here in the 3rd world.

It gets even worse when you face people who have used SVN for years. Once they realize that they can commit non-working code on their feature branch as long as the result of the final merge into master is OK, they start to dump random work-in-progress stuff into git repo. As the result, blame and bisect are completely broken, but who cares, that's another developer who would feel the pain trying to make sense from the changeset history two years from now, not you.

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

#33
post #30

Earlier 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.…

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.

Agreed, I don't tend to use `git add -i` much directly either. I use editor integrations and/or a GUI tool that allows line-by-line staging. I rather like Git Tower's[1] approach: it's easy to stage directly in the diff view either by hunk or by selected lines. This works nicely because most of the time the diff hunk(s) are OK, and I only need to mess with a selection in the less common cases.

[1] http://www.git-tower.com/

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

#34
post #32
post #28

Earlier quoted context omitted.

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.

This is definitely not true for the outsource companies here in the 3rd world. It gets even worse when you face people who have used SVN for years. Once they realize that they can commit non-working code on their feature branch as long as the result of the final merge into master is OK, they start to dump random work-in-progress stuff into git repo. As the result, blame and bisect are completely broken, but who cares…

One way to mitigate that is to always squash-merge the suspect work. In some orgs, it's really hard to establish a culture of good "git hygiene". Typically CI is already branch-focused, and the merging process after CI/review/etc. is tailored to just throw out the "noise" from the incoming branches.

This also handles issues such as staff who just don't get that long-lived, continually remerged (from master) branches are evil when viewing history using `git log --graph` or similar GUI views.

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

#35

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

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.

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

#36

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

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

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.

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

#37
post #26

Earlier 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.

So, what, if people aren't using the full power of Git, the response is to remove that power? That seems completely backwards. The response should be to educate people on proper development practices.

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

#38
post #37
post #26

Earlier quoted context omitted.

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.

So, what, if people aren't using the full power of Git, the response is to remove that power? That seems completely backwards. The response should be to educate people on proper development practices.

Sometimes it just feels like not removing the nuclear missile launch button from a cage with monkeys arguing that we should not remove the power of nuclear weapons just because monkeys are unable to understand the geopolitical situation.

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

#39
post #31
post #30

Earlier quoted context omitted.

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.

You can split hunks down to individual lines. Also git-gui can stage individual lines.

You can, but last time I tried it was only via editing the diffs ('e' command in `git add -p`), which is unpleasant and sometimes pretty annoying (ah, how many times I missed the leading space on context line to have it shout at me with incomprehensible errors). (And yeah, I'm just using `git gui` for this now.)

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

#40

Earlier quoted context omitted.

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.

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

That's true.
Post reply on HN