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

On Sun, Nov 25, 2007 at 02:42:08PM -0800, Junio C Hamano wrote:

"J. Bruce Fields" [off-list ref] writes:

quoted

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.