From: Christian Couder Date: Mon, 17 Dec 2012 13:43:59 GMT Subject: Re: [BUG] Cannot push some grafted branches Message-ID: In-Reply-To: <20121217114058.449cbc3c@chalon.bertin.fr> Hi Yann, On Mon, Dec 17, 2012 at 11:40 AM, Yann Dirson wrote: > On Mon, 17 Dec 2012 09:43:53 +0100 > Thomas Rast wrote: > >> Junio C Hamano 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 ..." 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 --parent --author --commiter ... > 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.