On Thu, Mar 6, 2014 at 9:42 AM, Michael Haggerty [off-list ref] wrote:
On 03/05/2014 08:18 PM, Junio C Hamano wrote:
quoted
Jeff King [off-list ref] writes:
quoted
On Wed, Mar 05, 2014 at 10:49:24AM -0800, Junio C Hamano wrote:
quoted
... 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
saying.
And I don't think "git grafts" is a good name. It looks too much like
we are encouraging people to use grafts.
Thanks,
Christian.