From: Thomas Rast <hidden> Date: 2016-06-15 22:55:32
Junio C Hamano [off-list ref] writes:
Yann Dirson [off-list ref] writes:
quoted
.... 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.
--
Thomas Rast
trast@{inf,student}.ethz.ch
On Mon, 17 Dec 2012 09:43:53 +0100
Thomas Rast [off-list ref] wrote:
Junio C Hamano [off-list ref] writes:
quoted
Yann Dirson [off-list ref] writes:
quoted
.... 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 a
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
From: Christian Couder <hidden> Date: 2016-06-15 22:55:32
Hi Yann,
On Mon, Dec 17, 2012 at 11:40 AM, Yann Dirson [off-list ref] wrote:
On Mon, 17 Dec 2012 09:43:53 +0100
Thomas Rast [off-list ref] wrote:
quoted
Junio C Hamano [off-list ref] writes:
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 a
new commit manually is a major step back in ease of use.
Yeah, at one point I wanted to have a command that created to craft a
new commit based on an existing one.
Perhaps it could be useful when using filter-branch or perhaps it
could reuse some filter-branch code.
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.
Yeah I wondered at one point if something like the following would do:
git replace --parent <parent1> --parent <parent2> --author <author>
--commiter <commiter> ... <orig-commit>
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.
It would not be straightforward to call it "graft" if it uses git replace.
Best,
Christian.
On Mon, 17 Dec 2012 14:43:59 +0100
Christian Couder [off-list ref] wrote:
Hi Yann,
On Mon, Dec 17, 2012 at 11:40 AM, Yann Dirson [off-list ref] wrote:
quoted
On Mon, 17 Dec 2012 09:43:53 +0100
Thomas Rast [off-list ref] wrote:
quoted
Junio C Hamano [off-list ref] writes:
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 a
new commit manually is a major step back in ease of use.
Yeah, at one point I wanted to have a command that created to craft a
new commit based on an existing one.
Perhaps it could be useful when using filter-branch or perhaps it
could reuse some filter-branch code.
quoted
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.
Yeah I wondered at one point if something like the following would do:
git replace --parent <parent1> --parent <parent2> --author <author>
--commiter <commiter> ... <orig-commit>
Yes, modification flags, that would only be allowed when the objects are commits,
and would cause creation of a replace commit that's <orig-commit> plus modifications.
We could then reuse the relevant options from git-commit, and add the missing --parent.
But wouldn't it stretch git-replace too much, to add commit-specific behaviour there ?
quoted
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.
It would not be straightforward to call it "graft" if it uses git replace.
Well, "git replace" would just be the "implementation detail". The idea would be to keep
the concept of a "graft", and just change its implementation. If we care (and we surely
do not, it's just a thought experiment ;), we could even provide, for pre-replace gits, a
"git graft" implementation that would manipulate info/grafts, together with a docpatch
saying that direct manipulation of info/grafts is deprecated.
--
Yann Dirson - Bertin Technologies