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

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

On 09/20/10 10:12, Stefan Haller wrote:
> Seth Robertson <in-gitvger@baka.org> wrote:

>>          -AA-- subtopic
>>         /     \
>>        A---B---C topic
>>       /         \
>>  D---E---F---G---H---I---J---K---L---M---N master
>>                           \         /
>>                            O---P---Q another-topic
>>
>>
>> In the above example, the subtopic branch merge from AA to C prevents
>> you from finding out what branch B is on using the original script.
> 
> When you say "the original script", are you talking about Artur's
> one-liner or my script?
> 
> My script gives me exactly the information I want in all cases.  For a
> given command $1 and a target branch $2, it shows you all merges that
> were involved in bringing $1 into $2. For example:
> 
>   Called with "B" "master", it returns H

No, it will return both C and H, just like my one-liner; this will be
misleading, the user won't be able to figure out where 'B" came from
w/o looking at the graph, from output like:

$ git-show-merges-since B master
C..... Merge branch 'subtopic' into topic
H..... Merge branch 'topic'

The results for 'B' and 'AA' will be exactly the same.

For 'B', the 'C' merge should be omitted; skipping it because 'B'
comes in via first parent would probably work, but i can't turn that
into a one-liner right now...


On 09/20/10 07:47, Seth Robertson wrote:
> I agree 100% that the right answer is topic for B and master for F.
> 
> I know how to get topic for B.  Finding master (and not another-topic)
> for F is difficult because we have to know something that I don't know
> how to get git to tell me: when another-topic branch was created.
> Using git-rev-parse another-topic....master we know what commit
> another-topic and master diverged, but I cannot figure out a way to
> discover which branch was created at that point and which branch
> pre-existed (obviously for master we know, but if this was a
> supertopic branch we would not).  I thought about using merge
> direction for subsequent merges as a hint, but we don't know if the
> second branch has been permanently been merged or not, if there was a
> K->P merge and Q-M did not happen (yet) then we would give the wrong
> branch name.

Oh, if there would be no 'Q->M' merge and both branches would still
be "live", 'both' is certainly the right answer.

If 'another-topic' was merged into another branch (like in the example
graph) and is dead at this point, i think skipping it is the correct
decision -- there could be many such branches and presenting a long
list of candidates won't really help the user.

Given history as in the graph and a /live/ 'another-topic' -- hmm, 
if there are just a few such refs maybe showing them would be ok.

artur