6 ms·

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

by beej71 2y ago

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.

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

by beej71 2y ago

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

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.