On Wed, Jul 2, 2014 at 11:34 AM, Jeff King <peff@xxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html