7 ms·

The Thing About Git

86 points by mqt 19y ago

axod 19y ago
I don't get it... svn commit file1 file2 somemorestuff Surely you just commit the files you want, and leave out the ones you're still working on :/ What am I missing?
- gcv 19y ago
  You're missing that you may have made not one, but multiple substantive changes to file1, and you want to commit those changes separately.
  - axod 19y ago
    Then you have a mess whatever revision control system you use. You have to manually decide which changes you want to commit in the file, and which you don't. I still say it's better to avoid that mess in the first place.
    - mhartl 19y ago
      Then you have a mess whatever revision control system you use. True, but some make it much easier than others. Git is one of the easy ones. I still say it's better to avoid that mess in the first place. The article addressed this, and concluded as follows: Here’s a general principle I would like my VCS to acknowledge: moving from the present point B to some desired point C should not require a change in behavior at point A in the past. More simply, the phrase: “you should have,” ought to set off alarm bells.
    - gcv 19y ago
      From whose perspective is that a mess? From the perspective of a source control system which cannot deal with how I choose to work? Honestly, no offense meant, but I'm starting to wonder if Subversion is the Blub of source control systems.
      - axod 19y ago
        For me it's a mess. If I start to fix bug B on top of a half implemented feature A, I end up with a mess. I don't understand why you would work that way, and don't understand what git solves that svn doesn't. You still have to untangle the mess yourself.
        gcv 19y ago
        You've seriously never looked at a file and said to yourself, "These changes belong in two separate commits"?
  - allertonm 19y ago
    This only works if you can guarantee that the changes are not intertwingled in the same code block. He is also taking a gamble that the result of his selection will actually parse/compile/pass unit tests (select as appropriate) - he has no way to be sure of this. He is pretty much going to have to do a "get" into another working copy to be able to check this out, so I don't think he is gaining quite as much as he believes.
ashu 19y ago
wow, i did not know about git add --patch. that seems very very powerful.
jkkramer 19y ago
The more I use git, the more I like it. It's like a treasure trove of great features but still feels lightweight and close to the metal.
graywh 19y ago
Sold.
sanswork 19y ago
I just started using git at the end of last week and after the initial bit of "Well it doesn't work like svn it's a pain" cursing I'm finally starting to get the hang of it. More tips like this are greatly appreciated as I am still very much a 4 commands git user.
- jmtulloss 19y ago
  I'm a big fan of Mercurial just for this reason. Mercurial offers most of the benefits of Git without the steep learning curve and poor documentation. For instance, git add --patch can be done with hg record.
  - KirinDave 19y ago
    Hg misses some of the most key features. For example, most people find git's robust inline branching support to be an incredible boon for their workflow. Hg's implementation of this feature is poor by comparison.
    - jmtulloss 19y ago
      Inline branching would be nice... I think they do away with this for simplicity. Inline branching doesn't make that much conceptual sense a lot of the time. That said, I wish Hg had it.
      - KirinDave 19y ago
        Forgive me, because this is not an insult, but this "doesn't make conceptual sense" argument I hear so much is so much nonsense and excuses to me. Git supports multiple workflows and allows you to either directly resolve tainted-working-copy situations directly or avoid them. By allowing for local branches you enable multiple parallel lines of development in one repository. It saves space, it saves effort, it saves time, and it's a cleaner way to organize your projects (all in one place rather than scatted across a directory listing). It also means you can evade the tainted-working-copy problem entirely by keeping short-lived, private, parallel branches of current feature development. Personally, I much prefer this mode of operation when I have the foresight to do it.
sabat 19y ago
Needless to say, Git is not for people who are bothered by lack of heavy structure. Sorta like dynamic languages.
mhartl 19y ago
This is great! This was the one big thing I knew how to do in darcs but not in Git.
meat-eater 19y ago
The article did a real good job of explaining what makes git different from the other popular VCS. I used to use git as a more flexible subversion, just bundling adds and commits. But after I had this concept figured out, I realized there is more to git than being distributed and more flexible than svn.
simianstyle 19y ago
Interesting comparison of the tangled working copy problem, i'll have to dive into Git and see what all the fuss is about. On a side note: Am I the only person that couldn't see the site in firefox on linux? It crashed my browser every time I opened it and I ended up using lynx to view the article.
allenbrunson 19y ago
okay, call me a luddite, but even after reading about this supposed solution to the tangled update problem, i'd never use it. too complicated for me.
- kirubakaran 19y ago
  So what do you do for version control?
  - icky 19y ago
    Hardcopy printouts, marked with the date, in a shoebox under the bed... ;-)
  - allenbrunson 19y ago
    we use svn at work, and i like it okay. i suppose it has happened that i've got two sets of updates in progress that are tangled up somewhat, but i try to avoid such things, and usually succeed.
    - kirubakaran 19y ago
      If you haven't already, watch Linus' Google tech talk about git.
webframp 19y ago
Nice article, I learn something new about git everyday.
ardit33 19y ago
Is there any GUI clients for GIT, or is it command line only? If there is no good visual client, then that would really suck. I use perforce at work, and its visual client is pretty decent, but I have a co-worker raving about git all the time, so I wanted to give it a try.
- orib 19y ago
  there are a few: giggle (developer.imendio.com/projects/giggle) git-gui (packaged with Git, at least on my distro) gitk (same as git-gui) and probably a few more

86 points by mqt 19y ago

axod 19y ago

I don't get it... svn commit file1 file2 somemorestuff Surely you just commit the files you want, and leave out the ones you're still working on :/ What am I missing?

gcv 19y ago
You're missing that you may have made not one, but multiple substantive changes to file1, and you want to commit those changes separately.
- axod 19y ago
  Then you have a mess whatever revision control system you use. You have to manually decide which changes you want to commit in the file, and which you don't. I still say it's better to avoid that mess in the first place.
  - mhartl 19y ago
    Then you have a mess whatever revision control system you use. True, but some make it much easier than others. Git is one of the easy ones. I still say it's better to avoid that mess in the first place. The article addressed this, and concluded as follows: Here’s a general principle I would like my VCS to acknowledge: moving from the present point B to some desired point C should not require a change in behavior at point A in the past. More simply, the phrase: “you should have,” ought to set off alarm bells.
  - gcv 19y ago
    From whose perspective is that a mess? From the perspective of a source control system which cannot deal with how I choose to work? Honestly, no offense meant, but I'm starting to wonder if Subversion is the Blub of source control systems.
    - axod 19y ago
      For me it's a mess. If I start to fix bug B on top of a half implemented feature A, I end up with a mess. I don't understand why you would work that way, and don't understand what git solves that svn doesn't. You still have to untangle the mess yourself.
      - gcv 19y ago
        You've seriously never looked at a file and said to yourself, "These changes belong in two separate commits"?
- allertonm 19y ago
  This only works if you can guarantee that the changes are not intertwingled in the same code block. He is also taking a gamble that the result of his selection will actually parse/compile/pass unit tests (select as appropriate) - he has no way to be sure of this. He is pretty much going to have to do a "get" into another working copy to be able to check this out, so I don't think he is gaining quite as much as he believes.

ashu 19y ago

wow, i did not know about git add --patch. that seems very very powerful.

jkkramer 19y ago

The more I use git, the more I like it. It's like a treasure trove of great features but still feels lightweight and close to the metal.

graywh 19y ago

Sold.

sanswork 19y ago

I just started using git at the end of last week and after the initial bit of "Well it doesn't work like svn it's a pain" cursing I'm finally starting to get the hang of it. More tips like this are greatly appreciated as I am still very much a 4 commands git user.

jmtulloss 19y ago
I'm a big fan of Mercurial just for this reason. Mercurial offers most of the benefits of Git without the steep learning curve and poor documentation. For instance, git add --patch can be done with hg record.
- KirinDave 19y ago
  Hg misses some of the most key features. For example, most people find git's robust inline branching support to be an incredible boon for their workflow. Hg's implementation of this feature is poor by comparison.
  - jmtulloss 19y ago
    Inline branching would be nice... I think they do away with this for simplicity. Inline branching doesn't make that much conceptual sense a lot of the time. That said, I wish Hg had it.
    - KirinDave 19y ago
      Forgive me, because this is not an insult, but this "doesn't make conceptual sense" argument I hear so much is so much nonsense and excuses to me. Git supports multiple workflows and allows you to either directly resolve tainted-working-copy situations directly or avoid them. By allowing for local branches you enable multiple parallel lines of development in one repository. It saves space, it saves effort, it saves time, and it's a cleaner way to organize your projects (all in one place rather than scatted across a directory listing). It also means you can evade the tainted-working-copy problem entirely by keeping short-lived, private, parallel branches of current feature development. Personally, I much prefer this mode of operation when I have the foresight to do it.

sabat 19y ago

Needless to say, Git is not for people who are bothered by lack of heavy structure. Sorta like dynamic languages.

mhartl 19y ago

This is great! This was the one big thing I knew how to do in darcs but not in Git.

meat-eater 19y ago

The article did a real good job of explaining what makes git different from the other popular VCS. I used to use git as a more flexible subversion, just bundling adds and commits. But after I had this concept figured out, I realized there is more to git than being distributed and more flexible than svn.

simianstyle 19y ago

Interesting comparison of the tangled working copy problem, i'll have to dive into Git and see what all the fuss is about. On a side note: Am I the only person that couldn't see the site in firefox on linux? It crashed my browser every time I opened it and I ended up using lynx to view the article.

allenbrunson 19y ago

okay, call me a luddite, but even after reading about this supposed solution to the tangled update problem, i'd never use it. too complicated for me.

kirubakaran 19y ago
So what do you do for version control?
- icky 19y ago
  Hardcopy printouts, marked with the date, in a shoebox under the bed... ;-)
- allenbrunson 19y ago
  we use svn at work, and i like it okay. i suppose it has happened that i've got two sets of updates in progress that are tangled up somewhat, but i try to avoid such things, and usually succeed.
  - kirubakaran 19y ago
    If you haven't already, watch Linus' Google tech talk about git.

webframp 19y ago

Nice article, I learn something new about git everyday.

ardit33 19y ago

Is there any GUI clients for GIT, or is it command line only? If there is no good visual client, then that would really suck. I use perforce at work, and its visual client is pretty decent, but I have a co-worker raving about git all the time, so I wanted to give it a try.

orib 19y ago
there are a few: giggle (developer.imendio.com/projects/giggle) git-gui (packaged with Git, at least on my distro) gitk (same as git-gui) and probably a few more