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