5 ms·

I think you may have misunderstood my comment, of course there is more to it then checkout and commit. Those are the basics, that's where you start. Then you g

I think you may have misunderstood my comment, of course there is more to it then checkout and commit. Those are the basics, that's where you start. Then you get stuck somehow, and you read more. That's what I did at least. IMO It's about not giving yourself the impression that the learning curve is insurmountable, you can do it. Starting with the basics and growing up is, I thought, common knowledge for acquiring a new skill. I find when I get confused and flustered with git, every single time it's because I don't understand [yet] how I got into the current state. I've found that if I take a breath, put the problem aside and focus on figuring out how I got into that broken state, then the solution reveals itself -- not once have I ever lost code as a result of git confusion.

deleted 12y ago
[deleted]
kazinator 12y ago
I perfectly understand that there are hordes of programmers for whom messing around with git is far more interesting than the actual code they are working on. "Man, I just interactively rebased my last six changes so the commits are in a different order, and two of them were squashed into one! Boy, does that feel productive."
- zBard 12y ago
  How is that in anyway a reply to what s/he wrote ? Even snark should have a purpose.
srean 12y ago
> It's about not giving yourself the impression that the learning curve is insurmountable, you can do it Perhaps I can, but with mercurial around I dont see why I need to. I think no one in their right mind claims git cannot be grokked. They question whether that effort is well spent given there are equally effective alternatives that people find simpler to use. Other than github I fail to see a compelling reason going for git apart for the linux kernel development workflow of course. Its not a bad tool but not quite the "you possibly cannot and should not do without it" that it is made out to be. I find this comment very telling https://news.ycombinator.com/item?id=8602259 https://news.ycombinator.com/item?id=8602259 I would rather do without all that.
- nitrogen 12y ago
  I find this comment very telling https://news.ycombinator.com/item?id=8602259 https://news.ycombinator.com/item?id=8602259 I would rather do without all that. That comment goes out of its way to make things seem complicated. The different synonyms for things are confusing, and are evidence of the fact that Git has evolved over time rather than springing forth fully formed. That said, the staging area is one of the most useful features of Git, and if you don't want to use it, you can largely ignore it. The staging area allows me to make a few simple changes in the order that they occur to me, but add and commit them (using git add -p) in the order that makes the most sense for code review. Also: I highly recommend setting up shell aliases for the most commonly used commands, whether you use Git or anything else. "gco" is much faster to type than "git checkout", etc.
  - kazinator 12y ago
    > The staging area allows me to make a few simple changes in the order that they occur to me, but add and commit them (using git add -p) in the order that makes the most sense for code review. Ah, but note that "git commit" also takes a "--patch" argument. So the add-and-commit case you are describing can in fact be done in one step. That step uses the index, but only for its implementation; you're not aware of it. "git commit --patch ..." appears to move selected changes from the working copy straight to a new commit on HEAD. The command could be implemented in a version of git that doesn't have an index. Those little commits you make in preparation for review are your true staging area.

deleted 12y ago

[deleted]

kazinator 12y ago

I perfectly understand that there are hordes of programmers for whom messing around with git is far more interesting than the actual code they are working on. "Man, I just interactively rebased my last six changes so the commits are in a different order, and two of them were squashed into one! Boy, does that feel productive."

zBard 12y ago
How is that in anyway a reply to what s/he wrote ? Even snark should have a purpose.

srean 12y ago

> It's about not giving yourself the impression that the learning curve is insurmountable, you can do it Perhaps I can, but with mercurial around I dont see why I need to. I think no one in their right mind claims git cannot be grokked. They question whether that effort is well spent given there are equally effective alternatives that people find simpler to use. Other than github I fail to see a compelling reason going for git apart for the linux kernel development workflow of course. Its not a bad tool but not quite the "you possibly cannot and should not do without it" that it is made out to be. I find this comment very telling https://news.ycombinator.com/item?id=8602259 https://news.ycombinator.com/item?id=8602259 I would rather do without all that.

nitrogen 12y ago
I find this comment very telling https://news.ycombinator.com/item?id=8602259 https://news.ycombinator.com/item?id=8602259 I would rather do without all that. That comment goes out of its way to make things seem complicated. The different synonyms for things are confusing, and are evidence of the fact that Git has evolved over time rather than springing forth fully formed. That said, the staging area is one of the most useful features of Git, and if you don't want to use it, you can largely ignore it. The staging area allows me to make a few simple changes in the order that they occur to me, but add and commit them (using git add -p) in the order that makes the most sense for code review. Also: I highly recommend setting up shell aliases for the most commonly used commands, whether you use Git or anything else. "gco" is much faster to type than "git checkout", etc.
- kazinator 12y ago
  > The staging area allows me to make a few simple changes in the order that they occur to me, but add and commit them (using git add -p) in the order that makes the most sense for code review. Ah, but note that "git commit" also takes a "--patch" argument. So the add-and-commit case you are describing can in fact be done in one step. That step uses the index, but only for its implementation; you're not aware of it. "git commit --patch ..." appears to move selected changes from the working copy straight to a new commit on HEAD. The command could be implemented in a version of git that doesn't have an index. Those little commits you make in preparation for review are your true staging area.