4 ms·

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

skrebbel 13y 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 13y 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.
- Peaker 13y 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_ 13y ago
Wasn't Git conceived as an api instead of a straight up all-in-one VCS?
- saraid216 13y 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 13y 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.
saidajigumi 13y 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/ http://stevelosh.com/blog/2013/04/git-koans/
- Guvante 13y 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.
- egork8n 13y 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.
  - Peaker 13y ago
    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.
    - egork8n 13y ago
      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.

skrebbel 13y 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 13y 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.
Peaker 13y 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_ 13y ago

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

saraid216 13y 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 13y 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.

saidajigumi 13y 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/ http://stevelosh.com/blog/2013/04/git-koans/

Guvante 13y 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.
egork8n 13y 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.
- Peaker 13y ago
  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.
  - egork8n 13y ago
    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.