On Tue, 18 Dec 2012 08:09:35 -0800 Junio C Hamano <gitster@xxxxxxxxx> wrote: > Yann Dirson <dirson@xxxxxxxxx> writes: > > > 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 :) > > I do not understand why you even want to go in the harder route in > the first place, only to complicate things? Although the approach you propose is elegant, it still looks like one could not leave the worktree untouched in the case of creating a merge replace, which the "just forge an arbitrary commit" approach handles easily. It seems the latter would also be more powerful, in that you can create new commits with an arbitrary number of parents, even when merge-octopus would simply refuse to help; and it is has no special case for creating merges. > Is this not intuitive enough? I would say it is a nice read that can help an advanced user to earn some XP - but well, replace refs are also meant for somewhat advanced users :) -- 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