Git security fixes released

Posted Apr 13, 2022 18:21 UTC (Wed) by dskoll (subscriber, #1630)
In reply to: Git security fixes released by tialaramex
Parent article: Git security fixes released

I use PS1 to set the git branch in my prompt, but I don't actually invoke git to find the branch. I wrote my own program that traverses up to / looking for .git/HEAD. It's way smaller and faster than git and also much simpler.

Git security fixes released

Posted Apr 13, 2022 18:35 UTC (Wed) by dtlin (subscriber, #36537) [Link] (2 responses)

But does it know how to follow git-worktree to the base repository? There's no .git/HEAD there.

Git security fixes released

Posted Apr 13, 2022 19:26 UTC (Wed) by dskoll (subscriber, #1630) [Link]

Well, I guess it would fail. But so far it works for all of my use-cases. The source, if anyone is interested, is at gitquickbranch.c.

Git security fixes released

Posted Apr 14, 2022 2:36 UTC (Thu) by NYKevin (subscriber, #129325) [Link]

As someone who has done similar things (but not for Git specifically), I can tell you why people do this: We can't stand waiting for the damn prompt to finish rendering. My prompt should print in under ~200 ms, but that's unrealistic if you're going to invoke half a dozen subshells on random command substitutions and the like. There are basically two ways out of this:

1. The right, but difficult way: Spawn a daemon or daemon-like process (running as yourself, e.g. using systemd's --user functionality, or just by persuading your shell to fork off a coprocess somehow) which knows how to find all of the information that your shell needs to print out its prompt, and then have your shell asynchronously send "I cd'd to a new directory" notifications to this daemon and asynchronously read updated prompt information from the daemon via some pipe/socket nonsense. Then you can get away with running heavy stuff like Git or Mercurial in the daemon, and your shell updates its prompt when the daemon eventually gets back to it.
2. The wrong, but easy way: Take shortcuts such as looking for .git, .hg, etc. by hand, hard-coding paths that you "know" have certain semantics in practice (e.g. "I know that the Git repos always live under /foo/bar/ on this system, so I will match ${PWD} against that prefix and then do [[ -d /foo/bar/$WHATEVER_WE_MATCHED/.git ]] to see whether we're in a Git repo"), etc., and never, ever spawn any more subshells than absolutely necessary (e.g. if a shell function has to return a string, do REPLY="$value" instead of printf "%s\n" "$value", and then you don't need to run it in a command substitution).

Tooling for (1) exists (e.g. zsh-async), but it's slightly more of a PITA to set up compared to just doing (2) everywhere (and also, I don't like running random GitHub code at $WORKPLACE unless it's in the package repository and somebody has vetted it), so you end up with horrible spaghetti code all over your .bashrc/.zshrc/what-have-you. It's a problem, but I wouldn't call it a big problem because ultimately it's just a shell prompt, it doesn't (directly) make $WORKPLACE money or anything like that.