4 ms·

I don't do new things in git, but since we transitioned, I spend about 3 to 4 times longer wrestling the VCS than with anything that I have used previously. Th

I don't do new things in git, but since we transitioned, I spend about 3 to 4 times longer wrestling the VCS than with anything that I have used previously. This is merely for routine stuff, because it takes more steps

adrianN 8y ago
The additional steps enable workflows that weren't possible before, so it's a tradeoff.
- gmueckl 8y ago
  This argument is just wrong. I have fewer steps with less mental load on other VCS implementations, yet I can get better workflows at the same time with zero loss of functionality. Prime example: the git staging area/cache/index needs to die. Git would be half as difficult to use with fewer code shredding surprises. This abomination is a prime example of badly exposed internal structure. Everything feature that is crammed into this whatever-the-hell-that-is could be replaced by a vastly superior solution which does not require anything like it.
  - nemetroid 8y ago
    The staging area is not necessary for your particular workflows. I found Mercurial horrible to work with precisely due to the lack of a staging step.
    - erik_seaberg 8y ago
      Untested commits should never exist, so why are we creating commits from abstracted storage that can't even be built and tested? Staging should happen in the workspace, stashing stuff that's not ready to commit.
      - DaiPlusPlus 8y ago
        > Untested commits should never exist Says who? Branches and commits are cheap, it's how we can undo ourselves and freely experiment. I agree that untested commits into a publishing/release branch shouldn't exist: all commits there should be merges from dev branches, but to say every commit should be tested is utter bollocks and denies us the advantages of cheap branching and commits.
        bzbarsky 8y ago
        > all commits there should be merges from dev branches Either they need to be squash+merge or the dev branches need to end up with working commits before the merge. Otherwise your life will become hell the first time you need to bisect.
    - gmueckl 8y ago
      Your dislike of mercurial is noted. But that does not change the fact that the staging area is objectively confusing and hindering users (don't have a link to the study here that looked into it).
      - jdbernard 8y ago
        Objectivity is not something you can just claim. There must be some objective measure. You mention a study, but that's not sufficient without an actual reference.
  - jdbernard 8y ago
    As a counter-anecdote, the staging area/cache/index is one of the main reasons I use git. When they were first released Mercurial was my initial choice. It was certainly more friendly to a beginner. But I quickly moved to using git and the staging area/cache/index you mention was one of the main reasons.

adrianN 8y ago

The additional steps enable workflows that weren't possible before, so it's a tradeoff.

gmueckl 8y ago
This argument is just wrong. I have fewer steps with less mental load on other VCS implementations, yet I can get better workflows at the same time with zero loss of functionality. Prime example: the git staging area/cache/index needs to die. Git would be half as difficult to use with fewer code shredding surprises. This abomination is a prime example of badly exposed internal structure. Everything feature that is crammed into this whatever-the-hell-that-is could be replaced by a vastly superior solution which does not require anything like it.
- nemetroid 8y ago
  The staging area is not necessary for your particular workflows. I found Mercurial horrible to work with precisely due to the lack of a staging step.
  - erik_seaberg 8y ago
    Untested commits should never exist, so why are we creating commits from abstracted storage that can't even be built and tested? Staging should happen in the workspace, stashing stuff that's not ready to commit.
    - DaiPlusPlus 8y ago
      > Untested commits should never exist Says who? Branches and commits are cheap, it's how we can undo ourselves and freely experiment. I agree that untested commits into a publishing/release branch shouldn't exist: all commits there should be merges from dev branches, but to say every commit should be tested is utter bollocks and denies us the advantages of cheap branching and commits.
      - bzbarsky 8y ago
        > all commits there should be merges from dev branches Either they need to be squash+merge or the dev branches need to end up with working commits before the merge. Otherwise your life will become hell the first time you need to bisect.
  - gmueckl 8y ago
    Your dislike of mercurial is noted. But that does not change the fact that the staging area is objectively confusing and hindering users (don't have a link to the study here that looked into it).
    - jdbernard 8y ago
      Objectivity is not something you can just claim. There must be some objective measure. You mention a study, but that's not sufficient without an actual reference.
- jdbernard 8y ago
  As a counter-anecdote, the staging area/cache/index is one of the main reasons I use git. When they were first released Mercurial was my initial choice. It was certainly more friendly to a beginner. But I quickly moved to using git and the staging area/cache/index you mention was one of the main reasons.