From: Junio C Hamano <gitster@pobox.com>
To: "Robert P. J. Day" <rpjday@crashcourse.ca>
Cc: Git Mailing list <git@vger.kernel.org>
Subject: Re: worth enhancing "man git-rebase" to show non-HEAD examples?
Date: Tue, 05 Mar 2019 22:10:56 +0900 [thread overview]
Message-ID: <xmqqef7lv53z.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <alpine.LFD.2.21.1903040955540.16666@localhost.localdomain> (Robert P. J. Day's message of "Mon, 4 Mar 2019 10:01:32 -0500 (EST)")
"Robert P. J. Day" <rpjday@crashcourse.ca> writes:
> one of the things i've noticed about the examples in "man
> git-rebase" is that they invariably show rebasing relative to a
> branch point that has not moved. for example, there's this example:
>
> o---o---o---o---o master
> \
> o---o---o---o---o next
> \
> o---o---o topic
>
> with subsequent sample command:
>
> $ git rebase --onto master next topic
>
> sure, that works, but there seem to be no examples that show that this
> is a valid starting point as well:
>
>
> o---o---o---o---o master
> \
> o---o---o---o---o next
> \
> o---o---o topic
You mean that the 'topic' forked from 'next', and it is OK for 'next'
to acquire further commits since 'topic' forked from it, for you to
rebase 'topic' on another history?
The very first example in Documentation/git-rebase.txt shows a
3-commit topic A-B-C, forked from the master branch at E in 4-commit
D-E-F-G sequence, gets rebased. Those F and G are in the same place
as those rightmost two commits you have on 'next' in the above
picture.
> as in, the examples in that man page could potentially suggest to an
> inexperienced reader that the *only* valid situations are rebasing as
> long as the other branch has not developed any further. (yes, i
> realize that, if you read carefully, it *should* make it clear, but i
> think it would be helpful to at least graphically show that
> happening.)
>
> thoughts?
So, we have both pictures, and I do not see there is much to add.
By the way, I sense a mis-perception that led you to say "... has
not developed any further". In the topology in your second
illustration, there is nothing to say that the rightmost two commits
on the 'next' branch were created _after_ topic has forked from
'next'. It is not just possible but also often is sensible to fork
a topic closer to what it needs to build on top of, limiting its
dependency as small as possible, so the 'topic' could have been
forked from the middle of 'next' branch when it was originally
created.
next prev parent reply other threads:[~2019-03-05 13:11 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-04 15:01 worth enhancing "man git-rebase" to show non-HEAD examples? Robert P. J. Day
2019-03-05 13:10 ` Junio C Hamano [this message]
2019-03-05 13:16 ` Robert P. J. Day
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=xmqqef7lv53z.fsf@gitster-ct.c.googlers.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=rpjday@crashcourse.ca \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).