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
prev parent 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).