On 2007.10.31 03:34:47 +0000, Johannes Schindelin wrote:
> Hi,
>
> On Wed, 31 Oct 2007, Björn Steinbrink wrote:
>
> > @@ -246,6 +292,13 @@ OPTIONS
> > Instead of ignoring merges, try to recreate them. This option
> > only works in interactive mode.
> >
> > +\--first-parent::
> > + Only follow the first parent commits in merge commits when looking
> > + for the commits that are to be rebased. This is most useful with -p
> > + as it will cause rebase to recreate the merges against the original
> > + branches instead of rebasing those branches as well. This option
> > + only works in interactive mode.
> > +
>
> Hmm. I had to read this several times to understand it. Maybe something
> like this instead?
>
> \--first-parent::
> When you want to preserve merges, this option allows you to rebase
> only the commits which were not merged in, i.e. which are in the
> first parent ancestry of the current HEAD.
> +
> This option only makes sense together with --preserve-merges.
Hm, I think that it might make might sense without -p. Say that your
topic branch is following two other branches like this:
---o---o---o--------o topicB
\ \
--o---A---o---o---o---o---B topicA
/ /
o---o---o---o---o master
topicB branched off from master earlier than topicA and you currently
require stuff from master..topicB _and_ topicB..master, so AFAICT, you
need sth. like the above.
Let's say that topicB simplifies some internal API and you desperately
wanted to use that, while master introduced some new stuff that you also
use. Now your stuff is finished, but it becomes obvious that topicB is
still too broken to go into master any time soon. Then you could do:
git rebase -i --first-parent master topicA
to get:
--o---o---o topicB (branched from master somewhere to the left)
o---o---o---A---B topicA
/
---o---o---o master
Depending on how much topicA really depends on topicB, you might need to
fix a bunch of stuff, but it might be worth it.
How about:
\--first-parent::
When this option is given and --preserve-merges is not, then
merge commits are completely ignored and only commits from the
first parent ancestry are rebased. This allows to pretend that
merges never happened.
If --preserve-merges is also given, the merge commits are
preserved, but only their first parent is rebased as opposed to
the default behaviour which would rebase all parents.
> Also, could you please add a test case to make sure that your patch works
> as advertised (and that this functionality will not be broken in future
> commits)?
Ok, might take some time, as I currently have no clue how the test stuff
for git works :-/ Well, I'm sure #git will be helpful :-)
Thanks,
Björn
-
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
