Re: [PATCH] filter-branch: Big syntax change; support rewriting multiple refs

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

Hi,

On Mon, 23 Jul 2007, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > 	Junio, I know that this comes quite late in the game, but I really
> > 	think that the "first arg is new branch name" was a bad syntax.
> >
> > 	Could you please consider taking this patch (or whatever version
> > 	comes out after review ;-) or keeping filter-branch of 1.5.3?  I 
> > 	do not want people to get used to the borked syntax...
> 
> Yeah, "No new features after -rc" should not apply to this one.
> 
> I was actually going to ask you about it, since this is a feature we 
> have already advertised to the public, but still is a new feature, and 
> we'd be better off getting it right in the first public version.

Thanks.

> > 	BTW I considered "git log -g --all" as an alternative to
> > 	inspecting refs/original/, but ATM this die()s if just _one_ of 
> > 	the refs has no logs.  Probably should fix that, too.
> 
> I do not think refs/original/ is such a hot feature.  What's wrong with 
> "gitk mine@{1}...mine"?

If you are saying

	$ git filter-branch <some-filters> --all <rev-list-options>

potentially all refs are rewritten.

To find out which ones actually changed, you can use "git show-ref | grep 
^refs/original/" ATM.

It is not really easy to do it otherwise.  With the patches I sent out 
yesterday,

	$ git log -g --no-walk --all --decorate --abbrev-commit 
	  --pretty=oneline --since=<before-the-last-filter-branch-call>

would be similar, but not as comfortable, would it?

Of course, we could teach filter-branch an option, say --show-changed, 
which will not actually filter branches, but instead look at the reflogs 
itself and show the refs which were recently changed by filter-branch.

But note that you can switch off reflogs.

Ciao,
Dscho