Johannes Schindelin wrote:
quoted text
> I am really unhappy that so much is talked about filtering out commits.  
> That is amost certainly not what you want in most cases.  In particular, I 
> suspect that most users would expect the _changes_ filtered out by such a 
> command, which is just not true.
>   

I agree that unless it's named and documented very carefully, users 
might expect this to tweak history such that the commits in question 
never happened (unlike revert, which of course adds a new commit and 
leaves the old ones alone.) The documentation for this command could 
stand to be more explicit about that.

quoted text
> Further, I do not see much value in making this operation faster.  It is 
> meant to be a one-time operation, for example when you open-source a 
> product and have to cull a lot of history that you must not show for legal 
> reasons.  It is a one-shot operation.
>   

Your recent changes to git-rebase (which, BTW, are great) include a 
feature that's very similar to this: the "squash these commits together 
in my history" feature. That'd be my use case for this, when I want to 
publish my changes to other developers who don't care about all my 
intermediate checkpoints of work in progress, and when the commits I'm 
removing haven't been published anywhere else yet.

With this command, I could do something like:

git rewrite-commits --grep="!@@@checkpoint"
git push

and it would strip out all my intermediate checkpoint commits (assuming 
I've marked them as such in my commit comments, which I always do) 
before pushing to my project's shared repo. Right now that's a much more 
cumbersome, and very manual, operation. Even with the new git-rebase 
changes, I still have to pick out those commits by hand, and it assumes 
that I otherwise want to do a rebase in the first place.

quoted text
> So there are two things I see here that filter-branch cannot do yet.  The 
> first is to rewrite _all_ branches, which should be easy to do, it only 
> has to be done.
>   

I wonder if it makes sense to go that direction, though, or to make this 
command do the things that filter-branch can do, for the simple reason 
that filter-branch is a shell script and this is already a nice 
non-shell-dependent C program. Obviously you end up in the same place 
either way eventually once filter-branch percolates to the top of the 
"port these scripts to C" list, but it seems odd to me to port features 
from a C program back to a shell script only to have to convert the 
shell script to C later on.

Ironically, this app doesn't really speed up the one thing I find too 
slow in filter-branch: the "remove a file from the tree in all 
revisions" case. To do that you still have to launch a filter app for 
every commit, which is especially bad when the file in question only 
appears in a few revisions deep in the history of a repo.

This command points us in the direction of a "remove/rename this file in 
history" feature that doesn't require forking tens of thousands of child 
processes on a repo with lots of history. For that alone I think it's 
worthwhile, even though it's not there yet; that will never happen with 
a shell script. And yeah, that's not a frequent operation, but it's sure 
nice when even the infrequent operations are lightning fast.

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