On 09/20/10 10:12, Stefan Haller wrote: > Seth Robertson <in-gitvger@xxxxxxxx> 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 -- 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