Re: [PATCH 0/3] Making remote tracking statistics available to other tools

From: Olivier Marin <dkr+ml.git@free.fr>
Date: Jul 3, 2008, 16:26 UTC
Message-ID: <486CFDA3.9070704@free.fr>
In-Reply-To: <7v3amsg1wx.fsf@gitster.siamese.dyndns.org>

Junio C Hamano a écrit :

Show 8 quoted lines

> The one I sent out was a bit hacky as the existing implementation inside
> git-checkout was not designed to be cleanly reusable.
> 
> Here is a cleaned up series that could be applied.
> 
> [PATCH 1/3] Refactor "tracking statistics" code used by "git checkout"
> [PATCH 2/3] git-status: show the remote tracking statistics
> [PATCH 3/3] git-branch -v: show the remote tracking statistics

Sorry, but the third patch does not work for me. FWIU, the problem comes from the revision walking code that is not reentrant because of the object cache. IOW, calling stats_tracking_info() more than once does not work: objects states changed after first call.

I do not understand the code enough yet and I failed to fix it. The only way I found is by clearing obj_hash (object.c) but this seems the wrong thing to do.

Ideas?

This test case should trigger the bug:

$ for i in a b c; do echo $i>$i && git add $i && git commit -m $i; done $ git clone . clone1 $ cd clone1 $ git checkout -b b1 origin/master $ git reset --hard HEAD~ $ echo d>d && git add d && git commit -m d $ git checkout -b b2 origin/master $ git reset --hard HEAD~ $ git merge b1

$ git branch -v
  b1     c07015a [ahead 1, behind 1] d
* b2     c07015a d
  master 08ca18b c

b1 and b2 are both 1 commit ahead and 1 commit behind.

$ git branch -D b1
$ git branch -v
* b2     c07015a [ahead 1, behind 1] d
  master 08ca18b c

deleting b1 show us the side effect.

Olivier.