From: John Keeping Date: Tue, 29 Oct 2013 08:51:11 GMT Subject: Re: [PATCH v3 2/2] merge-base: teach "--fork-point" mode Message-ID: <20131029085111.GA24023@serenity.lan> In-Reply-To: On Mon, Oct 28, 2013 at 12:13:22PM -0700, Junio C Hamano wrote: > John Keeping 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 to see if the branch forked from an earlier incarnation.