Re: [PATCH v3 2/2] merge-base: teach "--fork-point" mode

From: John Keeping <john@keeping.me.uk>
Date: Oct 29, 2013, 08:51 UTC
Message-ID: <20131029085111.GA24023@serenity.lan>
In-Reply-To: <xmqq38nlfbu5.fsf@gitster.dls.corp.google.com>

On Mon, Oct 28, 2013 at 12:13:22PM -0700, Junio C Hamano wrote:

Show 18 quoted lines

> John Keeping <john@keeping.me.uk> writes:
> 
> > The --reflog name has the advantage that it makes clear that this is
> > looking at something more than the commit graph and I don't think
> > --fork-point does imply that.
> 
> I think I understand what you are saying, but that "more than the
> commit graph" part in your reasoning is exactly one of the two
> reasons why I do not think that it is a good idea to call it with
> "reflog" in its name.  The next round of update to the feature may
> find a better way to find the fork point than looking at the reflog.
> What the feature is meant to do, i.e. "find the fork point" can stay
> the same (i.e. people can use it in their script), while the way how
> the implementation achieves it (i.e. by looking at reflog) can
> evolve over time, and by not hardcoding "how" in the name, the users
> will benefit from the updated behaviour, without having to ask for a
> better heuristics by using a different option by updating all of
> their scripts.

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.