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 - 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
