7 ms·

It's not necessary, it's a waste of development time and easily the biggest big-picture collective failure of our software engineering profession of the last de

by ak4g 10y ago

It's not necessary, it's a waste of development time and easily the biggest big-picture collective failure of our software engineering profession of the last decade. It easily beats out anything from the $foo.js world and the ongoing low-level security nightmare of web application development, because git, and more importantly, unnecessarily complex and error-prone git workflows have seen adoption across all kinds of software. There are probably a dozen projects in the world (the kernel admittedly being one of them) that are justifiably a good fit for the complex git-native workflows that have become standard practice across the industry today. But if you're doing it the old-fashioned way, you might as well use Subversion. Or mercurial, if you want all the local history, with the added bonus that unlike git it sensibly keeps the least-surprise semantics of 'commit', 'revert', and other commands that merely have a 30-year history of expectations that held true prior to git. But Mercurial was not authored by Linus, nor does it have the impenetrable, otherworldly data model that a first-time version-control-system author would unavoidably end up concocting in scratching their itch without consulting the existing, completely satisfactory, solutions that served us well for decades, which greatly reduces the number of interesting topics you can blog about for Mercurial. And so, git sees the adoption, github gets the $2bil valuation, and even bitbucket ends up switching to git as it's default. It won. Software engineering, collectively, has a lot of maturing to do.

marssaxman 10y ago
I have been using git for years and I still find its interface completely inscrutable. I have given up trying to learn it in a way that makes it make sense, and simply use a handful of everyday commands I've memorized by rote and look everything else up when I need it. I can't think of any other piece of software I actually use which has such a messy, non-predictable interface. Even 'make' eventually succumbed to rational analysis when I finally managed to suppress my nausea long enough to dig in and learn it as though it were a real language.
- simoncion 10y ago
  > I have given up trying to learn it in a way that makes it make sense, and simply use a handful of everyday commands I've memorized by rote and look everything else up when I need it. ? Here are the commands that I have used and make sense to me: branch, tag, log, diff, push, pull, fetch, commit, rebase (with or without -i), reset, add, rm, mv, stash, status, remote, bisect, reflog, blame, and fsck. Is this set of commands more or less the same as the set of commands that you've learned by rote memorization?
  - marssaxman 10y ago
    Commonly: pull, push, commit -a, reset --hard HEAD, checkout $FILE, status, log, show $HASH. Sometimes: commit --amend, rebase -i, add, rm, mv, stash [pop|apply]. Rarely: branch, revert. Git's documentation uses such a wide and flagrantly inconsistent variety of terminology and maintains such a poor distinction between its interface and its implementation that trying to read it actually worsens my understanding and reduces my confidence. I get everything useful from stackoverflow and ignore the docs at this point, and have thus resigned myself to using git as a form of voodoo. Subversion was so much clearer; I wish it had done a better job with merges and hadn't been so server-dependent. Mercurial seemed to actually care about its interface design, and the DVCS experience might suck less if it had won, but I've never had a chance to actually use it.
    - simoncion 10y ago
      Thanks for the reply! I agree that some of the commands have a very large array of options. I see many these options as very specialized tools (and certainly don't claim to know all (or -in some cases- most) of them). I, too find the "git config" command to be largely useless. Its value is in scripts or in Git frontends. Also, the git-config manpage has a complete listing of all valid git config options. So, there's that. :) > Commit, checkout, and reset seem rather more complicated than necessary and don't do anything useful in their default forms... When called with no args, commit records changes staged with add/rm/mv in the local repo's history. Checkout changes the tracked contents of the working copy to that of another point in the repo's history (so it is meaningless to call it without an argument), and git reset is destructive (and has no --force option), so it makes sense to require an argument. [0] In regards to commit and checkout: I came to git by way of Subversion. These two confused me for quite a while. What helped me to understand the logic behind them was to realize that -unlike SVN- git has * The working copy, which is manipulated with a bunch of commands * The area where changes that will be included in the next commit live, which is cleared out after every successful commit, and is manipulated by add, rm, and others * Your local repo, which is manipulated with commit and checkout * One or more remote repos, which is manipulated with push, pull, and merge But maybe you already had this solidly in mind, and this explanation was a waste of your time. :( > As always, trying to read the documentation leaves me with less understanding than I had before I started. Have you familiarized yourself with a significant fraction of git's vocabulary? The man pages became much clearer once I did so. [1] > ...for reasons I cannot comprehend they also get involved in merge resolution, where they perform tasks with no visible relationship to their names or their normal jobs. Oh. That's because a merge operation adds a series of commits from one or more branches into another branch and effectively makes a new commit with the result of the operation. If conflicts can be automatically resolved, then they are. If they cannot, then it's up to you to stage the changes you want to see in the merge commit (using add and friends) just like you would do when preparing any other commit. Does that make sense? > I have no idea what reflog would do; is there a flog command too? Nah. It's a command for examining and manipulating the reflog, which is -effectively- where git makes a record of every change that happened to your repo. You pretty much never need to use the command, but I have used to see just how git handled a set of complicated squash and commit reorder operations. From the man page: Reference logs, or "reflogs", record when the tips of branches and other references were updated in the local repository. Reflogs are useful in various Git commands, to specify the old value of a reference. For example, HEAD@{2} means "where HEAD used to be two moves ago", master@{one.week.ago} means "where master used to point to one week ago in this local repository", and so on. See gitrevisions(7) for more details. If you've gone on a mad history rewriting spree and have confused yourself (or simply accidentally moved a branch a while back and can't remember where it used to point), you can use reflog to trawl through the change history to save yourself. > I am generally more inclined to use stash or a second working directory than to deal with branches, since it's less busy-work. I'm curious. What busy-work do you have to do? I typically just have to do: "git branch whatever; git checkout another-branch; git branch -D some-other-branch". [0] Though -conceptually- a substantial portion of reset's functionality overlaps with checkout's functionality. So, that's silly and nonsensical. [1] Not that I'm implying that such a thing is be required to use git, mind.
- OneTwoFree 10y ago
  This. Even simple things like "undo last commit" has hard to remember syntax that I always have to google for it. I wish darcs was more successful.
vithlani 10y ago
This, x10,000. We have a situation at work where some rah-rah top managers are pushing this sort of thing as a way to try and appear to be more modern without any sort of understanding of the pain and disruptions it would bring in ordinary developer's daily workflow -- some of who don't even use any VCS.

by ak4g 10y ago

marssaxman 10y ago

I have been using git for years and I still find its interface completely inscrutable. I have given up trying to learn it in a way that makes it make sense, and simply use a handful of everyday commands I've memorized by rote and look everything else up when I need it. I can't think of any other piece of software I actually use which has such a messy, non-predictable interface. Even 'make' eventually succumbed to rational analysis when I finally managed to suppress my nausea long enough to dig in and learn it as though it were a real language.

simoncion 10y ago
> I have given up trying to learn it in a way that makes it make sense, and simply use a handful of everyday commands I've memorized by rote and look everything else up when I need it. ? Here are the commands that I have used and make sense to me: branch, tag, log, diff, push, pull, fetch, commit, rebase (with or without -i), reset, add, rm, mv, stash, status, remote, bisect, reflog, blame, and fsck. Is this set of commands more or less the same as the set of commands that you've learned by rote memorization?
- marssaxman 10y ago
  Commonly: pull, push, commit -a, reset --hard HEAD, checkout $FILE, status, log, show $HASH. Sometimes: commit --amend, rebase -i, add, rm, mv, stash [pop|apply]. Rarely: branch, revert. Git's documentation uses such a wide and flagrantly inconsistent variety of terminology and maintains such a poor distinction between its interface and its implementation that trying to read it actually worsens my understanding and reduces my confidence. I get everything useful from stackoverflow and ignore the docs at this point, and have thus resigned myself to using git as a form of voodoo. Subversion was so much clearer; I wish it had done a better job with merges and hadn't been so server-dependent. Mercurial seemed to actually care about its interface design, and the DVCS experience might suck less if it had won, but I've never had a chance to actually use it.
  - simoncion 10y ago
    Thanks for the reply! I agree that some of the commands have a very large array of options. I see many these options as very specialized tools (and certainly don't claim to know all (or -in some cases- most) of them). I, too find the "git config" command to be largely useless. Its value is in scripts or in Git frontends. Also, the git-config manpage has a complete listing of all valid git config options. So, there's that. :) > Commit, checkout, and reset seem rather more complicated than necessary and don't do anything useful in their default forms... When called with no args, commit records changes staged with add/rm/mv in the local repo's history. Checkout changes the tracked contents of the working copy to that of another point in the repo's history (so it is meaningless to call it without an argument), and git reset is destructive (and has no --force option), so it makes sense to require an argument. [0] In regards to commit and checkout: I came to git by way of Subversion. These two confused me for quite a while. What helped me to understand the logic behind them was to realize that -unlike SVN- git has * The working copy, which is manipulated with a bunch of commands * The area where changes that will be included in the next commit live, which is cleared out after every successful commit, and is manipulated by add, rm, and others * Your local repo, which is manipulated with commit and checkout * One or more remote repos, which is manipulated with push, pull, and merge But maybe you already had this solidly in mind, and this explanation was a waste of your time. :( > As always, trying to read the documentation leaves me with less understanding than I had before I started. Have you familiarized yourself with a significant fraction of git's vocabulary? The man pages became much clearer once I did so. [1] > ...for reasons I cannot comprehend they also get involved in merge resolution, where they perform tasks with no visible relationship to their names or their normal jobs. Oh. That's because a merge operation adds a series of commits from one or more branches into another branch and effectively makes a new commit with the result of the operation. If conflicts can be automatically resolved, then they are. If they cannot, then it's up to you to stage the changes you want to see in the merge commit (using add and friends) just like you would do when preparing any other commit. Does that make sense? > I have no idea what reflog would do; is there a flog command too? Nah. It's a command for examining and manipulating the reflog, which is -effectively- where git makes a record of every change that happened to your repo. You pretty much never need to use the command, but I have used to see just how git handled a set of complicated squash and commit reorder operations. From the man page: Reference logs, or "reflogs", record when the tips of branches and other references were updated in the local repository. Reflogs are useful in various Git commands, to specify the old value of a reference. For example, HEAD@{2} means "where HEAD used to be two moves ago", master@{one.week.ago} means "where master used to point to one week ago in this local repository", and so on. See gitrevisions(7) for more details. If you've gone on a mad history rewriting spree and have confused yourself (or simply accidentally moved a branch a while back and can't remember where it used to point), you can use reflog to trawl through the change history to save yourself. > I am generally more inclined to use stash or a second working directory than to deal with branches, since it's less busy-work. I'm curious. What busy-work do you have to do? I typically just have to do: "git branch whatever; git checkout another-branch; git branch -D some-other-branch". [0] Though -conceptually- a substantial portion of reset's functionality overlaps with checkout's functionality. So, that's silly and nonsensical. [1] Not that I'm implying that such a thing is be required to use git, mind.
OneTwoFree 10y ago
This. Even simple things like "undo last commit" has hard to remember syntax that I always have to google for it. I wish darcs was more successful.

vithlani 10y ago

This, x10,000. We have a situation at work where some rah-rah top managers are pushing this sort of thing as a way to try and appear to be more modern without any sort of understanding of the pain and disruptions it would bring in ordinary developer's daily workflow -- some of who don't even use any VCS.