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

Hi,

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

 Johannes Schindelin [off-list ref] 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.

 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