On Tue, 18 Dec 2012 13:49:44 +0100 Thomas Rast <trast@xxxxxxxxxxx> wrote: > Johannes Sixt <j.sixt@xxxxxxxxxxxxx> writes: > > > Am 12/18/2012 12:00, schrieb Yann Dirson: > >> On Mon, 17 Dec 2012 13:14:56 -0800 > >> Junio C Hamano <gitster@xxxxxxxxx> wrote: > >> > >>> Andreas Schwab <schwab@xxxxxxxxxxxxxx> writes: > >>> > >>>> Christian Couder <christian.couder@xxxxxxxxx> writes: > >>>> > >>>>> Yeah, at one point I wanted to have a command that created to craft a > >>>>> new commit based on an existing one. > >>>> > >>>> This isn't hard to do, you only have to resort to plumbing: > >>>> > >>>> $ git cat-file commit fef11965da875c105c40f1a9550af1f5e34a6e62 | > >>>> sed > >>>> s/bfae342c973b0be3c9e99d3d86ed2e6b152b4a6b/790c83cda92f95f1b4b91e2ddc056a52a99a055d/ > >>>> | git hash-object -t commit --stdin -w > >>>> bb45cc6356eac6c7fa432965090045306dab7026 > >>> > >>> Good. I do not think an extra special-purpose command is welcome > >>> here. > >> > >> Well, I'm not sure this is intuitive enough to be useful to the average user :) > > > > When I played with git-replace in the past, I imagined that it could be > > > > git replace <object> --commit ...commit options... > > > > that would do the trick. > > > > We could implement it with a git-replace--commit helper script that > > generates the replacement commit using the ...commit options... (to be > > defined what this should be), and git-replace would just pick its output > > (the SHA1 of the generated commit) as a substitute for the <replacement> > > argument that would have to be given without the --commit option. > > I wouldn't even want a script -- we'd end up inventing a complicated > command-line editor for what can simply be done by judicious use of an > actual text editor. How about something like the following? Well, while it does the job, it is still hardly as straightforward as the old "vi .git/info/grafts", or as a single easily-remembered commandline. I was again thinking the only commandline stuff that does not exist currently in git-commit is specifying parents. One possiblity would be to add such an option to git-commit, together with a --replace flag that would cause the new commit to attached a replace ref (not completely unlike --append, in that we're doing some non-default action instead of just adding the changes to a new commit). But well, I don't think we would want to add to git-commit the ability of playing with something else than what's in the index/worktree. Abstracting the commit commandline to make it reusable by a git-replace--commit and possibly other tools that may want to rw-manipulate arbitrary commits could make sense ? > > Documentation/git-replace.txt | 21 +++++++++++++++++++++ > 1 file changed, 21 insertions(+) > > diff --git i/Documentation/git-replace.txt w/Documentation/git-replace.txt > index 51131d0..2502118 100644 > --- i/Documentation/git-replace.txt > +++ w/Documentation/git-replace.txt > @@ -61,6 +61,27 @@ OPTIONS > Typing "git replace" without arguments, also lists all replace > refs. > > + > +EXAMPLE > +------- > + > +Replacements (and before them, grafts) are often used to replace the > +parent list of a commit. Since commits are stored in a human-readable > +format, you can in fact change any property using the following > +recipe: > + > +------------------------------------------------ > +$ git cat-file commit original_commit >tmp > +$ vi tmp > +------------------------------------------------ > +In the editor, adjust the commit as needed. For example, you can edit > +the parent lists by adding/removing lines starting with "parent". > +When done, replace the original commit with the edited one: > +------------------------------------------------ > +$ git replace original_commit $(git hash-object -w tmp) You probably meant "-t commit" - a sign that it's not so trivial to forge ? > +------------------------------------------------ > + > + > BUGS > ---- > Comparing blobs or trees that have been replaced with those that > > -- Yann Dirson - Bertin Technologies -- 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