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

[Mark Levedahl <mdl123@verizon.net>]

Johannes Schindelin wrote:
> Hi,
> 
> On Wed, 14 Feb 2007, Mark Levedahl wrote:
> 
> 
> Ah, I just realized that you do not shift. This is wrong. For example,
> 
> 	git bundle --output=a1 a..b
> 
> would pass "--output=a1 a..b" to git-rev-parse. While you say 
> "--revs-only", this would work, but so would "these are no refs". You lose 
> valuable information that way (namely invalid parameters). The standard 
> shell way is nicely visible in git-tag.sh (see the while loop). It is 
> basically
> 
> while case "$#" in 0) break ;; esac
> do
> 	case "$1" in
> 	--output)
> 		# handle $1 (and check that you can write to it).
> 		;;
> 	-*)
> 		usage
> 		;;
> 	*)
> 		break
> 	esac
> done

And that loop would always abort on things meant for git-rev-list. I 
want to avoid making git-bundle have to understand everything that is 
legal to git-rev-list. The current construct does this: it lets 
git-rev-parse remove what that function knows, aborting if something is 
amiss (or aborting later in git-rev-list), leaving git-bundle's parser 
to chew on the rest. I really don't see a way out of the dilemma: either 
allow --output foo but don't barf on bad arguments, or only accept 
--output=foo and be able to trap errors, or teach git-bundle everything 
that is valid for the other two.  (Let me write this in python, the 
dilemma is gone).

>>>   
>> Originally, this was in python with zip file built in memory (no 
>> temporaries). Sticking to portable shell makes many easy things really 
>> hard.
> 
> Not if you just pipe the two parts (refs & pack) into the output. Piping 
> also allows for "--output -" meaning stdout...

git-unbundle uses no temporary files: it pipes directly from tar (was 
zip, but I've changed to tar per Junio's request).

The problem is creating the tar: I know of no way to create a tar file 
with two separately addressable items, both created by piping in to 
stdin. If there are not two streams, I don't know how to split the data 
in sh without mangling the pack file due to sh variable substitution 
rules. So, I think the temporary file solution is a reasonable compromise.
> 
> Not at all. I meant to verify that these _hashes_ exist as commits. Not 
> necessarily refs.

See my other note.

>
> 
> We have shallow clones. This means that you can mark commits as "fake 
> root" commits, i.e. even if they have parents, they are treated as if they 
> had no parents. You do this by adding the hashes of the shallow commits to 
> ..git/shallow. For a short description, search for "shallow" in 
> Documentation/glossary.txt.

Thanks.

> 
> Ciao,
> Dscho
> 

Mark