Am 12/18/2012 12:00, schrieb Yann Dirson: > On Mon, 17 Dec 2012 13:14:56 -0800 > Junio C Hamano <gits...@pobox.com> wrote: > >> Andreas Schwab <sch...@linux-m68k.org> writes: >> >>> Christian Couder <christian.cou...@gmail.com> 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. -- Hannes -- 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
