On Thu, Mar 06, 2014 at 09:42:46AM +0100, Michael Haggerty wrote:
> 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:
I agree that better tool support would make "git replace" more pleasant
> * A tool that converts grafts (i.e., the grafts read from
> $GIT_DIR/info/grafts) into the equivalent replacements.
I don't know if this is strictly necessary, if we make your command
below pleasant to use. I.e., it should just be:
while read sha1 parents; do
git replace --graft $sha1 $parents
We can wrap that in "git replace --convert-grafts", but I do not think
grafts are so common that there would be a big demand for it.
> * 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.
I think it would be nice to have a set of "mode" options for
"git-replace" to do basic editing of a sha1 and install the result
(technically you could split the editing into a separate command, but I
do not see the point in editing a sha1 and then _not_ replacing it).
# pretty-print sha1 based on type, start $EDITOR, create a
# type-appropriate object from the result (e.g., using hash-object,
# mktree, or mktag), and then set up the object as a replacement for
git replace --edit SHA1
# ditto, but replace the $EDITOR step with the parent list
git replace --graft SHA1 PARENT1 PARENT2
# ...or remove entries from a tree
git replace --remove-entry SHA1 foo bar
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