Using Git's rerere feature to escape recurring conflict hell (gist.github.com)
75 points by ankitg12 10 hours ago
dools 4 hours ago
I never get conflicts during a merge because I only ever merge in one direction. I get all my conflicts on branches because I rebase before merging. I started doing this years and years ago because I kept coming across these mysterious silent regressions with my team. I searched something like "git merge silent regressions" and came across this stackoverflow answer:
https://stackoverflow.com/a/28510260
That completely fixed the problem. Now I only ever get conflicts on my feature branches. The rule is always: rebase away from main, and merge towards main. All conflicts are then on your branches, never on main, and always from rebase, never from merge. Then I set the pull behaviour to rebase, too.
I've never had a silent regression since, and never had a problematic conflict scenario.
I did recently learn about ORIG_HEAD though which was very cool, because I had accidentally rebased to main instead of to a dev branch from which I had created a bunch of worktrees, then when I merged back to the dev branch all hell broke loose, and I learned that I could revert a merge by checking out ORIG_HEAD:
acallaghan 2 hours ago
I'm also like this, rebasing feature branches onto main - I however have one suggestion when it comes to the push back up to origin
Instead of
`git push --force`
always use
`git push --force-with-lease`
https://git-scm.com/docs/git-push
This probably should be the default in git (as in there should be a `git push --force-without-lease` instead) and asks git to make sure the commits locally on your branch are up-to-date with those on remote/origin. It then fails if you try to overwrite commits that you haven't seen, and has saved me a few times when working between computers on the same project when i could have lost history on the remote that i failed to fetch.
kazinator 12 minutes ago
--force-with-lease serves no purpose.
If you are sure that the repo you are pushing to is a stable target (nobody else is accessing it), you just use --force.
If the repo you are pushing to is a moving target, you ... don't force push to it. Or else you warn all the repo users that you are about to rewrite history. Which means they not only should refrain from pushing, but have to be prepared for a second announcement which informs them that the rewrite is done; they must then fetch the rewritten head and fix up their unpublished work against the non-fast-forward change.
lelandfe 2 hours ago
If you squash merge PRs, this is equivalent to merging master back into your feature branch before merging to master.
I do that a lot to avoid commits mutating mid-review, so you avoid having to force push over reviewed commits (which is a sin)
barbazoo 2 hours ago
rerere is still useful here to handle merge conflicts after repeated rebases.
mqus 2 hours ago
As someone who tried rerere and didn't see the point:
How? Usually I rebase the same branch multiple times onto different, but successive commits of the master branch. But after I solved a bunch of conflicts of the first rebase, I shouldn't have the same conflicts again in a second one, since the rebased branch contains the merged conflict. Rebasing again could only turn up new conflicts (with newer, other commits on the master branch).
How can I have the same conflict again for repeated rebases?
kazinator 9 minutes ago
barbazoo an hour ago
techwizrd 2 hours ago
This is what I've been doing for years. It's remarkably stress-free!
ubercore 4 hours ago
I've never even seen someone suggest a rebase master onto feature workflow! TIL.
dools 3 hours ago
I think the terminology would be the other way around, like you're rebasing the feature onto the main:
git checkout feature
git rebase main
git checkout main
git merge feature
that way you get all your conflicts on the feature branch during rebase and your merge is always clean.
barbazoo 2 hours ago
> I get all my conflicts on branches because I rebase before merging
Pretty sure it's the other way around. You're on the branch and rebase it atop current master. If you merge after that, you won't have merge conflicts.
0123456789ABCDE 5 hours ago
#~/.config/git/config
[rerere]
enabled = true
autoUpdate = true
[pull]
rebase = true
[rebase]
autoSquash = true
autoStash = true
[merge]
# zdiff3 adds original text markers and removes matching lines from conflict regions
# https://git-scm.com/docs/git-config#Documentation/git-config.txt-mergeconflictStyle
conflictStyle = zdiff3
autoStash = true
[push]
autoSetupRemote = true
default = simple
[init]
defaultBranch = main0123456789ABCDE 2 hours ago
addendum
these are changes tacked to my git config over time. they're the result of working in a constant crunch state, where smooth forward move was more import than the state of the git history you left behind. these options remove small annoying road bumps. you should avoid some of them if you're working under different constraints, or the commit process differs such that these options don't apply.
it all starts with `pull.rebase=true` it makes `git pull --rebase` the default behavior. then comes `rebase.autoStash`, which just wraps the rebase with a stash push/pop envelop. if rebase is not your thing, and you prefer merge, `merge.autoStash=true` works the same. finally `push.autoSetupRemote=true` will skip asking you to set a remote tracking branch, it makes `git push` default to `git push --set-upstream`.
Izkata 2 hours ago
[pull]
rebase = true
The man page for "git pull" even has a warning about using this flag.
beart an hour ago
I believe push default simple is the default in git now and does not need to be explicitly set.
0123456789ABCDE 11 minutes ago
> This mode is the default since Git 2.0, and is the safest option suited for beginners.
the docs checkout, ty
adithyassekhar 3 hours ago
Do people really merge left and right between branches? Tell me if I got this wrong, this is how I work.
You got 4 devs. Each branched off from master. And we never merge from each other. Suppose 3 other people merged to master I pull it from master and fix only those conflicts. I’m not bringing your code into my branch unless it’s already finished and on master. If I need something you’re working on and it’s not on master when I need it, it’s a much larger planning issue.
If you have multiple environments before a stable master, do it only in one direction: feature > dev > staging > master. Don’t merge branches straight into staging or master.
I thought this was how everyone worked.
legorobot 2 hours ago
I thought this was how everyone worked.
I wish it were :)
This is the right way to do it. Whether using trunk-based development, git-flow, etc -- you're controlling the flow of merges in a particular direction.
However, I think the "larger planning issue" is harder to easily avoid when you have more devs, more changes, or the AI-boosted output we have today. If feature B requires feature A, and feature A isn't up-to-date with main, I could rebase feature A to main, then feature B to feature A. When feature A is merged and we're ready to PR feature B, I can rebase to main again then make my PR.
sheept an hour ago
That sounds like a lot of work. If you rebase A on main then B on main, you end up having to resolve A's conflicts on main twice. But if you stick with merge commits, A's conflicts are handled once in the merge from main.
powersjcb 2 hours ago
Yeah, I absolutely never run into this problem.
Sometimes we will have a huge stack of changes one of us is "finished but not clear to merge".
either:
- We just swap ownership of the branches and eng 2 now commits directly in branch 1. We review the final content together and typically pull in a 3rd person to review our combined work. Eng 1 either pairs with eng 2 until its finished or starts on a task that is decoupled from those changes.
- We use an integration branch that gets threated like the temporary master branch until the feature is ready to merge.
convolvatron 2 hours ago
when you're not just doing small patches (like Greenfield work), and you have multiple developers, it can be unreasonable and wasteful to do what you describe. say we're redoing the way memory management it being done, or changing a foundational api. A and B could go through master, but they'd have to redo a whole bunch of work. Or we could make an integration branch where A and B hash things out together and only push to master when their work is done. you can also see how this allows a lot more back and forth about the places where the designs interact rather than 'I got in master before you, so you get to eat a multi-day merge and I'm outta here'
this kind of interaction shows up more in a 'release' based model than CI environment, and one where the cost of testing is non-zero (because we're actually doing testing). I know that's not a very popular model, but not all software development is CI websites.
skydhash 2 hours ago
Those big refactoring should be discussed with the whole teams so everyone understands how they’re going to be affected. And rework like this should probably be hidden behind an abstraction (to do it gradually).
convolvatron 2 hours ago
davidelettieri 4 hours ago
I'm using these options https://blog.gitbutler.com/how-git-core-devs-configure-git and I'm happy with it
mamcx 2 hours ago
I use rerere when "forced" by team to use rebase. It not even work that much at the end (you can't control workflows outside yourself, that is why git ux is wrong: it desperately need total discipline).
THEN, I move to jujutsu. Only has a few problems at start trying to use it as git, but after get the idea, all fine.
BTW, this was with the same team and they never know, so JJ is in fact better: It survive OTHERS workflows.
kazinator 6 minutes ago
[delayed]
nchmy 40 minutes ago
No idea why this was downvoted. This is one of many ways in which jj is far better than raw dogging git
cautiouscat 4 hours ago
Every time I think I am adept in git, something like this is shown to me. I really should read into it more lol.