From: Mark Levedahl <mdl123@verizon.net>
Date: Wed, 14 Feb 2007 23:19:21 GMT
Subject: Re: [PATCH] git-bundle - bundle objects and references for disconnected transfer.
Message-ID: <45D398F9.6070205@verizon.net>
In-Reply-To: <Pine.LNX.4.63.0702142238310.22628@wbgn013.biozentrum.uni-wuerzburg.de>

Johannes Schindelin wrote:
> This is not necessary. You should do this instead:
>
> 	. git-sh-setup
>   
I debated that, it seemed a wash but can do.
> Throughout git, we seem to do both "--output=<bla>" _and_ "--output <bla>" 
> forms, or just the latter.
>   
Patches gratefully accepted for that. This exceeds my skills in bash: I 
can do that in python, C, or other languages, but in bash I am working 
through a list that is a part of $* an arg at a time with no ability to 
look at the next, which is what this needs. Unless of course bash arrays 
are part of portable shell (not sure on that).
>> +git-show-ref $refs > .gitBundleReferences
>>     
>
> Would it not be better to say explicitely which refs are expected to be 
> present already (they start with "^" in the output of `git-rev-parse`, but 
> you would need to do a bit more work, since you cannot just take the 
> symbolic names).
>
> Some general remarks:
>
> It would be so much nicer if you worked without temporary files (you could 
> do that by starting the file with the refs, then have an empty line, and 
> then just pipe the pack after that).
>   
Originally, this was in python with zip file built in memory (no 
temporaries). Sticking to portable shell makes many easy things really 
hard. I'll think about this.
> IMHO reliance on $(git fsck | grep ^missing) is not good. The file check 
> might take very, very long, or use much memory. And you _can_ do better 
> [*1*].
>   
Good idea, but I think it is simpler to just keep the ^... output from 
git-rev-parse and check that those exist. What you suggest below seems 
to presume all bases are themselves references, which is not the case 
when doing, for example, master~10..master.
> Also, your use of shallow is incorrect. If the boundary commits are 
> present, you might just leave them as-are, but if they are not present, 
> you have to mark them as shallow. Otherwise, you end up with a corrupt 
> (not shallow) repository.
>   
I have to say I do not understand what "mark them as shallow" means: can 
you please enlighten me further?


Thanks,
Mark