From: Johannes Schindelin Date: Tue, 24 Jul 2007 09:10:12 GMT Subject: Re: [PATCH] filter-branch: Big syntax change; support rewriting multiple refs Message-ID: In-Reply-To: <7vfy3ejre3.fsf@assigned-by-dhcp.cox.net> Hi, On Mon, 23 Jul 2007, Junio C Hamano wrote: > Johannes Schindelin 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 --all 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= 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