3 ms·

Hi. I'm someone who is neither unwilling to learn, nor attached to how Subversion did things. And I dislike git. Superficially, I dislike it because it seems

Hi. I'm someone who is neither unwilling to learn, nor attached to how Subversion did things. And I dislike git. Superficially, I dislike it because it seems very little thought has been put into giving it a coherent interface. TFA points out instances of this, and it's true: whether something is implemented as its own command or as a flag to another command sometimes seems to have been decided via dartboard rather than any sort of intelligent process. I also do intensely dislike git's own man pages, which are the first thing I'd ordinarily turn to. Unfortunately, the concept of an acyclic graph has not yet arrived in that part of git. I dislike the way git overloads "branch" with multiple meanings or, rather, forces end users to do so. Mercurial does a better job of this currently, and has built-in support for the most important case (bookmarks vs. branches, in hg's terminology). I dislike the fact that every repository and every branch is on equal footing except for all the commands that work differently with a remote branch or require you to do extra setup before they do work. I dislike the fact that side-by-side inspection of different branches requires me to jump through hoops, since git only wants me to see one branch at a time. SVN, for all its faults, at least got that one right -- I can actually see two different branches, at the same time, using tools that require no knowledge of anything beyond my filesystem. I dislike the fact that even people who use git day in and day out still can't seem to agree on a workflow. And I'm not just talking about things like whether rebasing is fashionable this week, but very basic things like when and how to branch. I also agree with the article's point about contributor workflow; git and GitHub are more complex for contributors. There's also very little that's "decentralized", since GitHub is full of canonical central repositories, which makes me wonder what we gain from pretending we're using the "D" in "DVCS". And that's really just the tip of the iceberg.

chris_wot 14y ago
Superficially, I dislike it because it seems very little thought has been put into giving it a coherent interface. TFA points out instances of this, and it's true: whether something is implemented as its own command or as a flag to another command sometimes seems to have been decided via dartboard rather than any sort of intelligent process. The examples given weren't illogical. The author's examples were git pull, which he complains is a git fetch followed by a git merge... which is quite logical, given that to pull from a repository you must first fetch the files, and then merge the files into your repository. The second example that he complains about git commit not commiting a file if it's not specified on the command line. This makes sense, as you need to explicitly add the files via git add - something the documentation makes clear. As one of the complaints is that the documentation isn't clear, I think it worthwhile mentioning that the git-commit man page specifically says: The content to be added can be specified in several ways: 1. by using git add to incrementally "add" changes to the index before using the commit command (Note: even modified files must be "added"); . . 3. by listing files as arguments to the commit command, in which case the commit will ignore changes staged in the index, and instead record the current content of the listed files (which must already be known to git); 4. by using the -a switch with the commit command to automatically "add" changes from all known files (i.e. all files that are already listed in the index) and to automatically "rm" files in the index that have been removed from the working tree, and then perform the actual commit; The third example he used was that the shortcut for git branch and git checkout is git checkout -b. However, this makes sense because a branch doesn't populate automatically with any files and needs a checkout. Thus git checkout -b makes perfect sense. Perhaps there needs to be a git branch -c? I also do intensely dislike git's own man pages, which are the first thing I'd ordinarily turn to. Unfortunately, the concept of an acyclic graph has not yet arrived in that part of git. I think some of the opening descriptions are a little terse, but not entirely sure what you mean by the acyclic graph comment... I haven't been able to find anything obvious in the man pages that references a man page that then references the original man page... of course, I might have missed something! I dislike the way git overloads "branch" with multiple meanings or, rather, forces end users to do so. Could you clarify what you mean? Branches have only one meaning in git! I dislike the fact that every repository and every branch is on equal footing except for all the commands that work differently with a remote branch or require you to do extra setup before they do work. Could you clarify what you mean? I dislike the fact that side-by-side inspection of different branches requires me to jump through hoops, since git only wants me to see one branch at a time. SVN, for all its faults, at least got that one right -- I can actually see two different branches, at the same time, using tools that require no knowledge of anything beyond my filesystem. Can't gitk do this? Genuinely interested... I dislike the fact that even people who use git day in and day out still can't seem to agree on a workflow. And I'm not just talking about things like whether rebasing is fashionable this week, but very basic things like when and how to branch. I really can't see that's a valid argument. Some folks need to branch differently than others. This isn't just a git thing, the same can occur in SVN. As has been pointed out, branching tends to be discouraged because merging can be a regular pain. I also agree with the article's point about contributor workflow; git and GitHub are more complex for contributors. There's also very little that's "decentralized", since GitHub is full of canonical central repositories, which makes me wonder what we gain from pretending we're using the "D" in "DVCS". I disagree. The github workflow might be a little tricky, but as has been pointed out there are other workflows possible in git. git != github!
- ubernostrum 14y ago
  Thus git checkout -b makes perfect sense. Does it? Pull and then merge is a common operation; it gets a top-level command. Create a new branch from the one I'm working on and check it out is a common operation; it gets a flag on an existing command. What logical, coherent process decides that in each case? Branches have only one meaning in git! Hence the "forces end users to do so". There are two very common ways people use branches: one is as a temporary place to do a quick bugfix, the other is as a long-lived place to do a major rewrite or refactoring. With respect to the history of the codebase, these have very different implications, but semantically are the same type of thing in git. To pick on Subversion: when you had a long-lived branch in SVN, sooner or later you'd merge it back into the mainline... and then what happens? You want someone to be able to look at the repository and see that something major happened here and easily watch the progress, but you also want a way to say "this is done and merged". This required inventing a convention to indicate that -- in SVN, typically the finished branches would go in an "attic" directory. In git you face the same problem: making a temporary branch, doing the work, merging and then deleting the branch is what you're supposed to do in git. But for those long-lived major branches, you need to invent a convention (commonly, tagging the merge point) to indicate that they're done. I mentioned Mercurial because it has two different concepts for these things: the ephemeral deleted-once-it's-done line is a bookmark (which is pretty much exactly equivalent to a git branch, in that it's a named head that moves as you commit), and the long-lived major branch is... a branch. Which has additional semantics to indicate things like being finished. This means that in Mercurial you don't have to invent and re-invent ad-hoc conventions to handle common development patterns, while in git you do. Can't gitk do this? Every time I say I want to see two branches side-by-side without invoking the VCS, someone says "well, here's a tool that invokes the VCS to do that!" Which shows a lack of reading comprehension. Some folks need to branch differently than others. Sure, but why isn't there a clearly-documented "most projects will get along fine with this" workflow? Or, rather, why are there dozens of them? We've had VCS tools for long enough that the best practices for common cases are out there. The github workflow might be a little tricky, but as has been pointed out there are other workflows possible in git. Oh, there are. But git + GitHub has been relentlessly hyped as an Oatmeal-ish fantasy of unicorns farting rainbows onto a field of lollipops, so that's how people actually end up using it, and so it's valid to mention that it's a more complex workflow for contributors since it is a very common case and becoming more common.

chris_wot 14y ago

Superficially, I dislike it because it seems very little thought has been put into giving it a coherent interface. TFA points out instances of this, and it's true: whether something is implemented as its own command or as a flag to another command sometimes seems to have been decided via dartboard rather than any sort of intelligent process. The examples given weren't illogical. The author's examples were git pull, which he complains is a git fetch followed by a git merge... which is quite logical, given that to pull from a repository you must first fetch the files, and then merge the files into your repository. The second example that he complains about git commit not commiting a file if it's not specified on the command line. This makes sense, as you need to explicitly add the files via git add - something the documentation makes clear. As one of the complaints is that the documentation isn't clear, I think it worthwhile mentioning that the git-commit man page specifically says: The content to be added can be specified in several ways: 1. by using git add to incrementally "add" changes to the index before using the commit command (Note: even modified files must be "added"); . . 3. by listing files as arguments to the commit command, in which case the commit will ignore changes staged in the index, and instead record the current content of the listed files (which must already be known to git); 4. by using the -a switch with the commit command to automatically "add" changes from all known files (i.e. all files that are already listed in the index) and to automatically "rm" files in the index that have been removed from the working tree, and then perform the actual commit; The third example he used was that the shortcut for git branch and git checkout is git checkout -b. However, this makes sense because a branch doesn't populate automatically with any files and needs a checkout. Thus git checkout -b makes perfect sense. Perhaps there needs to be a git branch -c? I also do intensely dislike git's own man pages, which are the first thing I'd ordinarily turn to. Unfortunately, the concept of an acyclic graph has not yet arrived in that part of git. I think some of the opening descriptions are a little terse, but not entirely sure what you mean by the acyclic graph comment... I haven't been able to find anything obvious in the man pages that references a man page that then references the original man page... of course, I might have missed something! I dislike the way git overloads "branch" with multiple meanings or, rather, forces end users to do so. Could you clarify what you mean? Branches have only one meaning in git! I dislike the fact that every repository and every branch is on equal footing except for all the commands that work differently with a remote branch or require you to do extra setup before they do work. Could you clarify what you mean? I dislike the fact that side-by-side inspection of different branches requires me to jump through hoops, since git only wants me to see one branch at a time. SVN, for all its faults, at least got that one right -- I can actually see two different branches, at the same time, using tools that require no knowledge of anything beyond my filesystem. Can't gitk do this? Genuinely interested... I dislike the fact that even people who use git day in and day out still can't seem to agree on a workflow. And I'm not just talking about things like whether rebasing is fashionable this week, but very basic things like when and how to branch. I really can't see that's a valid argument. Some folks need to branch differently than others. This isn't just a git thing, the same can occur in SVN. As has been pointed out, branching tends to be discouraged because merging can be a regular pain. I also agree with the article's point about contributor workflow; git and GitHub are more complex for contributors. There's also very little that's "decentralized", since GitHub is full of canonical central repositories, which makes me wonder what we gain from pretending we're using the "D" in "DVCS". I disagree. The github workflow might be a little tricky, but as has been pointed out there are other workflows possible in git. git != github!

ubernostrum 14y ago
Thus git checkout -b makes perfect sense. Does it? Pull and then merge is a common operation; it gets a top-level command. Create a new branch from the one I'm working on and check it out is a common operation; it gets a flag on an existing command. What logical, coherent process decides that in each case? Branches have only one meaning in git! Hence the "forces end users to do so". There are two very common ways people use branches: one is as a temporary place to do a quick bugfix, the other is as a long-lived place to do a major rewrite or refactoring. With respect to the history of the codebase, these have very different implications, but semantically are the same type of thing in git. To pick on Subversion: when you had a long-lived branch in SVN, sooner or later you'd merge it back into the mainline... and then what happens? You want someone to be able to look at the repository and see that something major happened here and easily watch the progress, but you also want a way to say "this is done and merged". This required inventing a convention to indicate that -- in SVN, typically the finished branches would go in an "attic" directory. In git you face the same problem: making a temporary branch, doing the work, merging and then deleting the branch is what you're supposed to do in git. But for those long-lived major branches, you need to invent a convention (commonly, tagging the merge point) to indicate that they're done. I mentioned Mercurial because it has two different concepts for these things: the ephemeral deleted-once-it's-done line is a bookmark (which is pretty much exactly equivalent to a git branch, in that it's a named head that moves as you commit), and the long-lived major branch is... a branch. Which has additional semantics to indicate things like being finished. This means that in Mercurial you don't have to invent and re-invent ad-hoc conventions to handle common development patterns, while in git you do. Can't gitk do this? Every time I say I want to see two branches side-by-side without invoking the VCS, someone says "well, here's a tool that invokes the VCS to do that!" Which shows a lack of reading comprehension. Some folks need to branch differently than others. Sure, but why isn't there a clearly-documented "most projects will get along fine with this" workflow? Or, rather, why are there dozens of them? We've had VCS tools for long enough that the best practices for common cases are out there. The github workflow might be a little tricky, but as has been pointed out there are other workflows possible in git. Oh, there are. But git + GitHub has been relentlessly hyped as an Oatmeal-ish fantasy of unicorns farting rainbows onto a field of lollipops, so that's how people actually end up using it, and so it's valid to mention that it's a more complex workflow for contributors since it is a very common case and becoming more common.