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

41–50 of 58 posts

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

#41

Post by twodave »

kazinator wrote: post #29
acallaghan wrote: post #21

Earlier quoted context omitted.

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

I wouldn’t say it serves no purpose. It is useful when rewrites are tolerable and loss of history is not. It’s the default when using tools like jj, because the expected workflow wraps git in a way that force pushes are frequent and expected, but blowing away someone else’s work by mistake is not.

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

#42

Post by kazinator »

Sohcahtoa82 wrote: post #38
kazinator wrote: post #31

Earlier quoted context omitted.

The point is that some organizations have a chaotic development process consisting of numerous similar branches. Often there is a main trunk, and then branches that were made for particular product variants (like piece of hardware or whatever) and cut at a particular point in time, in order to isolate from the trunk. What then happens is that when a bug is found that affects all branches, it must be cherry picked int…

> Often there is a main trunk, and then branches that were made for particular product variants (like piece of hardware or whatever) I worked at a place that did this. The code was written in C, and I always thought the better solution would have been to use #define/#ifdef to flag certain blocks of code out of the compilation. A branch for each product was a nightmare when there were 10+ products, some with multiple…

Yes; #ifdef and #endif is basically branching, but it's in one branch of the CM system.

The benefit that everything is integrated, so there are no games with having to cherry pick things this way and that and losing fixes.

The apparent downside is that there is no isolation. Inside some of those #ifdefs is code that you are not building. But changes you are making can break that code for someone else.

While this may seem risky, it's actually better. Breaking something now is better than someone cherry picking your fix 8 months later into their branch and then dealing with the breakage.

Fixes to common code never get left behind; everyone working off the trunk instantly gets them.

The #ifdefs are immediately and constantly visible, telling you where the code is that is or is not part of what you are doing, and reminding you of its existence. They greatly discourage refactoring parts that you cannot test.

There is pressure to keep those #ifdefs clean, whereas people go hog wild when they have their own branch, thinking they can rewrite whatever they want to suit what they are doing.

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

#43

Post by 0123456789ABCDE »

Izkata wrote: post #13
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…

[pull] rebase = true Don't use this one unless you really know what you're doing. Multiple co-workers have gotten into really bizarre rebases because of it (like rebasing 70+ commits from master on top of their branch instead of the other way around), it seems to cause more problems than it solves. The man page for "git pull" even has a warning about using this flag.

trying to parse your comment, and the story is only getting more convoluted, the more i reread it.

"rebasing 70+ commits from master on top of their branch" is not a real thing

like, i want to believe you. it just doesn't work the way you're describing it.

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

#44

Post by Izkata »

0123456789ABCDE wrote: post #43
Izkata wrote: post #13

Earlier quoted context omitted.

[pull] rebase = true Don't use this one unless you really know what you're doing. Multiple co-workers have gotten into really bizarre rebases because of it (like rebasing 70+ commits from master on top of their branch instead of the other way around), it seems to cause more problems than it solves. The man page for "git pull" even has a warning about using this flag.

trying to parse your comment, and the story is only getting more convoluted, the more i reread it. "rebasing 70+ commits from master on top of their branch" is not a real thing like, i want to believe you. it just doesn't work the way you're describing it.

I didn't catch the exact commands they were doing, but their branch was made that far back, that's how it was that many commits.

Support was putting that setting in ~/.gitconfig for all new laptops, and we didn't know it was there. I saw one of them going through this huge rebase and was suspicious about how a pull was causing a rebase at all since this wasn't the default (and this particular co-worker wasn't the kind to explore these settings), so we went looking for it. After removing the setting, the command they were running worked exactly as expected without any surprises. They'd also said they thought they were using git wrong somehow because that wasn't the first time it happened.

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

#45

Post by nlawalker »

kazinator wrote: post #29
acallaghan wrote: post #21

Earlier quoted context omitted.

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

>If you are sure

--force-with-lease exists for the scenario where you are sure, but wrong.

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

#46

Post by kazinator »

nlawalker wrote: post #45
kazinator wrote: post #29

Earlier quoted context omitted.

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

>If you are sure --force-with-lease exists for the scenario where you are sure, but wrong.

I don't see how you could be wrong in knowing whether you're the only user with push access to the remote repo, or there are others.

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

#47

Post by 0123456789ABCDE »

Izkata wrote: post #44
0123456789ABCDE wrote: post #43

Earlier quoted context omitted.

trying to parse your comment, and the story is only getting more convoluted, the more i reread it. "rebasing 70+ commits from master on top of their branch" is not a real thing like, i want to believe you. it just doesn't work the way you're describing it.

I didn't catch the exact commands they were doing, but their branch was made that far back, that's how it was that many commits. Support was putting that setting in ~/.gitconfig for all new laptops, and we didn't know it was there. I saw one of them going through this huge rebase and was suspicious about how a pull was causing a rebase at all since this wasn't the default (and this particular co-worker wasn't the kin…

so, your colleagues merge features into `master` locally?

no pull-requests, no branch protections for `master`. i mean this works, but you probably need those rails in place.

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

#48

Post by Izkata »

0123456789ABCDE wrote: post #47
Izkata wrote: post #44

Earlier quoted context omitted.

I didn't catch the exact commands they were doing, but their branch was made that far back, that's how it was that many commits. Support was putting that setting in ~/.gitconfig for all new laptops, and we didn't know it was there. I saw one of them going through this huge rebase and was suspicious about how a pull was causing a rebase at all since this wasn't the default (and this particular co-worker wasn't the kin…

so, your colleagues merge features into `master` locally? no pull-requests, no branch protections for `master`. i mean this works, but you probably need those rails in place.

No, master is protected. I think they were trying to update their local master so they could resolve a merge conflict.

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

#49

Post by dolni »

lelandfe wrote: post #22
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)

Squash merging PRs makes your commit log is far less useful.

The PR reviewer isn't the only person who will ever review your code, you know.

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

#50

Post by bathtub365 »

kazinator wrote: post #46
nlawalker wrote: post #45

Earlier quoted context omitted.

>If you are sure --force-with-lease exists for the scenario where you are sure, but wrong.

I don't see how you could be wrong in knowing whether you're the only user with push access to the remote repo, or there are others.

You could have multiple computers, checkouts, or worktrees pointing at the same branch
Post reply on HN