Re: [PATCH] git-bundle - bundle objects and references for disconnected transfer.

From: Mark Levedahl <mdl123@verizon.net>
Date: Feb 14, 2007, 23:19 UTC
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).

Show 14 quoted lines

>> +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.

Show 5 quoted lines

> 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