John Keeping <j...@keeping.me.uk> writes: > OK - given this reasoning I agree that --fork-point makes sense. > > I think this would have been clearer if the short description said > something like: > > Find the point at which a branch forked from another branch; this > does not just look for the common ancestor of the two commits but > also takes into account the reflog of <ref> to see if the branch > forked from an earlier incarnation.
That's much easier to read. Will squash the following in (I do want to make sure that it is clear that <commit> does not have to be at the tip, and also <ref> does not have to be a branch---it could be any ref). Thanks. --fork-point:: - Given a commit that is derived from possibly an earlier - incarnation of a ref, find an appropriate fork-point of the - derived history to rebase it on top of an updated base - history (see discussion on this mode below). + Find the point at which a branch (or any history that leads + to <commit>) forked from another branch (or any reference) + <ref>. This does not just look for the common ancestor of + the two commits, but also takes into account the reflog of + <ref> to see if the history leading to <commit> forked from + an earlier incarnation of the branch <ref> (see discussion + on this mode below). OPTIONS ------- -- 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
