Ivan Chernyavsky <camposer@xxxxxxxxx> 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
feature.
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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html