"Johannes Schindelin" <Johannes.Schindelin@xxxxxx> wrote in message
news:Pine.LNX.4.63.0702190126220.22628@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Hi,
Sorry to be such a PITA, but I really, really think that it is wrong
to
make a tar dependency here. You said your cygwin has problems with
binary
files. Could you please try this:
$ echo -ne '\x1a\x1b\x15\x10\0abc' | cat | wc
Same result on Cygwin and FC6:
~>echo -ne '\x1a\x1b\x15\x10\0abc' | cat | wc
0 1 8
If it returns anything else than "<tab>0<tab>1<tab>8", then your setup
works differently from mine. I fit returns what I expect it to, then
we
can use cat directly and do not have to move the tar bloat around (it
is
inherently block based, so it wastes a lot of space, and it also
stores
other things we'll never use, like permissions for all files).
To repeat an earlier message, I tried the following:
cat bundle | (
while read <header stuff> do
<prcess header stuff>
done
git-pack-index --stdin
)
and it worked, MOST of the time, most being the important word here. My
memory is already fuzzy about the failure rate, but it was something
like 2 of 7 bundle files I passed through resulting in git-pack-index
reporting a corrupted pack file: when I manually edited out the header
stuff and passed the remains of the file directly to git-pack-index
things were fine. The same experiment worked perfectly on my FC6 system,
so it was definitely some part of Cygwin, not the script. If git is
worried about tickling "which" on ancient Solaris, I think it is a bit
out of balance to simultaneously require a not yet written version of
Cygwin (that will get fixed after someone has time to reduce this
problem to a simple testcase and push back to the Cygwin maintainers).
A bundle file *is* an archive. We can use an existing archiver or write
a new one. I don't really favor writing one but that is personal
preference for not reinventing the wheel, nothing more. However, given
Cgywin's problems an archiver written in shell isn't going to work for
binary files. We could uuencode / uudecode the pack files and make
bundles pure ascii text. Or, we could use tar. Of course, rewriting this
as a builtin offers the ability to write a purpose built archiver as
well, but I was trying to avoid that.
</unsolicited ignoreable gripe>Has anyone considered how much easier all
of git would be if it were written in c + python, rather than c + every
variant of shell + core utils + non-core utils known to mankind since
the dawn of unix?</unsolicited ignorable gripe>
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