Re: [PATCH 5/6] rerere: let caller decide whether to renormalize

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 4, 2010, 18:12 UTC
Message-ID: <7vocdifdrk.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20100804032338.GF19699@burratino>

Jonathan Nieder <jrnieder@gmail.com> writes:

> NEEDSWORK: this is a step in the wrong direction.  rerere needs
> an -s option to use an arbitrary merge strategy and a -X option to
> pass arbitrary options to that driver.

If you are talking about "rerere", I strongly disagree with that.

1. "-s"

   A "merge strategy" deals with the shape of the history (e.g. common
   ancestor selection or synthesis for the purpose of 3-way merge) and the
   shape of the trees (e.g. rename detection, subtree shifting).  Starting
   from two commits, it decides, based on the shape of the history, what
   three trees your tree-level 3-way merge would operate on, and then
   based on the shape of the trees, decides the pairing of blobs to run
   the 3-way merge at the file-content level.

   When "rerere" is invoked, a strategy already has dealt with all of the
   above, and "rerere" only works on the (half-completed) result of that.
   It is purely a three-way merge at the file-contents level and there is
   no room for a "strategy" to get involved.  It makes direct calls to
   ll_merge() exactly for this reason.

2. "-X"

   In the "merge -X<opt>" syntax, "-X" does not stand for "low level
   details"; it just means "eXternal callout".  It is there just to tell
   the "merge" front-end "You may not understand this yourself, but the
   program you call does, so just pass it along".

   IOW, we want to be able to pass --<opt> through the frontend to the
   backend, without having to tell all the options any possible backends
   may know to the frontend.  Just to make it easier to parse and tell
   which ones are the front-end options and which ones are not (for both
   machines and humans), we say -X<opt> to the frontend.  Then "merge"
   turns that -X<opt> into "--<opt>" and give it to the strategy.

   A command that natively knows about an option is correct to take an
   option as "--<option>", e.g. "merge--recursive --renormalize".  You
   trigger it by saying "merge -Xrenormalize" from the frontend.

To recap: it is absolutely the right thing to do to introduce a new "rerere --renormalize" option, like your patch did. Doing anything else IS a step in the wrong direction.