22.08.2015, 01:39, "Junio C Hamano" <gitster@xxxxxxxxx>:
> Ivan Chernyavsky <camposer@xxxxxxxxx> writes:
>
>> Another problem is that builtin/branch.c currently does not use
>> setup_revisions(), so I'll have to hook it there as well.
>
> 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().
I meant "my problem" mostly ;) Yes I see git-branch currently has it's own way of doing things, I assume it avoids more heavy machinery from git-rev-list and friends.
> 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.
I still need to understand a lot how it all works. Any hint on where to look is appreciated. (I started from looking on builtin/shortlog.c just because it's one of the shortest ones using setup_revisions().)
One thing I'm worried about is that git-branch already has option --all. So we'll get a semantics conflict with setup_revisions() ("all branches" vs "all refs"). This will have to be treated carefully, e.g. retrace and fix effects of --all after setup_revisions() to include just branches but not other refs. Will such mangling be ok? Or could I prepare the call of setup_revisions() in a way that only branches will be included by --all? Anyway the semantics of --all will be different for git-branch and git-rev-list, but I believe more important is to keep it unchanged for git-branch.
> 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.
>
This is interesting. So can I have a look on some repo/branch or just wait until it'll be merged?
>> 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.
Yes, I see your point. But let me also explain my use case so it'll be probably more clear. Sorry if it's too long.
I work for HP as SCM and build manager for a product >15 years old. One of this product's greatest strenghts always was support for many old releases and customizations for particular users. So right now we are providing support for 10 subsequent releases (oldest one released back in 2006), and each release has 5 to 10 "customer" branches with their specific enhancements and fixes. (Though, as you would expect, all the fixes are generally merged to mainline, some customers are reluctant to apply fixes they don't need, so even here we must be flexible when preparing a patch.) So basically now I'm managing around 60 public branches in the repository.
SCM was ClearCase at the beginning, then StarTeam (whoa, complete disaster). At this point I joined the team and performed migration to Git last year (took a whole year). So now our history is a mixture of ancient baselines from ClearCase and artificial branches imported from StarTeam (thanks to my colleague who wrote a Git helper for StarTeam, https://github.com/AndreyPavlenko/git-st). So many changes which are 100% identical are represented by different commits, only identifiable with --cherry-pick option to git-log and friends. Even if I spent a great amount of time manually cutting and glueing history in Git to have the shortest logs.
And obviously, our workflow is based on cherry-picks, because very very often fixes and enhancements have to be merged *back* to many old customer branches. And you could immagine that when you port something to a codebase which is 5 years old, it rarely applies cleanly, so even --cherry-pick will not be able to identify it. And even if something is merged forward, it's only merged selectively when we are speaking about features and customer branches.
Supporting all this is a mess, as you could immagine. But that's what customers want, so I have no problem with that. After all, not every team has a dedicated SCM/build manager.
So quite often I or QA or support need to quickly find out, for example, which branches have specific enhancement or fix (ticket id) in their history. Commits which implement the actual feature or fix could be completely different, but the ticket id will be the same. True, it's not enough per se: you will still need to go and look into the branch. But having some initial set of branches is necessary anyway. And usually I trust our developers to mark their commits properly.
I had a look in the Internet before asking to this List, and I was a bit surprised to see that very few people really needed that. So I assumed that either I'm doing something wrong or we are really really special with our 10 years LTS, 60 public branches and cherry-picks. From your answers I tend to think that latter assumption is more correct.
Thanks a lot for your quick and detailed answers.
--
Ivan
--
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