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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html