Mike Hommey venit, vidit, dixit 02.07.2008 20:25:
quoted text
> 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

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html