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

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

On 09/20/10 01:54, Seth Robertson wrote:
> In message <4C9698C5.70607@gmail.com>, Artur Skawina writes:
> 
> On 09/20/10 00:03, Seth Robertson wrote:
>>>>>>                A---B---C topic
>>>>>>               /         \
>>>>>>          D---E---F---G---H---I---J---K---L---M---N master
>>>>>>                                   \         /
>>>>>>                                    O---P---Q another-topic
>>>
>>>>> 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.
>>>
>>>
>>>> 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. [...]
>>>
>>> The provided command actually doesn't work for me for all cases.  It
>>> works for the simple case of "B", but does not work for "F", because F
>>> saw merge H & M.  I think we need --not --first-parent, except that
>>
>> Well, F was never on a separate branch, so the command returning ""
>> is arguably the right thing.
> 
> I'd like a command that would tell me the right branch something was
> on whether it was on master or topic or whatever.  If instead of
> "master" the branch was named "supertopic" and master commit AA had
> child D would that make a difference?

Like i said, "arguably". In theory, no, there is no difference. In
practice, some branches will be more long-lived than others -- and
certain conventions will apply. Hence, i think that answer /is/ the
right one, in context -- that script was specifically looking for
info on /another/ branch.

>>> doesn't actually work in this case either.  However, if we get the
>>> full --first-parent rev-list and look for our commit, that works.
>>> This is incredibly painful, though.
>>> ----------------------------------------------------------------------
>>> #!/bin/sh
>>> TARGET=`git rev-list -n 1 $1`
>>> git branch -a --contains $1 | sed 's/^\** *//' | grep -v ' -> ' |
>>> while read br; do
>>>  if git rev-list --first-parent $br | grep -q "$TARGET"; then
>>>   echo $br
>>>  fi
>>> done
>>> ----------------------------------------------------------------------
> 
>> And it does not work if you no longer have the branches around...
> 
> If something doesn't have a name I am not very interested in it (for
> my purposes, your milage may vary).  Presumably the other code could be
> combined with my inner loop.
> 
>> But even if you kept all the old refs, this would return
>> "another-topic"+"master", which is hardly the right answer.
> 
> I'm not sure how you can figure out when a branch was first created.
> We might "know" that master is older than the others, but if this
> commit was on another-topic and supertopic we cannot use that
> intuition..
> 
> Returning all possible branch names at least gives the user somewhere
> to start and does not give them ones which are obviously insane.

If you want to find out on which branch a change was committed and
"master" is right for 'F', then the "another-topic" part of that
answer is problematic -- every commit on that branch is a descendant
of 'F", and so is everything in between $common_base ('J') and master.
If you /don't/ treat master as special (ie don't treat the first
parent as special) what is then the difference vs a simple
"git branch -a --contains F"?
IOW, why would the right answer for 'F' be both 'master' and
'another-topic', but for 'B' - just 'topic'?

artur