Re: Find out on which branch a commit was originally made

[Artur Skawina <art.08.09@gmail.com>]

On 09/19/10 16:08, Stefan Haller wrote:
> Stefan Haller <lists@haller-berlin.de> wrote:
> 
>> Artur Skawina <art.08.09@gmail.com> wrote:
>>
>>> On 09/18/10 17:26, Stefan Haller wrote:
>>>> Ævar Arnfjör? Bjarmason <avarab@gmail.com> wrote:
>>>>>                      A---B---C topic
>>>>>                     /         \
>>>>>                D---E---F---G---H master
>>>
>>>> The question is the same though: if I hit commit B while blaming, how do
>>>> I know what topic it was a part of?  For that, I need to find commit H
>>>> which will tell me, right?  How do I do that?
>>>
>>> git rev-list --ancestry-path --merges --reverse B..master --format=oneline
>>
>> Thanks, this is helpful.  (However, my co-workers will probably laugh at
>> me if I suggest they remember a command such as this for what they think
>> should be a very simple operation.)
>>
>> There's a problem though for commits that are far back in history:
>>
>>                A---B---C topic
>>               /         \
>>          D---E---F---G---H---I---J---K---L---M---N master
>>                                   \         /
>>                                    O---P---Q another-topic
>>
>> Your command also shows M, which is not interesting at all in this
>> context.  Ideally it should stop at the first command that's common to
>> topic and master.
> 
> No, that's not what I need either.  After thinking about it more, I
> think what I want is "of all merges in the ancestry path from B to
> master, show only those whose first parent can't reach B."  The result
> is the list of all merges that were involved in bringing B to master.
> 
> Here's what I came up with:
> 
> #!/bin/sh
> 
> git rev-list --ancestry-path --merges --reverse "$1".."${2-master}" \
>   | while read ref
> do
>   if [ -z "$(git rev-list --ancestry-path "$1".."$ref"^)" ]
>   then
>     git --no-pager log -1 --pretty=oneline "$ref"
>   fi
> done
> 
> It's pretty inefficient, but seems to get the job done. Is there a
> smarter way to achieve the same?

This would work, and i don't see a way to optimize it in git-speak,
given that you don't want to see any extra trailing merges. At least,
not if it's supposed to be generic; consider a case where the 'topic'
merges another 'subtopic' and is then merged into a 'supertopic', which
is then merged to 'master'. Maybe somebody else has an idea?

For me, this seems like overkill, the merge list given by "git rev-list"
should be more than enough to figure out which branch the commit came
from. And if not - either your shell script or walking the history
("--parents" option) w/ a script would do. But i can't even imagine how
such a history would have to look like... 

artur