From: Junio C Hamano <gitster@pobox.com>
To: Thomas Rast <trast@student.ethz.ch>
Cc: git@vger.kernel.org
Subject: Re: [RFC PATCH] Documentation: new upstream rebase recovery section in git-rebase
Date: Tue, 02 Sep 2008 14:39:28 -0700 [thread overview]
Message-ID: <7vvdxei5wv.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <1220386721-10215-1-git-send-email-trast@student.ethz.ch> (Thomas Rast's message of "Tue, 2 Sep 2008 22:18:41 +0200")
Thomas Rast <trast@student.ethz.ch> 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
next prev parent reply other threads:[~2008-09-02 21:40 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-02 20:18 [RFC PATCH] Documentation: new upstream rebase recovery section in git-rebase Thomas Rast
2008-09-02 21:39 ` Junio C Hamano [this message]
2008-09-03 5:38 ` Thomas Rast
2008-09-11 15:38 ` [PATCH 0/2.5] " Thomas Rast
2008-09-11 15:38 ` [PATCH 1/2] " Thomas Rast
2008-09-11 15:38 ` [PATCH 2/2] Documentation: Refer to git-rebase(1) to warn against rewriting Thomas Rast
2008-09-11 15:39 ` [RFC PATCH] Documentation: add manpage about workflows Thomas Rast
2008-09-11 16:37 ` Jakub Narebski
2008-09-12 7:26 ` [RFH] Asciidoc non-example blocks [was: Re: [RFC PATCH] Documentation: add manpage about workflows] Thomas Rast
2008-09-20 0:22 ` [RFC PATCH] Documentation: add manpage about workflows Santi Béjar
2008-09-21 20:26 ` Dmitry Potapov
2008-09-30 16:05 ` Thomas Rast
2008-09-30 16:07 ` Thomas Rast
2008-10-01 9:54 ` Santi Béjar
2008-10-09 11:42 ` [RFC PATCH v2] " Thomas Rast
2008-10-09 11:42 ` [Interdiff] " Thomas Rast
2008-10-09 12:50 ` Junio C Hamano
2008-10-19 15:20 ` [RFC PATCH v3] " Thomas Rast
2008-10-19 15:20 ` [Interdiff] " Thomas Rast
2008-10-19 20:07 ` Junio C Hamano
2008-09-12 1:15 ` [PATCH 1/2] Documentation: new upstream rebase recovery section in git-rebase Marcus Griep
2008-09-13 5:08 ` Junio C Hamano
2008-09-13 16:10 ` [PATCH 0/3] Documentation: rebase and workflows Thomas Rast
2008-09-13 16:11 ` [PATCH 1/3] Documentation: new upstream rebase recovery section in git-rebase Thomas Rast
2008-09-13 16:11 ` [PATCH 2/3] Documentation: Refer to git-rebase(1) to warn against rewriting Thomas Rast
2008-09-13 16:11 ` [PATCH 3/3] Documentation: add manpage about workflows Thomas Rast
2008-09-13 16:11 ` Interdiff: [3/3] " Thomas Rast
2008-09-08 22:55 ` [RFC PATCH] Documentation: new upstream rebase recovery section in git-rebase Junio C Hamano
2008-09-09 5:42 ` Thomas Rast
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vvdxei5wv.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=trast@student.ethz.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.