Re: [PATCH] Teach filter-branch about subdirectory filtering

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jun 8, 2007, 05:04 UTC
Message-ID: <Pine.LNX.4.64.0706080603520.4059@racer.site>
In-Reply-To: <7vzm3bmfeq.fsf@assigned-by-dhcp.cox.net>

Hi,

On Thu, 7 Jun 2007, Junio C Hamano wrote:

> Good thing you folded git-split into this, which is an obviously right 
> thing to do.

So my secritt evvil plann did not stay secritt that long.

> But it makes me wonder, if it is common to want to split a combined 
> project into two (or more) sets, taking more than one directories at a 
> time.

It's just a guess, but now that we come really, really close to having a concise implementation of git-subproject which will probably soon propagate to master, and then maint, I gather that more and more people come and want to split their projects (which they maintained as one big project) into several subprojects (which they should have been from the start, but the tool did not easily allow for that).

> We might however want to make sure that we detect an attempt to give 
> more than one --subdirectory-filter parameter.

Yeah. But then, I think that rev-list actually does not like to be passed a file/directory which does not exist currently, so that is probably a sensible safeguard against that usage.

Unless you think -- as I fear you do -- that people could think git-filter-branch (its name not withstanding) filters _multiple_ branches _at once_.

That case I did not foresee, and you're right, I should output a big fat error for the case when somebody says "filter-branch --subdirectory-filter a/ --subdirectory-filter b/". It does not make any sense. But humans are known for their unique feeling that things should work, even if they make no sense at all, and their brain should have warned them (that it is unlikely, at best, to work), but failed to do so.

Ciao, Dscho