Re: [PATCH] filter-branch: rewrite only refs which were not excludedbythe options

Hi,

On Tue, 24 Jul 2007, Johannes Sixt wrote:

Johannes Schindelin wrote:

quoted

On Tue, 24 Jul 2007, Johannes Sixt wrote:

quoted

Johannes Schindelin wrote:

quoted

On Tue, 24 Jul 2007, Johannes Sixt wrote:

quoted

But there's another problem. Consider this history:

   ---X--o--M         <- master
             \
          ...-o-...-o <- topic

Then this (rather contrieved) command:

   $ git-filter-branch -n $n master topic --not X

If $n is small enough so that M is never rewritten, then

   git rev-list -1 "$ref" $negatives

still expands to non-empty even for 'master' (= M), which then
incorrectly ends up in "$tempdir"/heads.

Aaargh!  Of course!  Since I have to add --topo-order at the end.
Otherwise it makes no sense.

No, that was no my point: In my example above, if n=1, `git rev-list -1
"$ref" $negatives` evaluates to

    $ git rev-list -1 "master" -n 1 ^X

which returns M, even though M is not going to be rewritten.
--topo-order changes nothing. The problem is that the -n is a relative
restriction. --since is turned into --max-age, which is absolute,
therefore, the test works as expected with --since.

So you think we have to say something like

        git rev-list "$ref" $negatives | grep "$ref" > /dev/null || continue

?

No, doesn't help either.

We are talking about a case where there is more than one positive ref.
We need not consider the -- sub/ case - it makes things just even more
complicated. There are two different rev ranges to be considered:

  # (1) candidate range to be rewritten
  $ git rev-list "$@"

  # (2) test if positive ref is in candidate range
  $ git rev-list $ref $negatives

Okay, but with out any subdirs,

	git rev-list "$@" | grep $(git rev-parse "$ref") > /dev/null || continue

should do exactly what we want.  But in that case, we could just use the 
generated list ../revs to grep for the positive refs.

Darn, this _is_ getting complicated.

Ciao,
Dscho