From: Michael J Gruber Date: Wed, 02 Jul 2008 18:34:49 GMT Subject: Re: RFC: grafts generalised Message-ID: In-Reply-To: <20080702182510.GC29559@glandium.org> Mike Hommey venit, vidit, dixit 02.07.2008 20:25: > On Wed, Jul 02, 2008 at 07:42:55PM +0200, Stephen R. van den Berg wrote: >> Michael J Gruber wrote: >>> Maybe the upcoming git-sequencer could be the appropriate place? It >>> tries to achieve just that: edit history by specifying a list of >>> commands. The currently planned set of commands would need to be >> That's the problem. Like git filter-branch, git sequencer needs you to >> parameterise the changes, which, in my case, is hardly possible, since >> the changes are randomlike. >> Also, having to run the sequencer to dig 20000 commits into the past, >> then change something, then come back up and rewrite all following >> history and relations (parents/tags/merges) will take a sizeable amount >> of time. I need something that can be changed at will, then viewed with >> gitk a second later. >> >> These edits are numerous and spread over many months, so the typical >> history fixup-sessions involve periods where you make 30 random >> historicaledits per hour (which need to be viewed and checked every time >> immediately after making the change). And say once every 4 months, you >> run it through git filter-branch to cast everything into stone. A >> typical git filter-branch run takes 15 minutes on a repository this >> size. > > I think the point was more about making a tool to do exactly what you > want, based on the new git sequencer. Note that git filter-branch could > also be rewritten to use the sequencer. Yes, that was at least my point. As I understand, git filter-branch -i is a candidate for that rewrite. But I understand now that OP wants to do lots of history edits and see them immediately before doing the actual (time consuming) rewrite; and then do the rewrite occasionally. Rewriting is surpirsingly slow even on tmpfs. Michael