John Keeping <john@xxxxxxxxxxxxx> 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. The other reason (of my two reasons) is because I do not think "finding the fork-point" will stay to be the _only_ feature that uses reflog in merge-base. When a next cool feature to compute something completely different from fork-point happens to be implemented by taking advantage of reflog data, what would we call it? -- 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