Thomas Rast <trast@xxxxxxxxxxxxxxx> writes:
> I flagged it as RFC because I'd appreciate some feedback:
>
> - Are the warnings too repetitive? I fear that if we sound too
> protective, users won't listen.
>
> - Is it perhaps too verbose, or in the wrong place? I did not want to
> detract from the feature descriptions that the manpage should first
> and foremost contain. Chances that a user will "accidentally" read
> the section at this position and length seem fairly low however.
It feels on a bit too repetitive side, but I think this is going in the
right direction. How about dropping the earlier part of the change to
Notes section (but keep "See also" which is a good guide for understanding
the said "implications")?
> +HELP, MY UPSTREAM HAS REBASED!
> +------------------------------
I read this section only once, but it looked reasonable as a recovery
procedure to me.
The additions you made are all about why rebasing public history is bad
from mechanisms (overlapping changes made by old upstream history and new
upstream history, unless they are identical, will cause merge conflicts
between themselves that downstream will have hard time resolving) POV.
While that description is all good, I think there should also be a
discussion from the patchflow/workflow angle.
"Upstream has rebased" almost implies that it has its own upstream
(i.e. "My upstream" is not the toplevel upstream, but is a subsystem tree
or something).
Rebasing upstream is bad, but an upstream that backmerges from its own
upstream too often is equally bad, and the reason of the badness, viewed
from the workflow angle, shares exactly the same component.
It means that the mid-level upstream in question is not focused enough.
Cf.
http://article.gmane.org/gmane.linux.kernel/681763
http://article.gmane.org/gmane.linux.kernel/684030
http://article.gmane.org/gmane.linux.kernel/684073
http://article.gmane.org/gmane.linux.kernel/684091
http://article.gmane.org/gmane.linux.kernel/638511
--
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
