Re: [PATCH] Add git-bundle: move objects and references by archive.

["Mark Levedahl" <mdl123@verizon.net>]

"Johannes Schindelin" <Johannes.Schindelin@gmx.de> wrote in message 
news:Pine.LNX.4.63.0702190126220.22628@wbgn013.biozentrum.uni-wuerzburg.de...
> 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