Live data from Hacker News

Committing Without Git

matheustavares.gitlab.io

1–10 of 23 posts

Re: Committing Without Git

#4
One could use `printf 'first\0second'` in the Bash shell as an example of making a "string" with null embedded into it, but you can't store that in a Bash variable.

    $ TEST_VAR="$(printf 'first\0second')"
    bash: warning: command substitution: ignored null byte in input
I'm not familiar with working with null characters in Bash in this way, but I think there might be a way to do it.

Re: Committing Without Git

#5

One could use `printf 'first\0second'` in the Bash shell as an example of making a "string" with null embedded into it, but you can't store that in a Bash variable. $ TEST_VAR="$(printf 'first\0second')" bash: warning: command substitution: ignored null byte in input I'm not familiar with working with null characters in Bash in this way, but I think there might be a way to do it.

You don't actually need to store it in a variable. Do it the bash way and write it to a temporary file. You can then get the sha1 of that file and then zlib compress and copy it to the appropriate dir and filename.

Re: Committing Without Git

#7

One could use `printf 'first\0second'` in the Bash shell as an example of making a "string" with null embedded into it, but you can't store that in a Bash variable. $ TEST_VAR="$(printf 'first\0second')" bash: warning: command substitution: ignored null byte in input I'm not familiar with working with null characters in Bash in this way, but I think there might be a way to do it.

Shells and their aversion to null characters was my first introduction to Perl way back when. Tcl, at the time, couldn't handle null characters either. Various Awk implementations had different issues with them. Python didn't yet exist, C was too tedious for many things.

One option with shells is some set/get functions that encode/decode to base64, hex, etc. Feels pretty clunky though.

Re: Committing Without Git

#8
Somewhat in the same space, I saw an interesting stackoverflow post[1] about how to generically retrieve a single file from git. Apparently since git version 1.7.9.5, you can do this:

  git archive --remote=ssh://host/pathto/repo.git HEAD README.md | tar xO
Though apparently support depends on how you're running git, and potentially some enabled server side options.

[1] https://stackoverflow.com/questions/1125476/retrieve-a-singl...

Re: Committing Without Git

#9
post #8

Somewhat in the same space, I saw an interesting stackoverflow post[1] about how to generically retrieve a single file from git. Apparently since git version 1.7.9.5, you can do this: git archive --remote=ssh://host/pathto/repo.git HEAD README.md | tar xO Though apparently support depends on how you're running git, and potentially some enabled server side options. [1] https://stackoverflow.com/questions/1125476/retri…

Interesting! I didn't know about the --remote flag and this usage. I would probably have done something like:

git clone --filter=tree:0 --depth=1 --sparse --no-checkout && git checkout HEAD

(But that would still end up fetching a few more objects than just the desired file.)

Re: Committing Without Git

#10
post #7

One could use `printf 'first\0second'` in the Bash shell as an example of making a "string" with null embedded into it, but you can't store that in a Bash variable. $ TEST_VAR="$(printf 'first\0second')" bash: warning: command substitution: ignored null byte in input I'm not familiar with working with null characters in Bash in this way, but I think there might be a way to do it.

Shells and their aversion to null characters was my first introduction to Perl way back when. Tcl, at the time, couldn't handle null characters either. Various Awk implementations had different issues with them. Python didn't yet exist, C was too tedious for many things. One option with shells is some set/get functions that encode/decode to base64, hex, etc. Feels pretty clunky though.

I am sure you know this, so I'm just being pedantic here, but it's not that really the shells that have an aversion to the null character so much as that the exec() system call and the main() convention require C strings for program names, program arguments and environment variables, and since shells are thin layers above exec() and the environment, shells kinda have to also use C strings. Sure, nothing stops a shell from using counted byte strings and then allowing nulls in non-exported variable values, but because they evolved in a system that was so deeply based on C and C strings... they don't.
Post reply on HN