From: "Christian Couder" <chriscool@xxxxxxxxxxxxx>
From: "Philip Oakley" <philipoakley@xxxxxxx>
From: "Christian Couder" <chriscool@xxxxxxxxxxxxx>
The replaced object and the replacement object must be of the same
type.
-There is no other restriction on them.
+This restriction can be bypassed using `-f`.
Unless `-f` is given, the 'replace' reference must not yet exist.
+There is no other restriction on the replaced and replacement
objects.
Is this trying to allude to the fact that merge commits may be
exchanged with non-merge commits? I strongly believe that this
ability
to exchange merge and non-merge commits should be stated _explicitly_
to counteract the false beliefs that are listed out on the internet.
Maybe we can show that in an example. But I think the patch is quite
clear as it is and should be enough.
If we really want to correct some false beliefs, the best would be to
state the truth where those false beliefs are stated.
I've added a sub-comment to the original SO post that started this
thread (my post $gmane/231598 - SO/a/18027030/717355), but given the
guy's blog has comments going back to 2009 I suspect its a bit of a
http://xkcd.com/386/ task, hence my desire that it's explicitly
mentioned in the 'replace' documentation. In addition, if the guy
doesn't correct his post I'll mark it down in a couple of days to make
it plain to other readers it's in error.
The creation of a (merge?) commit that's equivalent to a graft line
isn't something that jumps out (to me) as an easy couple lines of bash
script.
A 'graft2replace' script (or 'git-graft' command) which takes an
existing graft file (or command line list) and creates the replacement
objects and then does the replace, all while still in a dirty tree would
be the holy grail for properly deprecating grafts (which are sooo easy
to create)
It's probably better stated in a separate patch for that explicit
purpose to avoid mixed messages within this commit.
If people agree, I will add a another patch with an example in an
EXAMPLE section.
Thanks,
Christian.
Thanks for your work on this.
Philip
--
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