On Thu, Mar 6, 2014 at 9:42 AM, Michael Haggerty <mhag...@alum.mit.edu> wrote:
> On 03/05/2014 08:18 PM, Junio C Hamano wrote:
>> Jeff King <p...@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.
Yeah, I sent a kind of rough draft of a script to do that last year to
the mailing list, but I didn't take the time to convert it to a real
script or command.
> * 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
Yeah, maybe it can be a "git create-replace-ref command" and it could
have a --convert-graft-file option to convert an existing graft file.
There have been discussions about such a command already some time ago.
> These features could be added to "git replace" or could be built into a
> new "git grafts" command.
I think Junio previously said that it was better if such features were
not part of "git replace". But maybe I misunderstood his subtle
And I don't think "git grafts" is a good name. It looks too much like
we are encouraging people to use grafts.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html