5 ms·

No. Source control is not that complicated. Git is just bad. As an existence proof: Mercurial is much better and simpler. I can teach someone who has never eve

No. Source control is not that complicated. Git is just bad. As an existence proof: Mercurial is much better and simpler. I can teach someone who has never even heard of source control how to use Perforce in about 10 minutes. They will never shoot themselves in the foot and they will never lose work. There are certainly more advanced techniques that require additional training. But the basics are very easy. Git makes even basic things difficult. And allows even experts to shoot their face off with a rocket launcher. Git sucks. The best tool doesn't always win. If MercurialHub had been founded instead of GitHub we'd all be used a different tool. Alas.

beej71 2y ago
Out of curiosity, what are the most common foot guns, in your opinion?
- lostdog 2y ago
  Messing up conflicts during a rebase, thinking I did it right, and then finalizing the rebase and losing work that accidentally disappeared. That's my most common mistake at least.
  - rblatz 2y ago
    Find your last entry before the rebase using the reflog and reset your local branch to that entry. The work isn’t lost, it is sitting right there.
    - maccard 2y ago
      > Find your last entry before the rebase using the reflog and reset your local branch to that entry. You shouldn’t ever need to go to the reflog unless you’re in an exceptional case, and fit makes it very very easy to get into that exceptional case.
      - diggan 2y ago
        > You shouldn’t ever need to go to the reflog unless you’re in an exceptional case If "loosing your work and it's not in the git log" isn't an exceptional case, what exactly is a "exceptional case"?
        maccard 2y ago
        > If "loosing your work and it's not in the git log" isn't an exceptional case, what exactly is a "exceptional case"? Losing your work should be exceptional. It's very, very easy to fuck a rebase up, and rebasing is (like it or lump it) a common operation. You shouldn't one step away from an exceptional case from a daily operation.
        diggan 2y ago
        Powerful tools have powerful consequences, case in point: with `rm` you're always one mistake away from blowing away large parts of your work.
        _proofs 2y ago
        this is solved by branching your feature again and rebasing from that or the feature original in case the rebase gets fucked. you don't have to treat rebases or merges as this black hole of "i have no recourse for not getting it perfect the first time".
- bb88 2y ago
  Not realizing that git branches are cheap. 1. Create a branch from the intended destination. 2. Merge/rebase/whatever complex operation you need to do into that branch. 3. If successful merge this branch (fast forward merge) into the intended destination. 4. If unsuccessful delete the branch and start over at step 1.
- forrestthewoods 2y ago
  Honestly? I’m not sure. Here’s the problem: 1. it’s possible to get into a bad state 2. it’s not clear what exactly that state is 3. it’s not clear how you got into that state 4. it’s not clear how to get out of it I understand Git reasonably well. I know a good bit how it works under the hood. When I have a gitastrophe I rarely understand what I did wrong and how to avoid it in the future. Here’s a recent post from a friend: “ 0) clicked fetch all to make sure I had latest everything 1) right clicked on master and selected "merge master into branch" 2) made sure there were no merge errors 3) get on the master branch 4) clicked pull again because sometimes switching to branches doesn't work without it 5) right clicked on my branch and selected "merge branch into master" 6) clicked check in and push buttons About an hour later, someone noticed that everyone's work from the past week was gone. I mean the checkins were still there in the graph, but all their code was basically gone in latest. And because my branch had many commits in it, apparently no one could just revert my merge and it took someone an hour to work out how to fix everything during which no one could touch git” Somewhere along the way he didn’t do what he thought he did. No one could figure out what he actually did wrong. No lessons were learned from this Gitastrophe.
  - Izkata 2y ago
    Well first, that's not git, that's some other GUI giving its own interface to git. The majority of the time my co-workers have a git problem, it's because their GUI tool has done something weird without telling them exactly what it did - one of theirs has a "Sync Branch" button which he'd click on whenever the IDE highlighted it, and I have no idea what that's even supposed to do, but I think it was some sort of rebase. Without knowing for sure what was going on and whether your friend was describing it using the right verbs, I'm thinking (0) didn't pull in the changes ("fetch" instead of "pull") so (1) didn't merge in any new commits, but (4) did advance master, causing it to diverge from what was on the server. Then (6) probably decided to be helpful and did a force-push instead of a regular push so it wouldn't fail on the user. That would cause the server to have your friend's changes, but be missing anything that had been pushed to master after they started working on their branch.
    - Izkata 2y ago
- maccard 2y ago
  How do switch to a branch? (Note that you need to fetch before you switch. Also switch is experimental but it’s not really) How do I undo a change and get it to other people on the team? - follow up, What happens if someone has made an unrelaydx change since? - someone has committed an enormous change and I want the commit immediately after it but the enormous change doesn’t affect me. How do I get that single file without needing the mega change. - someone has committed a mega change and pushed it to main, and it’s busted. How do I put my perfectly functioning feature in while i wait for the west coast to wake up and fix it? I don’t need an explanation on how to solve these issues, I am perfectly able to. But these are daily workflow issues that hit requires you to use external tools, and change entire development processes to work around. And trying to skirt them is a guaranteed one way ticket to a busted workspace
  - diggan 2y ago
    I'm aware of how to do most of those things in git, but that probably says more about me than git. What I'm curious about though, since I basically entered the software developer workforce just as Git became mainstream and GitHub became popular, how would you do those things with the alternatives at the time; SVN, Mercurial, Perforce and the rest? Would it be easier or harder? Would it work better/worse in a sync/async context, without centralized servers? There are lots of people complaining about how needlessly complicated git is, but they almost always fail to put forward some simpler alternative that can handle the same things. Is git actually accidentally complicated or purposefully complicated because the topic at hand is kind of complicated?
    - maccard 2y ago
      > without centralized servers? Git is complicated _beacuse_ of this. The defaults are tuned for this. But, most people don't need this. I'm sure there are people out there who set an upstream to their coworkers PC and clone a branch from them, merge it with their work and then someone else takes that and is saved a bunch of work because the commits all line up, but for every 1 of those people there are probably 100,000 who push and pull to a centralized forge, and pay the complexity cost for the distributed workflow. > but they almost always fail to put forward some simpler alternative that can handle the same things. Is git actually accidentally complicated or purposefully complicated because the topic at hand is kind of complicated? Git is complicated because it's got poor defaults, an unintuitive cli, and is designed for distributed workflows (I've never worked anywhere that has used a distributed workflow, fwiw). I can sit someone down with perforce for 15 minutes and basically never have to interact with them on it again. It's _so_ much simpler - because it's centralized. It has some baggage, is definitely not perfect (and it costs an absolute bomb). Mercurial is another example of something that is much, much easier to use and work with. I wish mercurial won, honestly.
- Pxtl 2y ago
  offhand: 1) The fact that "fetch" doesn't happen automatically in the "chrome" commands. 2) naive use of "git merge" results in history that's a cyclopean horror. For example, caring about the "left" and "right" parents of a commit. 3) rerere isn't enabled by default so if you're merging from upstream constantly you're having to re-resolve same conflicts, every time is an opportunity to screw up. 4) a culture of keeping a clean history but cleaning history is destructive and painful for other users of the same branch. 5) git merge merges from local (stale) branch by default, so when merging from upstream to get new commits you have to remember to `git merge origin/main` instead of `git merge main`. Also see (1). 6) using submodules. At all.
gitgood 2y ago
You're welcome to switch back to CVS or RCS at any time. You're also welcome to deal with their specific tradeoffs.
- forrestthewoods 2y ago
  One of the modern curiosities is that people have somehow made using Git to be part of their identity. Dear HN user ‘gitgood’ who has a one hour old account, I suggest you take a step back and reevaluate things.
- sunshowers 2y ago
  Why not switch forward to Jujutsu? It's simpler and more powerful than Git.
  - forrestthewoods 2y ago
    I've been using Jujutsu a little and over the weekend lost a bunch of files. I'd been working happily in an anonymous branch. I had a bunch of content in a thirdparty folder that was hidden by .gitignore. I couldn't figure out how to merge my anonymous branch into master. Somehow wound up on the old master and it deleted all of my gitignored files. Then jj status got totally fubar and couldn't complete in under 5 minutes because something something 7500 files (everything that got deleted, it was compiler toolchains). It was a disaster. Literally the most important thing for any VCS tool is to never ever delete file I don't want deleted. No more Jujutsu for me. Someday someone will invent a VCS tool that doesn't suck. Today is not that day.
    - necauqua 2y ago
      While I understand your predicament, consider not giving up on jj just yet because of this. It is _exceedingly_ hard to lose files in jj, it's actually emotionally frustrating reading the line "most important thing [..] is to never ever delete file" because that's the whole shtick in jj with the oplog and whatnot - so something like nuking secrets completely from a jj repo is a bit of a chore. Can you file a bug at least? A repro of some sort?. Or at least show us what is it what you did, `jj op log` might be enough to deduce what happened. Also check out `jj op log -p`, your files might very well be in history, especially if, as you said, jj status took a long time (presumably snapshotting those files that got lost)
crabbone 2y ago
Why I agree with many points you make... let's keep Perforce out of it. The amount of damage that program done to my source code, and the amount of pain caused by it in daily use tells me that 10 minutes will not cut it. Here's a simple example of how people shoot themselves in the foot with Perforce all the time: it makes files you edit read-only, and then you run with your pants on fire trying to figure out how to save your changes, because the system won't let you do that. And then you do something dumb, like copy the contents of the file you aren't able to save someplace else, and then try to incorporate those changes back once you've dealt with the file that Perforce wouldn't save. And then end up with a merge conflict just working with your one single change that you are trying to add to your branch. I never regretted never having to touch Perforce ever again. Just no.
- maccard 2y ago
  Why does git get a free pass for shitty defaults but perforce doesn’t? Perforce long predates git, and the checkout operation (which can be done on save with any modern editor) fixes that immediately.
  - jayd16 2y ago
    Have you actually used P4 in anger? Having to add P4 support to any script, sucks. Having to do a network operation when touching files, sucks. Many many many apps have no idea what p4 is and will never get p4 support. Git gets out of the way.
    - maccard 2y ago
      > Have you actually used P4 in anger? Yes. I use it every day. I've ran P4 servers that serve hundreds of GBs per day globally with both commit edges and regular proxies. I've written batch scripts, bash scripts, and tooling in python, go and C# around it. > Having to add P4 support to any script, sucks. I disagree. It's no worse than adding git support to something. p4 zTag isn't the most elegant thing, but it works. > Having to do a network operation when touching files, sucks. Does it? Is it any worse than having to keep the entire history of every file locally on your machine, including any "large files?" And git-lfs as a solution to that means you're now coupled to wherever those files are stored. Making large submits to P4 isn't the nicest experience, but it sure beats paying that price every time you clone a repo IMO. > Many many many apps have no idea what p4 is and will never get p4 support In the same way that many people in this thread are blaming a git gui for a problem, "that's not P4's fault". I do agree it's shit though. > Git gets out of the way. Until it doesn't.

beej71 2y ago

Out of curiosity, what are the most common foot guns, in your opinion?

lostdog 2y ago
Messing up conflicts during a rebase, thinking I did it right, and then finalizing the rebase and losing work that accidentally disappeared. That's my most common mistake at least.
- rblatz 2y ago
  Find your last entry before the rebase using the reflog and reset your local branch to that entry. The work isn’t lost, it is sitting right there.
  - maccard 2y ago
    > Find your last entry before the rebase using the reflog and reset your local branch to that entry. You shouldn’t ever need to go to the reflog unless you’re in an exceptional case, and fit makes it very very easy to get into that exceptional case.
    - diggan 2y ago
      > You shouldn’t ever need to go to the reflog unless you’re in an exceptional case If "loosing your work and it's not in the git log" isn't an exceptional case, what exactly is a "exceptional case"?
      - maccard 2y ago
        > If "loosing your work and it's not in the git log" isn't an exceptional case, what exactly is a "exceptional case"? Losing your work should be exceptional. It's very, very easy to fuck a rebase up, and rebasing is (like it or lump it) a common operation. You shouldn't one step away from an exceptional case from a daily operation.
        diggan 2y ago
        Powerful tools have powerful consequences, case in point: with `rm` you're always one mistake away from blowing away large parts of your work.
        _proofs 2y ago
        this is solved by branching your feature again and rebasing from that or the feature original in case the rebase gets fucked. you don't have to treat rebases or merges as this black hole of "i have no recourse for not getting it perfect the first time".
bb88 2y ago
Not realizing that git branches are cheap. 1. Create a branch from the intended destination. 2. Merge/rebase/whatever complex operation you need to do into that branch. 3. If successful merge this branch (fast forward merge) into the intended destination. 4. If unsuccessful delete the branch and start over at step 1.
forrestthewoods 2y ago
Honestly? I’m not sure. Here’s the problem: 1. it’s possible to get into a bad state 2. it’s not clear what exactly that state is 3. it’s not clear how you got into that state 4. it’s not clear how to get out of it I understand Git reasonably well. I know a good bit how it works under the hood. When I have a gitastrophe I rarely understand what I did wrong and how to avoid it in the future. Here’s a recent post from a friend: “ 0) clicked fetch all to make sure I had latest everything 1) right clicked on master and selected "merge master into branch" 2) made sure there were no merge errors 3) get on the master branch 4) clicked pull again because sometimes switching to branches doesn't work without it 5) right clicked on my branch and selected "merge branch into master" 6) clicked check in and push buttons About an hour later, someone noticed that everyone's work from the past week was gone. I mean the checkins were still there in the graph, but all their code was basically gone in latest. And because my branch had many commits in it, apparently no one could just revert my merge and it took someone an hour to work out how to fix everything during which no one could touch git” Somewhere along the way he didn’t do what he thought he did. No one could figure out what he actually did wrong. No lessons were learned from this Gitastrophe.
- Izkata 2y ago
  Well first, that's not git, that's some other GUI giving its own interface to git. The majority of the time my co-workers have a git problem, it's because their GUI tool has done something weird without telling them exactly what it did - one of theirs has a "Sync Branch" button which he'd click on whenever the IDE highlighted it, and I have no idea what that's even supposed to do, but I think it was some sort of rebase. Without knowing for sure what was going on and whether your friend was describing it using the right verbs, I'm thinking (0) didn't pull in the changes ("fetch" instead of "pull") so (1) didn't merge in any new commits, but (4) did advance master, causing it to diverge from what was on the server. Then (6) probably decided to be helpful and did a force-push instead of a regular push so it wouldn't fail on the user. That would cause the server to have your friend's changes, but be missing anything that had been pushed to master after they started working on their branch.
  - Izkata 2y ago
maccard 2y ago
How do switch to a branch? (Note that you need to fetch before you switch. Also switch is experimental but it’s not really) How do I undo a change and get it to other people on the team? - follow up, What happens if someone has made an unrelaydx change since? - someone has committed an enormous change and I want the commit immediately after it but the enormous change doesn’t affect me. How do I get that single file without needing the mega change. - someone has committed a mega change and pushed it to main, and it’s busted. How do I put my perfectly functioning feature in while i wait for the west coast to wake up and fix it? I don’t need an explanation on how to solve these issues, I am perfectly able to. But these are daily workflow issues that hit requires you to use external tools, and change entire development processes to work around. And trying to skirt them is a guaranteed one way ticket to a busted workspace
- diggan 2y ago
  I'm aware of how to do most of those things in git, but that probably says more about me than git. What I'm curious about though, since I basically entered the software developer workforce just as Git became mainstream and GitHub became popular, how would you do those things with the alternatives at the time; SVN, Mercurial, Perforce and the rest? Would it be easier or harder? Would it work better/worse in a sync/async context, without centralized servers? There are lots of people complaining about how needlessly complicated git is, but they almost always fail to put forward some simpler alternative that can handle the same things. Is git actually accidentally complicated or purposefully complicated because the topic at hand is kind of complicated?
  - maccard 2y ago
    > without centralized servers? Git is complicated _beacuse_ of this. The defaults are tuned for this. But, most people don't need this. I'm sure there are people out there who set an upstream to their coworkers PC and clone a branch from them, merge it with their work and then someone else takes that and is saved a bunch of work because the commits all line up, but for every 1 of those people there are probably 100,000 who push and pull to a centralized forge, and pay the complexity cost for the distributed workflow. > but they almost always fail to put forward some simpler alternative that can handle the same things. Is git actually accidentally complicated or purposefully complicated because the topic at hand is kind of complicated? Git is complicated because it's got poor defaults, an unintuitive cli, and is designed for distributed workflows (I've never worked anywhere that has used a distributed workflow, fwiw). I can sit someone down with perforce for 15 minutes and basically never have to interact with them on it again. It's _so_ much simpler - because it's centralized. It has some baggage, is definitely not perfect (and it costs an absolute bomb). Mercurial is another example of something that is much, much easier to use and work with. I wish mercurial won, honestly.
Pxtl 2y ago
offhand: 1) The fact that "fetch" doesn't happen automatically in the "chrome" commands. 2) naive use of "git merge" results in history that's a cyclopean horror. For example, caring about the "left" and "right" parents of a commit. 3) rerere isn't enabled by default so if you're merging from upstream constantly you're having to re-resolve same conflicts, every time is an opportunity to screw up. 4) a culture of keeping a clean history but cleaning history is destructive and painful for other users of the same branch. 5) git merge merges from local (stale) branch by default, so when merging from upstream to get new commits you have to remember to `git merge origin/main` instead of `git merge main`. Also see (1). 6) using submodules. At all.

gitgood 2y ago

You're welcome to switch back to CVS or RCS at any time. You're also welcome to deal with their specific tradeoffs.

forrestthewoods 2y ago
One of the modern curiosities is that people have somehow made using Git to be part of their identity. Dear HN user ‘gitgood’ who has a one hour old account, I suggest you take a step back and reevaluate things.
sunshowers 2y ago
Why not switch forward to Jujutsu? It's simpler and more powerful than Git.
- forrestthewoods 2y ago
  I've been using Jujutsu a little and over the weekend lost a bunch of files. I'd been working happily in an anonymous branch. I had a bunch of content in a thirdparty folder that was hidden by .gitignore. I couldn't figure out how to merge my anonymous branch into master. Somehow wound up on the old master and it deleted all of my gitignored files. Then jj status got totally fubar and couldn't complete in under 5 minutes because something something 7500 files (everything that got deleted, it was compiler toolchains). It was a disaster. Literally the most important thing for any VCS tool is to never ever delete file I don't want deleted. No more Jujutsu for me. Someday someone will invent a VCS tool that doesn't suck. Today is not that day.
  - necauqua 2y ago
    While I understand your predicament, consider not giving up on jj just yet because of this. It is _exceedingly_ hard to lose files in jj, it's actually emotionally frustrating reading the line "most important thing [..] is to never ever delete file" because that's the whole shtick in jj with the oplog and whatnot - so something like nuking secrets completely from a jj repo is a bit of a chore. Can you file a bug at least? A repro of some sort?. Or at least show us what is it what you did, `jj op log` might be enough to deduce what happened. Also check out `jj op log -p`, your files might very well be in history, especially if, as you said, jj status took a long time (presumably snapshotting those files that got lost)

crabbone 2y ago

Why I agree with many points you make... let's keep Perforce out of it. The amount of damage that program done to my source code, and the amount of pain caused by it in daily use tells me that 10 minutes will not cut it. Here's a simple example of how people shoot themselves in the foot with Perforce all the time: it makes files you edit read-only, and then you run with your pants on fire trying to figure out how to save your changes, because the system won't let you do that. And then you do something dumb, like copy the contents of the file you aren't able to save someplace else, and then try to incorporate those changes back once you've dealt with the file that Perforce wouldn't save. And then end up with a merge conflict just working with your one single change that you are trying to add to your branch. I never regretted never having to touch Perforce ever again. Just no.

maccard 2y ago
Why does git get a free pass for shitty defaults but perforce doesn’t? Perforce long predates git, and the checkout operation (which can be done on save with any modern editor) fixes that immediately.
- jayd16 2y ago
  Have you actually used P4 in anger? Having to add P4 support to any script, sucks. Having to do a network operation when touching files, sucks. Many many many apps have no idea what p4 is and will never get p4 support. Git gets out of the way.
  - maccard 2y ago
    > Have you actually used P4 in anger? Yes. I use it every day. I've ran P4 servers that serve hundreds of GBs per day globally with both commit edges and regular proxies. I've written batch scripts, bash scripts, and tooling in python, go and C# around it. > Having to add P4 support to any script, sucks. I disagree. It's no worse than adding git support to something. p4 zTag isn't the most elegant thing, but it works. > Having to do a network operation when touching files, sucks. Does it? Is it any worse than having to keep the entire history of every file locally on your machine, including any "large files?" And git-lfs as a solution to that means you're now coupled to wherever those files are stored. Making large submits to P4 isn't the nicest experience, but it sure beats paying that price every time you clone a repo IMO. > Many many many apps have no idea what p4 is and will never get p4 support In the same way that many people in this thread are blaming a git gui for a problem, "that's not P4's fault". I do agree it's shit though. > Git gets out of the way. Until it doesn't.