Re: What's cooking in git.git (topics)

[Junio C Hamano <gitster@pobox.com>]

"J. Bruce Fields" <bfields@fieldses.org> writes:

> Anyway, here's a first draft.
>
> --b.
>
> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> index 8355cce..7544715 100644
> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> ...
> +Normally whenever a branch head in a public repository is modified, it
> +is modified to point to a descendent of the commit that it pointed to
> +before.  By forcing a push in this situation, you break that convention.
> +(See <<problems-with-rewriting-history>>).
> +
> +Nevertheless, this is a common practice for people that need a simple
> +way to publish a work-in-progress patch series, and it is an acceptable
> +compromise as long as you warn other developers that this is how you
> +intend to manage the branch.

Note that modern git allows repository owners to forbid such a forced
non fast forward push at the receiving end.  In such a case, you cannot
even force a push.

Instead, you would need to fetch the current branch tip from the remote
and merge it into the branch you were tring to push, possibly using the
"ours" merge strategy, before pushing it again.  Use of "ours" merge in
such a case:

 - makes the next fetch by other people properly fast-forwarding;

 - records your admission of guilt: "I screwed up the last push and
   this is a replacement --- this is what I really should have pushed
   the last time".

 - makes the resulting tree exactly the same as what you tried to push
   unsuccessfully.  This is a valid substitute to a forced push in that
   it reverts the mistakes _you_ made with the previous push.