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

From: Mark Levedahl <mdl123@verizon.net>
Date: Feb 15, 2007, 02:32 UTC
Message-ID: <45D3C62D.6090609@verizon.net>
In-Reply-To: <Pine.LNX.4.63.0702150054210.22628@wbgn013.biozentrum.uni-wuerzburg.de>

Johannes Schindelin wrote:

Show 28 quoted lines

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

Show 7 quoted lines

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

Show 7 quoted lines

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