Re: [WIP PATCH 0/3] implement merge strategy for submodule links

From: Johan Herland <johan@herland.net>
Date: Jun 19, 2010, 13:15 UTC
Message-ID: <201006191515.25640.johan@herland.net>
In-Reply-To: <20100619101736.GA3539@book.hvoigt.net>

On Saturday 19 June 2010, Heiko Voigt wrote:

Show 19 quoted lines

> Hi,
> 
> On Fri, Jun 18, 2010 at 11:40:16AM +0200, Johan Herland wrote:
> > [1]: To put the search in general terms: Find all merge commits that
> > has _both_ (or in the case of octopus; _all_) of the candidate commits
> > (but none of the other merges) somewhere in its ancestry. You could
> > implement this by first intersecting the sets returned from these
> > commands (run in the
> > 
> > submodule):
> >   git rev-list --merges --ancestry-path --all ^B
> >   git rev-list --merges --ancestry-path --all ^F
> > 
> > to get the set of merges descending from both 'B' and 'F', and then
> > prune each member in the remaining set that has another set member in
> > its ancestry.
> 
> Is the --ancestry-path option already implemented? Because on my git
> 1.7.1 it does not seem to.

It was recently merged to 'next'.

> What does it do?

When given a commit range ("$from..$to", or "$to ^$from"), it shows commit that are in $to but not in $from (i.e. the usual), but additionally limits the list to those commits that descend from $from. Another use case for this functionality is, given a bug introduced in commit $foo, you can list the commit in the master branch that are potentially "contaminated" with the bug, with the following command:

  git log --ancestry-path $foo..master

See the --ancestry-path documentation in the jc/rev-list-ancestry-path series for more info.

...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net