Re: [PATCH] disable grafts during fetch/push/bundle

[Michael Haggerty <mhagger@alum.mit.edu>]

On 03/05/2014 08:18 PM, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
> 
>> On Wed, Mar 05, 2014 at 10:49:24AM -0800, Junio C Hamano wrote:
>>
>>> ... the plan, at least in my mind, has always been exactly that: grafts
>>> were a nice little attempt but is broken---if you really wanted to
>>> muck with the history without rewriting (which is still discouraged,
>>> by the way), do not use "graft", but use "replace".
>>
>> I certainly had in the back of my mind that grafts were a lesser form of
>> "replace", and that eventually we could get rid of the former. Perhaps
>> my question should have been: "why haven't we deprecated grafts yet?".
> 
> Given that we discourage "grafts" strongly and "replace" less so
> (but still discourage it), telling the users that biting the bullet
> and rewriting the history is _the_ permanent solution, I think it is
> understandable why nobody has bothered to.

Replace objects are better than grafts in *almost* every dimension.  The
exception is that it is dead simple to create grafts, whereas I always
have to break open the man pages to remember how to create a replace
object that does the same thing.

So I think a helpful step towards deprecating grafts would be to offer a
couple of convenience features to help people kick the "grafts" habit:

* A tool that converts grafts (i.e., the grafts read from
$GIT_DIR/info/grafts) into the equivalent replacements.

* A tool that creates a new replacement object that is the equivalent of
a graft.  I.e., it should do, using replace references, the equivalent
of the following command:

      echo SHA1 [PARENT1...] >>$GIT_DIR/info/grafts

These features could be added to "git replace" or could be built into a
new "git grafts" command.

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/