On Sat, Apr 8, 2017 at 5:03 PM, Stefan Haller <lists@xxxxxxxxxxxxxxxx> wrote: > Matt McCutchen <matt@xxxxxxxxxxxxxxxxx> wrote: > >> When I'm rewriting history, "git push --force-with-lease" is a nice >> safeguard compared to "git push --force", but it still assumes the >> remote-tracking ref gives the old state the user wants to overwrite. >> Tools that do an implicit fetch, assuming it to be a safe operation, >> may break this assumption. In the worst case, Visual Studio Code does >> an automatic fetch every 3 minutes by default [1], making >> --force-with-lease pretty much reduce to --force. >> >> For a safer workflow, "git push" would check against a separate "old" >> ref that isn't updated by "git fetch", but is updated by "git push" the >> same way the remote-tracking ref is and maybe also by commands that >> update the local branch to take into account remote changes (I'm not >> sure what reasonable scenarios there are, if any). > > Here's a rough proposal for how I would imagine this to work. > > For every local branch that has a remote tracking branch, git maintains > a new config entry branch.*.integrated, which records the sha1 of the > last upstream commit that was integrated into the local branch. Can you elaborate on what "integrate" means in this context? In some ways the entire point of this feature is that you're trying to push over history that you don't want to integrate. I.e. you're trying to force push your unrelated X over remote history A, but not more recent arbitrary history B based on A which someone may have just pushed. I'm having a hard time imagining how anything merge/rebase/whatever would place in branch.*.integrated wouldn't just be a roundabout way of recording the info we now record via the tracking branch, or in cases where that's auto-updated for some reason having another tracking branch as my "[PATCH] push: document & test --force-with-lease with multiple remotes" suggests. But maybe I'm just missing something obvious...