On 09/19/10 16:08, Stefan Haller wrote:
> Stefan Haller <lists@xxxxxxxxxxxxxxxx> wrote:
>
>> Artur Skawina <art.08.09@xxxxxxxxx> wrote:
>>
>>> On 09/18/10 17:26, Stefan Haller wrote:
>>>> Ãvar ArnfjÃr? Bjarmason <avarab@xxxxxxxxx> 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
--
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