On 03/05/2014 08:18 PM, Junio C Hamano wrote:
> Jeff King <peff@xxxxxxxx> 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@xxxxxxxxxxxx
http://softwareswirl.blogspot.com/
--
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