4 ms·

Git for the nervous developer

98 points by fogus 17y ago

ulf 17y ago
Very well written and pleasantly neutral. He focuses on a few key issues, which makes the article a very good starting point.
lawrencegs 17y ago
nice article! another blog post that push me to leave svn
dlsspy 17y ago
I'm becoming a huge fan of gerrit. I have to say that I still feel that "git commit -a" is trouble. It's OK to ease one in, but the faster you free yourself from thinking of committing as "saving the state of things" and begin to think of committing as "introducing a change" the more sense it all makes for everyone else. (I say this having had my team spend a week or so cleaning up a tree for public consumption and hearing them say things like "I don't understand what this change does" -- if we don't understand, we can't publish it)
- blasdel 17y ago
  "git add -p" is one of my favorite things. Do you know if anyone's written some porcelain that combines add -p with commit? Maybe you're adding annotations to the hunks as you 'y' them, which then gets inlined into COMMIT_EDITMSG?
  - cbeust 17y ago
    dlsspy: It depends. I make complex merges/branches on a regular basis and I find myself using `commit -a` pretty often, but I am also diligently branching out whenever I start working on something different, so I'm often confident that all the files that are both tracked and modified are the ones I want to commit. blasedl: I think that `git add -p` (committing certain changes in a file but not others) is a pretty advanced feature. I can see how it can be a life saver for experienced users, but I recommend creating two branches with each 100% of your changes rather than using just one branch that contains 60% and 40% of your changes. One switch that I find very useful is `git add -i`, which you should use whenever you want to add 2 files but you have 20 untracked ones in your working directory.
    - blasdel 17y ago
      add -p is barely advanced at all. It's certainly less advanced than merging the conflicts between pointless local branches and dealing with the existence of modified files in the working copy when switching between them. I find commit -am to be more infantile than rebase is advanced. Don't try to pretend that the index doesn't exist, since it will get dropped in your lap eventually, most likely when you least want it to (failed merge, etc).
      - dlsspy 17y ago
        I agree with this. In the above mentioned cleanup procedure, one of my developers was convinced that git would commit all changes during an interactive rebase where he was splitting a changeset regardless of what he had staged. I asked him the exact commands he used: git rebase -i whatever # select a thing to edit and split git add -p # ... git commit git rebase --continue Said it never split his change. Then I saw his transcript -- it included "git commit -a" Apparently he got so used to typing that that he just instinctively placed "-a" at the end of "git commit" because that's how you do it. I'm pretty sure he wasted hours with the magic -a option (not counting the ones that required the commits to be split up in the first place).
dasil003 17y ago
As opposed to its ugly user interface, Git’s underlying infrastructure is very solid and extremely well designed. On top of that, it’s actually not that hard to understand, and once you do, a whole new world will open up. This is the crux of why I love git and why I think so many people hate it. I love it because at the end of the day what it does under the hood is quite simple and intuitive, as opposed to systems like svn or cvs which even after using for ten times as long still were extremely opaque to me. It's a shame a lot of people can't make it past the interface.
- steamboiler 17y ago
  "On top of that, it’s actually not that hard to understand, and once you do, a whole new world will open up." While I agree with the author I must point out that it will take some effort for average users to understand what goes on behind the scenes. Especially if they have been using CVS/SVN for long. I came to git from SVN. It took me a good hour of working through the key diagrams/explanations using a pencil and paper to figure out the git model. And once I did git became a pleasure to work with. I find that some of my fellow developers are averse to making this initial investment of time and brain cycles to understand the theory of git. Some of them feel that a version control system isn't worth spending time on. Some of this reluctance has to do with how one is introduced to source control. Many learn about version control from "senior developers". More often than not CVS/SVN is explained away as "tracking diffs". Naturally when faced with something like git they ignore it or balk at the idea.
pnelly 17y ago
Can anyone here tell me if it would be possible to create a user interface for git, say if someone posted a link to a git repository, read the branches from the repository, and add some javascript magic with collapsible tree structure? I'm not familiar enough with git to know if this is possible. cheers

98 points by fogus 17y ago

ulf 17y ago

Very well written and pleasantly neutral. He focuses on a few key issues, which makes the article a very good starting point.

lawrencegs 17y ago

nice article! another blog post that push me to leave svn

dlsspy 17y ago

I'm becoming a huge fan of gerrit. I have to say that I still feel that "git commit -a" is trouble. It's OK to ease one in, but the faster you free yourself from thinking of committing as "saving the state of things" and begin to think of committing as "introducing a change" the more sense it all makes for everyone else. (I say this having had my team spend a week or so cleaning up a tree for public consumption and hearing them say things like "I don't understand what this change does" -- if we don't understand, we can't publish it)

blasdel 17y ago
"git add -p" is one of my favorite things. Do you know if anyone's written some porcelain that combines add -p with commit? Maybe you're adding annotations to the hunks as you 'y' them, which then gets inlined into COMMIT_EDITMSG?
- cbeust 17y ago
  dlsspy: It depends. I make complex merges/branches on a regular basis and I find myself using `commit -a` pretty often, but I am also diligently branching out whenever I start working on something different, so I'm often confident that all the files that are both tracked and modified are the ones I want to commit. blasedl: I think that `git add -p` (committing certain changes in a file but not others) is a pretty advanced feature. I can see how it can be a life saver for experienced users, but I recommend creating two branches with each 100% of your changes rather than using just one branch that contains 60% and 40% of your changes. One switch that I find very useful is `git add -i`, which you should use whenever you want to add 2 files but you have 20 untracked ones in your working directory.
  - blasdel 17y ago
    add -p is barely advanced at all. It's certainly less advanced than merging the conflicts between pointless local branches and dealing with the existence of modified files in the working copy when switching between them. I find commit -am to be more infantile than rebase is advanced. Don't try to pretend that the index doesn't exist, since it will get dropped in your lap eventually, most likely when you least want it to (failed merge, etc).
    - dlsspy 17y ago
      I agree with this. In the above mentioned cleanup procedure, one of my developers was convinced that git would commit all changes during an interactive rebase where he was splitting a changeset regardless of what he had staged. I asked him the exact commands he used: git rebase -i whatever # select a thing to edit and split git add -p # ... git commit git rebase --continue Said it never split his change. Then I saw his transcript -- it included "git commit -a" Apparently he got so used to typing that that he just instinctively placed "-a" at the end of "git commit" because that's how you do it. I'm pretty sure he wasted hours with the magic -a option (not counting the ones that required the commits to be split up in the first place).

dasil003 17y ago

As opposed to its ugly user interface, Git’s underlying infrastructure is very solid and extremely well designed. On top of that, it’s actually not that hard to understand, and once you do, a whole new world will open up. This is the crux of why I love git and why I think so many people hate it. I love it because at the end of the day what it does under the hood is quite simple and intuitive, as opposed to systems like svn or cvs which even after using for ten times as long still were extremely opaque to me. It's a shame a lot of people can't make it past the interface.

steamboiler 17y ago
"On top of that, it’s actually not that hard to understand, and once you do, a whole new world will open up." While I agree with the author I must point out that it will take some effort for average users to understand what goes on behind the scenes. Especially if they have been using CVS/SVN for long. I came to git from SVN. It took me a good hour of working through the key diagrams/explanations using a pencil and paper to figure out the git model. And once I did git became a pleasure to work with. I find that some of my fellow developers are averse to making this initial investment of time and brain cycles to understand the theory of git. Some of them feel that a version control system isn't worth spending time on. Some of this reluctance has to do with how one is introduced to source control. Many learn about version control from "senior developers". More often than not CVS/SVN is explained away as "tracking diffs". Naturally when faced with something like git they ignore it or balk at the idea.

pnelly 17y ago

Can anyone here tell me if it would be possible to create a user interface for git, say if someone posted a link to a git repository, read the branches from the repository, and add some javascript magic with collapsible tree structure? I'm not familiar enough with git to know if this is possible. cheers