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

51–58 of 58 posts

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

#51

Post by kazinator »

bathtub365 wrote: post #50
kazinator wrote: post #46

Earlier quoted context omitted.

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

You'd have to interrupt your own activity of synchronizing one of your downstream repos with your upstream, and force-publishing something back upstream, by switching to another one of the downstreams and publishing something into the upstream, which is then clobbered when you resume the original activity. Basically, split personality disorder where some of the personalities are not aware of the others.

All of this still overlooks the fact that the changes are not lost. Say someone (like one of the personalities in your head you don't know about) publishes a change which you unknowingly clobber with a "git push --force". That someone will notice when they fetch the repo: it has diverged from their clone and when they look at the history of master vs origin/master, they will see that their commit which they are sure they pushed does not appear in origin/master.

If you have multiple downstream checkouts and manage to clobber something with force pushes, you can recover. Then have a word with yourself and work smarter going forward.

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

#52

Post by acallaghan »

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…

My point is really that the default --force is dangerous for new/sleep deprived users, or ones that kinda understand but don't - where as --force-with-lease is not and is always safe. --force-with-lease should just be default

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

#53

Post by robertlagrant »

kazinator wrote: post #51
bathtub365 wrote: post #50

Earlier quoted context omitted.

You could have multiple computers, checkouts, or worktrees pointing at the same branch

You'd have to interrupt your own activity of synchronizing one of your downstream repos with your upstream, and force-publishing something back upstream, by switching to another one of the downstreams and publishing something into the upstream, which is then clobbered when you resume the original activity. Basically, split personality disorder where some of the personalities are not aware of the others. All of this s…

All force-with-lease does it stop you from clobbering rather than you having to realise somehow that you did that. It seems like a no-brainer. What's the problem with it?

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

#54

Post by jstimpfle »

Rebasing all the time will most likely result in intermediate commits that don't build anymore (because who builds all the intermediate commits after a rebase), and which don't make sense anymore as a "history" of changes.

So my simple resolution has become: don't rebase anything beyond trivial. I use rebase -i to merge, delete, or reorder individual commits on an insolated feature branch. Anything else? Not worth the effort in my opinion. Just merge, in any direction. I even merge between feature branches sometimes, though one must be aware that this essentially glues the two feature branches, meaning either both or none can get merged to master.

Something worth stressing: The most important commit is always the one HEAD points to. Older commits don't matter so much to the degree that cleaning them up later is wasted time. The most value of git commit graph comes as a support structure for git merge. In most cases, nobody gives a shit that all intermediate commits are perfect for some definition of "perfect". Most commits will never be read again.

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

#55

Post by lelandfe »

dolni wrote: post #49
lelandfe wrote: post #22

Earlier quoted context omitted.

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.

I felt similarly. But I'm also usually the only person Tim Pope'ing my commits.

If you police atomic feature branch PRs instead of atomic feature branch commits, though, things actually work out OK.

(By the way, the even more compelling next step to your argument is: pull requests aren't artifacts! I've worked on projects that have emigrated from GitHub, and was left with just the commit log)

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

#56

Post by [deleted] »

robertlagrant wrote: post #53
kazinator wrote: post #51

Earlier quoted context omitted.

You'd have to interrupt your own activity of synchronizing one of your downstream repos with your upstream, and force-publishing something back upstream, by switching to another one of the downstreams and publishing something into the upstream, which is then clobbered when you resume the original activity. Basically, split personality disorder where some of the personalities are not aware of the others. All of this s…

All force-with-lease does it stop you from clobbering rather than you having to realise somehow that you did that. It seems like a no-brainer. What's the problem with it?

[deleted]

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

#57

Post by kazinator »

robertlagrant wrote: post #53
kazinator wrote: post #51

Earlier quoted context omitted.

You'd have to interrupt your own activity of synchronizing one of your downstream repos with your upstream, and force-publishing something back upstream, by switching to another one of the downstreams and publishing something into the upstream, which is then clobbered when you resume the original activity. Basically, split personality disorder where some of the personalities are not aware of the others. All of this s…

All force-with-lease does it stop you from clobbering rather than you having to realise somehow that you did that. It seems like a no-brainer. What's the problem with it?

The only situations in which I would use a git push --force would be in which I have carefully considered what state the remote is in, and what state I want it to be be in, and I know that it's not a moving target it any way in between checking its state and doing the force.

Already, "git push" stops from clobbering: it warns that your proposed push is non-fast-forward and that you need --force.

If you are using git as intended, that's all the warning you need.

I understand that there are dubious workflows out there where a repo has multiple downstream users and they are all doing "git push --force", without coordinating with each other. They need a double force to make sure that they are clobbering what they think they are clobbering.

If that's not you (which it arguably shouldn't be, and certainly isn't me), you don't need to know about force-with-lease.

The only thing I would ever do with --force-with-lease is go "oh", and immediately repeat the command with --force, knowing that I'm in a situation in which the check is not applicable.

Even if the force were erasing a new commit that came from another repo, I would know that. Like I pushed something into upstream U from repo B, but I'm fixing the situation out of repo A which hasn't picked up the change. Yes, I know what I'm doing, that's why I'm using --force, and don't require --simon-says-force. I want the chain of commits I now have in A to be exactly what is in U, as a rare exception to normal git use. After I'm done from A, I will switch back to B, do a "git fetch" and probably "git reset --hard origin/master" to make B look like U.

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

#58

Post by robertlagrant »

kazinator wrote: post #57
robertlagrant wrote: post #53

Earlier quoted context omitted.

All force-with-lease does it stop you from clobbering rather than you having to realise somehow that you did that. It seems like a no-brainer. What's the problem with it?

The only situations in which I would use a git push --force would be in which I have carefully considered what state the remote is in, and what state I want it to be be in, and I know that it's not a moving target it any way in between checking its state and doing the force. Already, "git push" stops from clobbering: it warns that your proposed push is non-fast-forward and that you need --force. If you are using git…

Hm - I think I follow. But say I push a commit on a branch, then realise I messed up the commit message, so I --amend and push. I know that git push will fail, but if I git push -f then it won't detect that someone else pushed to the same branch in between - it'll just silently wipe their push.

Using --force-with-lease means the git push -f will succeed if no-one's pushed in between, and fail otherwise.

Post reply on HN