On Mon, 17 Dec 2012 09:43:53 +0100
Thomas Rast <tr...@student.ethz.ch> wrote:

> Junio C Hamano <gits...@pobox.com> writes:
> > Yann Dirson <dir...@bertin.fr> writes:
> >
> >> ....  In this respect, they seem to be
> >> lacking a few features, when compared to "replace" refs, but they have 
> >> different
> >> uses, ...
> >
> > Not reallyl; grafts were old hack whose use is still supported with
> > its original limitations; replace is meant to replace all uses of
> > grafts while removing grafts' largest warts.
> I suppose there's the additional issue that grafts are much easier to
> use than replacements if you really only want to replace some parent
> lists.  With replace you need to handcraft the replacement commits, and
> git-replace(1) unhelpfully does not say this, much less gives an example
> how to do it.

Right, replace refs can surely be made easier to use.  The requirement to craft 
new commit manually is a major step back in ease of use.

Maybe something like "git replace -p <orig-commit> <parent>..." to just provide 
a simple
API to the exact graft functionnality would be good.  But it would be 
commit-specific, whereas
replace refs are indeed more generic, and, one could want to rewrite any other 
part of the commit,
so we could prefer a more general mechanism.

Something that could be useful in this respect, would be an --amend like option 
to git-commit, like
"git commit --replace".  But unfortunately it does not allow to change parents, 
and it has the
drawback of requiring that HEAD points to the commit to be replaced.

So maybe, if there are no other idea, a simple "git graft" command that would 
wrap "git replace",
would fill the gap.

Yann Dirson - Bertin Technologies
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

Reply via email to