threads / patch / 8353

patchRe: [PATCH] rev-parse: Identify short sha1 sums correctly.

Subject: Re: [PATCH] rev-parse: Identify short sha1 sums correctly.

## tl;dr

3 messages between May 29, 2007 and May 30, 2007. Diffs are folded; open one to read it.

replies: 2people: 2as markdown or json

Junio C Hamano· May 29, 2007, 23:40 UTC · lore

James Bowes <jbowes@dangerouslyinc.com> writes:

> find_short_packed_object was not loading the pack index files.
> Teach it to do so.
>
> Signed-off-by: James Bowes <jbowes@dangerouslyinc.com>

I think this is the proper fix of the problem I was unhappy about with 'next', rather than reverting the lazy index loading. But I wonder how many _other_ places like this there are that we might be missing...

Shawn, an Ack, and any ideas for futureproofing?

Show 23 quoted lines

>  sha1_name.c |    7 +++++--
>  1 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/sha1_name.c b/sha1_name.c
> index 8dfceb2..7df01af 100644
> --- a/sha1_name.c
> +++ b/sha1_name.c
> @@ -76,8 +76,11 @@ static int find_short_packed_object(int len, const unsigned char *match, unsigne
>  
>  	prepare_packed_git();
>  	for (p = packed_git; p && found < 2; p = p->next) {
> -		uint32_t num = p->num_objects;
> -		uint32_t first = 0, last = num;
> +		uint32_t num, last;
> +		uint32_t first = 0;
> +		open_pack_index(p);
> +		num = p->num_objects;
> +		last = num;
>  		while (first < last) {
>  			uint32_t mid = (first + last) / 2;
>  			const unsigned char *now;
> -- 
> 1.5.2.869.g6b3ba

Shawn O. Pearce· May 30, 2007, 01:58 UTC · re: Junio C Hamano · lore

Junio C Hamano <junkio@cox.net> wrote:

Show 13 quoted lines

> James Bowes <jbowes@dangerouslyinc.com> writes:
> 
> > find_short_packed_object was not loading the pack index files.
> > Teach it to do so.
> >
> > Signed-off-by: James Bowes <jbowes@dangerouslyinc.com>
> 
> I think this is the proper fix of the problem I was unhappy
> about with 'next', rather than reverting the lazy index
> loading.  But I wonder how many _other_ places like this there
> are that we might be missing...
> 
> Shawn, an Ack, and any ideas for futureproofing?

Ack, though late.  ;-)

I actually found this exact same bug today. At first I thought it was related to alternates, but when I dug into the code I came up with basically the same patch as James did. His was sent in first and is logically identical, so I'm not going to send my version.

With regards to future proofing this, I have no idea. I'm going to write up a test case that catches this and submit that, to avoid a future regression here, but otherwise I'm not sure what we can do. I had thought I had visited every callsite and checked them, but apparently that wasn't true.

What would probably help is to change the name of the structure member in the .h file when its initialization time changes (or its meaning changes in a subtle way) and then go through and manually update every mention of the old name to the new name, then flip it back with a global search and replace when done.

E.g. I should have done:

	* in cache.h rename num_objects to num_objects_SHAWNCHANGEHERE;
	* manually update every num_objects usage to my private name;
	* finally globally search-replace back to the standard name.

It would have forced me to more carefully visit every damn callsite.

I'll go back through the code tonight and double check my work, because this bug was completely my fault. I'm hoping this was the only bug however.

-- 
Shawn.

Shawn O. Pearce· May 30, 2007, 02:02 UTC · re: Junio C Hamano · lore

Junio C Hamano <junkio@cox.net> wrote:

Show 9 quoted lines

> James Bowes <jbowes@dangerouslyinc.com> writes:
> 
> > find_short_packed_object was not loading the pack index files.
> > Teach it to do so.
> >
> > Signed-off-by: James Bowes <jbowes@dangerouslyinc.com>
> 
> I think this is the proper fix of the problem I was unhappy
> about with 'next'

Actually this bug is exactly the reason why I *always* run 'next' in production use on all of my systems, and why I also get a number of coworkers to run it. Many people beating on the same code in weird ways notice things.

Today I found this because I have a shell script that tried to do something of the form "git checkout v1.8.0-18-g18as1f' and Git couldn't believe that was a revision... It held up day-job work for an hour while I tracked it down, but I did catch it. ;-)

-- 
Shawn.