On Wed, Jul 2, 2014 at 11:34 AM, Jeff King <p...@peff.net> wrote:
> Have you tried "git describe --contains --all <commit>"?
>
> To some degree, I fear your question isn't something git can answer. If
> the branch containing the commit has been merged into other branches,
> then they all "contain" the commit. There is not really any reason to
> prefer one over the other ("describe --contains" will try to find the
> "closest" branch, but that is based on heuristics and is not necessarily
> well-defined).I have not tried that command. Note I mentioned named refs, so nameless branches I'm not worried about. Even if I merge branch A into branch B, branch A is still closest in terms of number of steps to get to the commit, because to get to the commit through B you have to cross over a merge commit. Basically the priority should be directness and distance. The more direct a branch is (i.e. the lesser number of merge commits it goes through to get to the commit) the more relevant it is. As a second condition, distance would be used in cases where the directness of it is the same. Sorting this in the log graph and seeing it visually (I could even use --simplify-by-decoration) would help me understand the topography of git's history relative to the commit(s) I specify. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
