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
- 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).
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