Re: [PATCH 2/2] filter-branch: work correctly with ambiguous refnames

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jan 6, 2008, 01:57 UTC
Message-ID: <alpine.LSU.1.00.0801060154150.10101@racer.site>
In-Reply-To: <7vabnk81aw.fsf_-_@gitster.siamese.dyndns.org>

Hi,

On Sat, 5 Jan 2008, Junio C Hamano wrote:

Show 15 quoted lines

>  Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>  > Junio wrote:
>  >
>  >> But at that point I would say that exposing the refname dwimming
>  >> logic to the scripts could be a much cleaner solution.
>  >
>  > I considered that when ripping the script from cogito, but it seemed 
>  > to me at that time that not requiring an up-to-date git for testing 
>  > the script would be better.
>  >
>  > Now is a different situation, however, so I agree.
> 
>  It was already tied to the specific git version when
>  git-filter-branch became part of git.git ;-)

Heh. But that was not my intention (at least _before_ it was in git.git's "master"), so that people could test it.

Show 8 quoted lines

>  I do not use filter-branch myself very often, but I think this
>  is worth fixing.  The additional --no-flags and sed are to deal
>  with something like:
> 
> 	--topo-order master..next
> 
>  although I do not offhand know if filter-branch would work with
>  things like --topo-order and --first-parent.

Frankly, I have no idea, but --topo-order _should_ not matter, whereas --first-parent _should_ rewrite only commits in the first-parent chain of the given refs.

In any case, from a cursory look I like the 2 patches (except for the curly brackets around the single-line "else" clause, but I know your opinion about this, so I will not object).

Ciao, Dscho