Re: [WIP PATCH] revision-walk: --parent option to find children of a parent

From: Michael J Gruber <git@drmicha.warpmail.net>
Date: Sep 30, 2010, 15:12 UTC
Message-ID: <4CA4A8F3.3010805@drmicha.warpmail.net>
In-Reply-To: <20100930143234.GH4850@burratino>

Jonathan Nieder venit, vidit, dixit 09/30/2010 04:32 PM:

Show 13 quoted lines

> Hi,
> 
> Michael J Gruber wrote:
> 
>> Introduce a new --parent=<commit> option for the revision walker which
>> limits the commits to those which have <commit> as one of their parents.
> 
> So this lists the direct children for a given commit.  Could you
> mention a use case?  Why would one want to use this instead of
> 
>  the_commit=$(git rev-parse --verify <commit>) &&
>  git rev-list --parents ... ^<commit> |
>  grep -F " $the_commit"

| cut -d' ' -f1 # or such :)

> 
> ?

Full disclosure: I didn't see that it can be scripted that easily, simply because the description of "--parents" does not indicate at all that it lists the commit along with its parents. I had the impression that it outputs the parents only (same goes for --children.) so that looping over the rev-list output would be required, which would have been much slower.

As a use case, it not only tells you whether a specific commit is a fork point, it's also a reverse of "rev-parse commit^@", so to say.

Personally, this was some exercise with the revision walker before approaching something else there.

[It also helps with "Heck, I committed on top of a detached origin/next yesterday, how did I tag that commit.", but there are other solutions, of course...]

Speaking of that: It helps you "going forward(!)" from a commit that you checked out (maybe for inspection). Just imagine trying to understand a history by checking out versions iteratively. Say, you want to review the last 10 revs, do a "checkout HEAD~10", then a "checkout HEAD~9" and notice that's not quite the way to do it... (Again, there are alternatives, of course.)

Show 9 quoted lines

>> --- a/revision.c
>> +++ b/revision.c
>> @@ -1149,6 +1149,7 @@ static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg
>>  {
>>  	const char *arg = argv[0];
>>  	const char *optarg;
>> +	unsigned char sha1[20];
> 
> Could this be given narrower scope?

Sure! I expected more rough edges (and some resistance) which is why I sent a WIP first.

Michael