Subject: Re: [RFC PATCH] repack: rewrite the shell script in C.

From: Martin Fick <[email-masked]>
Date: Wed, 14 Aug 2013 16:28:41 -0600

On Wednesday, August 14, 2013 04:16:35 pm Stefan Beller 
wrote:
> On 08/14/2013 07:25 PM, Martin Fick wrote:
> > I have been holding off a bit on expressing this
> > opinion too because I don't want to squash someone's
> > energy to improve things, and because I am not yet a
> > git dev, but since it was brought up anyway...
> 
> It's ok, if you knew a better topic to work on, I'd
> gladly switch over. (Given it would be a good beginners
> topic.)

See below...

> > I can say that as a user, having git-repack as a shell
> > script has been very valuable.  For example:  we have
> > modified it for our internal use to no longer ever
> > overwrite new packfiles with the same name as the
> > current packfile. This modification was relatively
> > easy to do and see in shell script.  If this were C
> > code I can't imagine having personally: 1) identified
> > that there was an issue with the original git-repack
> > (it temporarily makes objects unavailable) 2) made a
> > simple custom fix to that policy.
> 
> Looking at the `git log -- git-repack.sh` the last commit
> is from April 2012 and the commit before is 2011, so I
> assumed it stable enough for porting over to C, as there
> is not much modification going on. I'd be glad to
> include these changes you're using into the rewrite or
> the shell script as of now.

One suggestion would be to change the repack code to create 
pack filenames based on the sha1 of the contents of the pack 
file instead of on the sha1 of the objects in the packfile.  

Since the same objects can be stored in a packfile in many 
ways (different deltification/compression options), it is 
currently possible to have 2 different pack files with the 
same names.  The contents are different, but the contained 
objects are the same.  This causes the object availability 
bug that I describe above in git repack when a new packfile 
is generated with the same name as a current one.

I am not 100% sure if the change in naming convention I 
propose wouldn't cause any problems?  But if others agree it 
is a good idea, perhaps it is something a beginner could do?

-Martin

-- 
The Qualcomm Innovation Center, Inc. is a member of Code 
Aurora Forum, hosted by The Linux Foundation