Hacker News Reader

Comment by epmatsw | Hacker News Reader

But how can you know it's safe in a collaborative project? What if someone else merges a PR right before you push?

--force-with-lease instead of --force. It does the same thing as force but checks to make sure the branch hasn't changed since you fetched it. Still very likely to piss off your co-workers, though.

This.

The problem is not if someone merges a PR before you push, but if someone branches off of the current tip of master, works on it, you remove that tip, and your colleague now is based on a history that doesn't exist, has to resolve your conflicts.

They're the same conflicts they'd have to fix if I pushed a new commit or merged a PR; assuming I made the same changes to code when I force pushed.

1. Rebase onto master.

2. Pull master just before you push.

3. If there are new commits, rebase onto master again.

If everyone on the team follows these 3 rules, it won't get too messy to untangle.

Unless I'm missing something, there's a race condition between "check if there are new commits to pull before force pushing" and "new commits come in". This workflow might work for a very small team but for a larger team it is bound to cause problems.

He may have editted his comment, but it doesnt mention `force`. As written, there is no race condition.

Right. As logn as you døn't force-push, then you can rebase until the problems are all gone. Although, this 3-step solution works best with proper team communication and planning.

You've probably seen it in other comments, but if not, `--force-with-lease`

`git push --force-with-lease`

You can use chat. Say "@channel I need to fix to master, nobody merge for a minute".

Bluff ;) - tell them they did something wrong. It's their fault. They don't know how to use git.

There's an xkcd about this I think.

Reply on news.ycombinator.com