Re: [PATCH 4/4] Add git-rewrite-commits

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi,

On Mon, 9 Jul 2007, Jeff King wrote:

> On Mon, Jul 09, 2007 at 12:56:04AM +0100, Johannes Schindelin wrote:
> 
> > But hey, maybe it _is_ time to rethink the whole filter business, and 
> > introduce some kind of regular expression based action language. Something 
> > like
> > 
> > 	git rewrite-commits -e '/^author Darl McBribe/skip-commit' \
> > 		-e 'substitute/^author Joahnnes/author Johannes/header' \
> > 		-e 'substitute/poreclain/porcelain/body' \
> > 		-e 'rewrite-commit-names'
> 
> This is starting to look an awful lot like sed.

Yep.  Fully intended.

> Which is good, but I wonder if we can get sed to do the heavy lifting. I 
> have had success with similar systems by writing the data structure out 
> into a canonical format, editing it as text, and then "applying" the 
> result.
> 
> Something like:
>   git rewrite-generate oldbranch |
>     sed 's/^author Darl McBribe/skip-commit/'
>     sed 's/^author Joahnnes/author Johannes/' |
>     git-rewrite-commit-names |
>     git rewrite-apply newbranch
> 
> where git-rewrite-generate would generate something like git-log output,
> and git-rewrite-apply would, given a log-ish input, write a new history
> branch. A nice advantage is that it makes things like this very natural:
>   git rewrite-generate oldbranch >history
>   vi history
>   git rewrite-apply newbranch <history
> 
> which allows interactive editing.

Granted.  It is a really nice idea, but again you lack the map function.

> Of course, this is:
>   - possibly inefficient, since rewrite-apply doesn't know what you
>     changed and what you didn't change; it would have to recalculate
>     a lot of sha1 hashes.
>   - doesn't really deal with actual tree rewriting, unless there is some
>     canonical text format for that, and then we are talking about making
>     things _really_ inefficient
> 
> Hmm. Which makes me think that maybe 'git-format-patch' is really
> git-rewrite-generate, and 'git-am' is really git-rewrite-apply (but with
> some extensions to preserve committer info).

Of course, you miss out the merge commits.

> So maybe a bad idea, but I thought I would throw it out there.

Not so bad.  What you describe as possibly inefficient has been 
implemented very, very efficiently already: git-fast-import!

So your idea brings me to another idea: Why not write git-fast-export?  
Actually, let's not all it that, since repo.or.cz has that name already 
(curiously enough, it is used for scripts exporting from _other_ SCMs, 
feeding to git-fast-import...), but git-fast-dump.

The output should be _exactly_ as expected by git-fast-import, so that 
"git fast-dump | git fast-import" would be a nop, data-wise.

Of course, there is a more fundamental problem with that approach: how to 
act on the commit message, conditional on the commit header?  I know, with 
perl it would be really easy.  But then you have to write a complete perl 
script, and the whole purpose of this 
admin-rewritehist/filter-branch/rewrite-commits frackass is that it should 
be _easy_ to use.

Ciao,
Dscho