From: Jakub Narebski <jnareb@gmail.com>
To: Junio C Hamano <junkio@cox.net>
Cc: git@vger.kernel.org
Subject: Re: [PATCH/RFC] Documentation: Two more git-rebase --onto examples
Date: Sun, 5 Nov 2006 11:22:17 +0100 [thread overview]
Message-ID: <200611051122.17623.jnareb@gmail.com> (raw)
In-Reply-To: <7vbqnmwvib.fsf@assigned-by-dhcp.cox.net>
Thanks for comments.
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> +More useful example of --onto option usage include transplanting feature
>> +branch from one development branch to other, for example change to branch
>> +based off "next" branch:
>
> By "more" do you mean the following examples are more useful
> than the one before, or having larger number of examples adds to
> the usefulness of the document overall?
I found original example somewhat artifical, but after thinking on that
I guess that the need for rebase onto master~1 might happen when the last
commit in master is for example to be amended or rebased.
The "transplanting branch" example feels like more natural to me.
> How about:
>
> Here is how you would transplant a topic branch based on one
> branch to another, to pretend that you forked the topic branch
> from the latter branch, using `rebase --onto`.
Perhaps adding why one might want to transplant topic branch from one
development branch to other: for example when feature being developed
on topic branch relied on functionality which was at the time topic branch
was started available only in 'next' branch, but meanwhile it matured and
was merged into 'master' (more stable) branch. One would want to base
topic branches on 'master' branch if possible.
[...]
> This looks the same as the original example for --onto; I would
> either drop it or replace it something of different flavor.
This example is from latest post by Andy Parkins, which asked how to
do that. But I find your example as being better, because it shows
even more power of core git history manipulation.
> What I find myself doing more is to reorder without using StGIT.
> When I have this:
>
> 1---2---3---4 topic
>
> and 2 is a bit half-baked, and I would want to have:
>
> 1---3'--4'--2' topic
[...]
Here I find lack of --interactive option to at least git-am based
rebase; git-rebase could simply pass --interactive option to git-am.
--
Jakub Narebski
next prev parent reply other threads:[~2006-11-05 10:21 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-04 21:05 [PATCH/RFC] Documentation: Two more git-rebase --onto examples Jakub Narebski
2006-11-05 1:08 ` Junio C Hamano
2006-11-05 10:22 ` Jakub Narebski [this message]
2006-11-06 18:12 ` [PATCH] Documentation: Transplanting branch with git-rebase --onto Jakub Narebski
2006-11-06 22:53 ` Junio C Hamano
2006-11-06 23:14 ` Jakub Narebski
2006-11-06 18:14 ` [PATCH/RFC] Documentation: Two more git-rebase --onto examples Carl Worth
2006-11-06 19:18 ` Junio C Hamano
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=200611051122.17623.jnareb@gmail.com \
--to=jnareb@gmail.com \
--cc=git@vger.kernel.org \
--cc=junkio@cox.net \
/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).