Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Using Git's rerere feature to escape recurring conflict hell

gist.github.com

Post reply on HN
Print view View original

21–30 of 58 posts

Re: Using Git's rerere feature to escape recurring conflict hell

#21

Post by acallaghan »

dools wrote: post #5

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 completel…

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.

Re: Using Git's rerere feature to escape recurring conflict hell

#22

Post by lelandfe »

dools wrote: post #5

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 completel…

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)

Re: Using Git's rerere feature to escape recurring conflict hell

#23

Post by barbazoo »

mqus wrote: post #19
barbazoo wrote: post #9

Earlier quoted context omitted.

rerere is still useful here to handle merge conflicts after repeated rebases.

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…

I know what you mean but doesn't that require squashing as well? If I have a branch with 5 commits, I think rerere helps me by only having to fix the conflict once, not potentially multiple times. I might be wrong here though.

Re: Using Git's rerere feature to escape recurring conflict hell

#24

Post by skydhash »

convolvatron wrote: post #18
skydhash wrote: post #16

Earlier quoted context omitted.

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).

yes of course they should, that doesn't mean that integration branches aren't a good way to manage the tactical process. and often this kind of situation comes up when you're trying to do exactly that, introduce that abstraction that solves a whole bunch of issues, but requires cross-cutting changes. the problem comes up the other way too. the person making the refactor can get stuck in a perpetual hell of constantly…

I don’t remember which books exactly, but it was about legacy code. The author was talking about seams. If you’re trying to complete a refactor in one go, it will usually be arduous and maybe fail. What you want is to find seams in the codebase and maybe create some, where you can gradually decouple the architecture. After that you’ll have contracts and independent modules that can be reworked.

It’s not easy though and you need to have a very good understanding of the codebase. But the nice thing is that you can do it without having to maintain a long lived branch (which is an antipattern).

Re: Using Git's rerere feature to escape recurring conflict hell

#25

Post by sheept »

legorobot wrote: post #20
adithyassekhar wrote: post #8

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…

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-…

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.

Re: Using Git's rerere feature to escape recurring conflict hell

#26

Post by beart »

0123456789ABCDE wrote: post #2

#~/.config/git/config [rerere] enabled = true autoUpdate = true while you're editing git config, consider these: [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…

I believe push default simple is the default in git now and does not need to be explicitly set.

Re: Using Git's rerere feature to escape recurring conflict hell

#28

Post by nchmy »

mamcx wrote: post #15

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 wor…

No idea why this was downvoted. This is one of many ways in which jj is far better than raw dogging git

Re: Using Git's rerere feature to escape recurring conflict hell

#29

Post by kazinator »

acallaghan wrote: post #21
dools wrote: post #5

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 completel…

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-da…

--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.

Now it may be that --force-with-lease allows you to sneak in non-fast-forward changes without losing newly introduced upstream changes: but that assumes it's a good idea to be doing that sort of thing without communicating with your team. I.e. as long as we can sneak in a non-fast-forward change without accidentally/unknowingly deleting anyone's work, we are peachy; no need to coordinate.

Re: Using Git's rerere feature to escape recurring conflict hell

#30

Post by 0123456789ABCDE »

beart wrote: post #26
0123456789ABCDE wrote: post #2

#~/.config/git/config [rerere] enabled = true autoUpdate = true while you're editing git config, consider these: [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…

I believe push default simple is the default in git now and does not need to be explicitly set.

> This mode is the default since Git 2.0, and is the safest option suited for beginners.

the docs checkout, ty

Post reply on HN