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

From: "J. Bruce Fields" <[email-masked]>
Date: Sun, 25 Nov 2007 23:08:55 +0000

On Sun, Nov 25, 2007 at 02:42:08PM -0800, Junio C Hamano wrote:
> "J. Bruce Fields" <[email-masked]> 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.

OK, that's interesting.  In a similar vein, I've been experimenting with
"merge -s ours" lately as a way to keep track of the "meta-history" of
an unsubmitted patch series in progress.  It seems a little hairy right
now, but maybe it'll turn out to be The Right Thing to do.

I don't want to deal with this in the manual yet.  For the sake of
keeping things simple, I'd rather first stick to the case of a public
repository set up by the user which the user controls.  And I think that
kind of use of "-s ours" is worth documenting but I'm not sure how to
deal with it yet.

--b.