Hi, On Mon, 9 Jul 2007, Sven Verdoolaege wrote: > On Mon, Jul 09, 2007 at 01:57:10PM +0100, Johannes Schindelin wrote: > > > On Mon, 9 Jul 2007, Sven Verdoolaege wrote: > > > > > What if the commit message is larger than the pipe buffer? > > > > You start_command(). Then you write() until it is all written, or the > > pipe is broken. Then you get the output via index_pipe(). Which is a > > single sha1. I do not understand your question. > > Ah, but that is not how my commit "filter" works right now. It should > produce the whole commit on stdout (as mentioned in the documentation). > So the default filter is "cat" (and not "git-hash-object -t commit > --stdin", as you seem to assume). Sorry. Somehow I misread that index_pipe() for a read_pipe(). > How about I change that to a filter that accepts a single SHA1 and > produces zero or more SHA1's as output? > A filter for the current rewrite-commits would then be replaced > by "xargs | git-cat-file commit | original-filter | git-hash-object -t commit --stdin" You still have not addressed the fundamental problem! If the commit filter takes the things as a whole commit buffer or as a single sha1, or if it writes one, two or -1 commits is not really a fundamental problem. The real problem is that this filter can only act on _one_ commit. Yes, it wants to change only one commit at a time, but it might need information from _other_ commits, too! > > To enhance on the above example: you're rewriting the commit messages > > so that commit names are rewritten to match the rewritten commits. > > That is possible by a message filter in cg-admin-rewritehist. > > > > But now somebody comes along, and says "I have a history I need to > > rewrite. All bug fixes. The commit names were all abbreviated in the > > commit messages, but they always had 'commit ' in front of them. I > > want to rewrite them, too." > > The current git-rewrite-commits will rewrite all SHA1's it can find, > irrespective of any 'commit ' that may precede it. Even abbreviated ones? > > > What's wrong with --author='!Darl McBribe' ? > > > > It is a very special use case. Not always will you be able to get all > > the information from the commit object you need for conditional > > operations. My example only showed that you can do the same with that > > syntax. But imagine what you could do if we just added a small > > syntactical sugar: > > > > -e '?has-path:README?substitute/v2/v3/' > > So you want to introduce a whole language? > Isn't that a bit over-engineering? We already have a tool which is powerful enough to do that. Yes, it is a little complicated to operate, and yes, it is slower than your version. But darn it, it _does_ more than your version. It is a pity that you did not address the fundamental problem, so I have to spend time (that I should really spend differently) thinking about it. Alas, I think I have a solution. You need a flag: --write-sha1-mappings=<directory> Yes, it makes your code slower again, but only if you need those mappings. Yes, it is way less convenient than the "map" function, but then you could automatically write a script into that directory, providing the convenience functions, and exporting the path so that you can say --commit-filter '. "$G"; ... map "$sha1"' and also add convenience functions "save <varname>" and "restore <varname>" so that finally a bit of convenience is restored to the filter writers. But those are no longer fundamental problems. I'd be glad if you could put these suggestions to use in rewrite-commits. While at it, you should also change the semantics for the commit filter, probably even less so than you suggested: since you rewrite the parents, and the tree, you should continue to pipe this information into the commit filter. That would be another place for a convenience function "commit", which does the same as "git hash-object -w --stdin". Okay now. To be precise, here is my wish list: * rename the darned things to "filter" again. * --write-sha1-mappings=<directory> (or --write-commit-mappings), possibly defaulting to .git/mappings/. Be careful not to overwrite an existing such directory. * change the semantics of the commit filter: the output is a list (possibly empty) of replacement sha1's for this commit. * if any filters are called, provide a script with convenience functions, and an environment variable pointing to it. These functions should include: * map * commit * save * restore 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
