Reminds me some of Raymond Chen's "Stupid Git Tricks" series [0-6] of blog posts where he used a lot of git commit-tree and similar low level tools to avoid worktree changes and minimize GC churn (partly because of working in the humongous Windows git, which of course seems to have similar issues to the Mozilla ones mentioned here such as auto-rebuild tools).
It makes a bunch of sense to build nicer porcelain tools for such low level git magic when it becomes semi-routine.
(I couldn't find a good permalink for the entire series as a whole, so linked are all the individual posts.)
FWIW, in case people aren't familiar with the term "porcelain", it refers to higher-level tools for working with git. (As opposed to lower-level "plumbing" commands).
Indeed, it's an old and somewhat out-of-favor term that I used partly as an in-joke.
(At one point everyone assumed the entire `git` command would be replaced for most users by a true porcelain interface, but that never really quite happened in that way as most people just standardized on `git` on the command line rather than any of the porcelain attempts. Instead `git` has sometimes directly got some of the high level commands and polish that was expected to be meant for porcelain tools.)
> partly because of working in the humongous Windows git, which of course seems to have similar issues to the Mozilla ones mentioned here such as auto-rebuild tools
Also possibly because windows FS operations are known to be extremely slow. That's one of the issues many folks have with WSL too.
Just to be clear, by Windows git I meant `Windows.git`, the git repository for Windows itself which no one in the world has yet admitted to having a larger git repository. The repository that Microsoft built tools like GitVFS for to virtualize dealing with the git object database and even the full worktree to manage working with that repository.
Local file system operations don't sound like they are the bottleneck there. (Also, Windows FS operations aren't "extremely slow" in general, they just have very different transactional model than Linux FS operations, which was the problem with WSL1 file operations trying to use the Windows FS to pretend to be the Linux FS, layering different transactional models on top of each other in a complex stack. Which is why WS2 is taking the VHD approach.)
This sounds exactly like my dream tool, the very thing I've been meaning to write myself and haven't gotten around to it. Thank you for writing this!
Suggestion: I'd love to see a `revise.autoSquash` git config flag (like `rebase.autoSquash`) to always autosquash in interactive mode. Maybe you already support it, but if so, the manpage doesn't list it.
8 comments
[ 2.5 ms ] story [ 28.9 ms ] threadIt makes a bunch of sense to build nicer porcelain tools for such low level git magic when it becomes semi-routine.
(I couldn't find a good permalink for the entire series as a whole, so linked are all the individual posts.)
[0] https://devblogs.microsoft.com/oldnewthing/20190506-00/?p=10...
[1] https://devblogs.microsoft.com/oldnewthing/20190507-00/?p=10...
[2] https://devblogs.microsoft.com/oldnewthing/20190508-00/?p=10...
[3] https://devblogs.microsoft.com/oldnewthing/20190509-00/?p=10...
[4] https://devblogs.microsoft.com/oldnewthing/20190510-00/?p=10...
[5] https://devblogs.microsoft.com/oldnewthing/20190513-00/?p=10...
[6] https://devblogs.microsoft.com/oldnewthing/20190515-00/?p=10...
https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Po...
(At one point everyone assumed the entire `git` command would be replaced for most users by a true porcelain interface, but that never really quite happened in that way as most people just standardized on `git` on the command line rather than any of the porcelain attempts. Instead `git` has sometimes directly got some of the high level commands and polish that was expected to be meant for porcelain tools.)
Also possibly because windows FS operations are known to be extremely slow. That's one of the issues many folks have with WSL too.
Local file system operations don't sound like they are the bottleneck there. (Also, Windows FS operations aren't "extremely slow" in general, they just have very different transactional model than Linux FS operations, which was the problem with WSL1 file operations trying to use the Windows FS to pretend to be the Linux FS, layering different transactional models on top of each other in a complex stack. Which is why WS2 is taking the VHD approach.)
Suggestion: I'd love to see a `revise.autoSquash` git config flag (like `rebase.autoSquash`) to always autosquash in interactive mode. Maybe you already support it, but if so, the manpage doesn't list it.
revise is giving me now some ideas.