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