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

> "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.