On Sun, Nov 25, 2007 at 02:42:08PM -0800, Junio C Hamano wrote: > "J. Bruce Fields" <bfields@xxxxxxxxxxxx> 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. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
