mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <>
To: Ivan Chernyavsky <>
Cc: Duy Nguyen <>, Git Mailing List <>
Subject: Re: Which branch(es) contain certain commits? (was Re: (unknown))
Date: Fri, 21 Aug 2015 15:39:46 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <> (Ivan Chernyavsky's message of "Sat, 22 Aug 2015 00:29:59 +0300")

Ivan Chernyavsky <> writes:

> But now I had a look on the source and I can see that builtin/branch.c
> builds the list of references and prints them in a single place
> (print_ref_list()) so I will have to split that function into two in
> order to reuse existing functionality.
> Another problem is that builtin/branch.c currently does not use
> setup_revisions(), so I'll have to hook it there as well.
> Then, I assume, I'll need to use the initial ref_list (filled the same
> as for the current "list" case) to configure the rev_info structure
> after setup_revisions(), and start revision traversal.
> I'm not sure I've got it all right from the source in those few days,
> so I apologize in advance if it's stupid in some part or as a whole.

Heh, you say "problem" above, but I do not think it is a "problem"
per-se.  If you want to teach branch some preprocessing based on the
revision traversal API, you naturally need to call setup_revisions().

The outlined steps above all feel sensible; one thing you did not
mention is that you may probably have to clear object flags after
you are done with the initial "--grep" revision traversal, as some
features of branch may want to use the object flags (e.g. --merged
would use in_merge_bases()).  Other than that, all of it sounds
easily implementable.

Note that "branch --list", "tag --list" and "for-each-ref" are being
revamped to share more internal code.  If you want to pursue this,
you probably would want to build on top of that effort once it is
done.  That way, you may get "tag --grep=FIX123" for free.

> That said, do you think the goal is worth such changes?

That is a dangerous question.  As Duy already said,

> Probably because nobody is interested and steps up to do it. The lack
> of response to you mail is a sign.

apparently not many people thought it is worth; otherwise we would
already have such a feature.

If you are asking me personally, I'm sorry but I have to say no.

The reason why I personally do not think your "branch --grep=FIX123"
would be very useful to me is because I would imagine that I would
be interested in learning the exact commit that mentions FIX123 as
well as which branches contain it, if I had a need for such a

That is, it would inherently be two step process for me anyway, i.e.

 (1) I'd run "log -p --grep" to find which commits are about FIX123
     and check that what they did indeed make sense; and

 (2) I'd then run "branch --contains" to learn which ones are
     already up to date with respect to the fix.

Your "branch --grep=FIX123" that only tells me the names of branches
would have no use in that workflow, as it would not even give me an
indication that the request --grep=FIX123 found the right commit in
the first place.

  reply	other threads:[~2015-08-21 22:40 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-05 12:47 (unknown) Ivan Chernyavsky
2015-08-05 17:03 ` Which branch(es) contain certain commits? (was Re: (unknown)) Junio C Hamano
2015-08-05 17:05   ` Junio C Hamano
2015-08-05 19:48     ` Ivan Chernyavsky
2015-08-15  9:19 ` Duy Nguyen
2015-08-17  6:45   ` Which branch(es) contain certain commits? (was Re: (unknown)) Ivan Chernyavsky
2015-08-17 17:49   ` Junio C Hamano
2015-08-21 21:29     ` Which branch(es) contain certain commits? (was Re: (unknown)) Ivan Chernyavsky
2015-08-21 22:39       ` Junio C Hamano [this message]
2015-08-22  9:19         ` Ivan Chernyavsky
2015-08-22 10:32           ` Ivan Chernyavsky
2015-08-22 10:59           ` Karthik Nayak

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:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \

* 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.
Code repositories for project(s) associated with this public inbox

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 read-only IMAP folder(s) and NNTP newsgroup(s).