git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael J Gruber <git@drmicha.warpmail.net>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [WIP PATCH] revision-walk: --parent option to find children of a parent
Date: Thu, 30 Sep 2010 17:12:51 +0200	[thread overview]
Message-ID: <4CA4A8F3.3010805@drmicha.warpmail.net> (raw)
In-Reply-To: <20100930143234.GH4850@burratino>

Jonathan Nieder venit, vidit, dixit 09/30/2010 04:32 PM:
> 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.)

>> --- 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

      reply	other threads:[~2010-09-30 15:16 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-30 10:30 [WIP PATCH] revision-walk: --parent option to find children of a parent Michael J Gruber
2010-09-30 14:32 ` Jonathan Nieder
2010-09-30 15:12   ` Michael J Gruber [this message]

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=4CA4A8F3.3010805@drmicha.warpmail.net \
    --to=git@drmicha.warpmail.net \
    --cc=git@vger.kernel.org \
    --cc=jrnieder@gmail.com \
    /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).