Welcome to the 113th edition of Git Rev News, a digest of all things Git. For our goals, the archives, the way we work, and how to contribute or to subscribe, see the Git Rev News page on git.github.io.
This edition covers what happened during the months of June and July 2024.
[ANNOUNCE] Tickets available for Git Merge 2024
Taylor Blau announced that tickets for Git Merge 2024, Berlin, September 19th and 20th are now on sale. People who would like to come but need financial assistance with travel costs can contact the Git PLC or Scott Chacon directly.
[ANNOUNCE] Git Merge 2024 CFP deadline extended
Taylor Blau announced that the Git Merge 2024 CFP (Call For Proposals) limit has been extended by a week from August 1st to August 8th. So there are a few more days left to propose talks.
[ANNOUNCE] Berlin Git Meetup on August 14th, 6pm CEST
Patrick Steinhardt announced that some Git developers are trying to revive the Git user group in Berlin and will host their first session together with GitButler soon.
[BUG] “git clean -df .” silently doesn’t delete folders with stale .nfs* files
Yuri reported that git clean -df ., which was supposed to delete a
directory and all its contents, didn’t work when there were files
named ‘.nfsXXXXXXXXXXX’ managed by NFS in that directory. He
expected that git clean -df . would warn or error out when it
cannot remove such a file, instead of ignoring the fact that it
could not remove the file and the containing directory and
terminating with a success exit code.
Junio Hamano, the Git maintainer, replied to Yuri saying that it was expected that directories that were not empty were not removed.
Yuri replied that he expected the ‘.nfsXXXXXXXXXXX’ files to be removed as they were untracked, that is, neither added nor part of the repo, and the command was expected to remove such untracked files.
Junio replied that the ‘.nfsXXXXXXXXXXX’ files were “a limitation” of NFS that applications, including Git, couldn’t and weren’t supposed to remove. He pointed to some documentation which explains what these special NFS files are, and that they originate from an NFS protocol based implementation strategy commonly known as “silly rename”.
Yuri replied that Git should still complain when it cannot remove such files, or that there should be a verbosity option that should make it complain in such cases.
Randall S. Becker replied to Yuri that he tried to reproduce the issue without using NFS and couldn’t. So he asked Yuri if he could share “a reproducible set of commands” and said that it was probably caused by NFS.
Junio replied to Randall and Yuri that removing a ‘.nfsXXXXXXXXXXX’ files under a real NFSv3 client would likely result in the file being automatically resurrected, and that failure to remove a file should indeed be reported as Git does when it cannot remove a regular file.
Yuri replied to Randall listing a series of instructions to reproduce the issue. He agreed that Git reported failures when it couldn’t remove a file because of “permissions and special flags reasons”, but he repeated that it should also do it in the case of such NFS files.
Randall replied to Yuri saying he thought that Git didn’t even see
the NFS files. He asked if a second git clean -df . removed the
NFS files and put new ones, with different names, in place.
Yuri replied that it wasn’t the case and there seemed to be a single NFS file.
Chris Torek then chimed into the discussion replying to Yuri. He explained in details how “NFS silly renames” work, and listed some cases which could result in NFS lying to Git by reporting that an unlink(2) operation succeeded when in fact the file was renamed but not deleted. In such a case Git could not report that it couldn’t remove a file. It could report that it couldn’t remove the containing directory though.
Chris finished his explanations saying “Anyway, that’s the OS view of this mess. I leave the work on Git itself to others. :-)”
Jeff King, alias Peff, replied to Yuri’s email that contained a series of instructions to reproduce the issue. He said he got the following warning when trying to reproduce:
warning: failed to remove xx/.nfs0000000002c8197f00000002: Device or resource busy
So Peff thought Git worked properly on his system and then communicated details of the OS and NFS mount he used.
Yuri replied by giving information about his system. He also said
that when using rm -rf to remove the NFS file, he got a “Device or
resource busy” error message, but not when using Git.
Randall replied to Peff that doing a self-mount to reproduce as Peff did was perhaps not the best, as the NFS client might be aware of the self-mount and things might not behave the same as in a regular mount.
Yuri suggested using a virtual machine to avoid a self-mount.
Gabor Gombas replied to Yuri reporting the results of his tests. He
got a “Directory not empty” or a “Device or resource busy” error
message when he used git clean -dfx, but he also got no error
message when using git clean -df.
This led Yuri to reply that with -dfx Git indeed warns about NFS
files on his machine, but with -df it doesn’t, because the NFS
files are in the ignore list.
It is indeed expected that ignored files are not deleted and are
just ignored without the -x option.
Who are you and what do you do?
My name is Rubén, and that’s how it’s spelled correctly. However, some old friends call me Ruben because when we were kids changing names was a sign of friendship. Changing the accent from “ben” to “ru”, makes the letter ‘e’ lose its tilde when writing my name.
My $dayjob is not related to Git, but I use it quite often during the workday. Using it sometimes gives me an itch that I often can’t resist trying to scratch.
What would you name your most important contribution to Git?
I can’t think of any worth mentioning. But I’ll say something in the other direction; contributing to Git has not only meant solving some itches, but it has clearly made me improve my overall work style. I’m grateful for that.
What are you doing on the Git project these days, and why?
This can be read at any time: polishing up some itches that has come up for me or a colleague.
Lately, though, I find myself exploring more and more side issues that arise during iterations of the changes I was originally interested in.
If you could get a team of expert developers to work full time on something in Git for a full year, what would it be?
I’ll say a feasible one: something in Git that allows me to avoid
writing shortcuts like @{-1}, @{1}, @{...
At least on my keyboard, it’s a pain to type @, {...}. And I
tend to type those shortcuts a lot.
Perhaps too easy for the experts and they’ll have a lot of spare time during the year?
If you could remove something from Git without worrying about backwards compatibility, what would it be?
I think that backwards compatibility is overrated most of the time. It’s usually a matter of getting on with it and time; sometimes a lot of time, I admit.
The steps being taken towards Git 3.0 seem very interesting to me [ref 1] [ref 2]. Perhaps there is an opportunity to do some breaking changes. I don’t have any in mind, though.
What is your favorite Git-related tool/library, outside of Git itself?
Definitely: tig.
Do you happen to have any memorable experience w.r.t. contributing to the Git project? If yes, could you share it with us?
Nope.
What is your toolbox for interacting with the mailing list and for development of Git?
To interact with the list, I mainly use lei,
mutt and thunderbird
in a rather makeshift way. Maybe someday I’ll finally configure
git send-email.
In fact, more often than not, when I send a patch, I have the feeling that someone is going to come along and say: “Come on, Rubén. That user agent? Set up a decent environment to send this properly”.
To develop, I mainly use vanilla Vim.
What is your advice for people who want to start Git development? Where and how should they start?
Perhaps I would say that writing and reading code are not the most important skills in a project like Git. Empathy and the development of effective arguments to convey ideas or intentions are much more crucial.
Realizing and internalizing that, is a solid starting point, I think.
If there’s one tip you would like to share with other Git developers, what would it be?
Keep in mind that reviewing code is much harder than writing it, but writing a good message for the commit is even harder.
Various
git config list),
an enhanced credential helper protocol, and improving the still experimental reftable support.git update-ref --stdin,
git config interface improvements (mentioned in the previous article linked), and bundle URI fixes.Light reading
pre-receive hook (and git-http-backend configured
to allow anonymous push) that turns git push into series of patch emails.
(Though this approach has some limitations.) Written by Steinar H. Gunderson on his blog.
git commit --fixup).
Reality shattered like broken glass. The firmament that separated the real world from the eldritch beyond had broken. Two timelines had collided in the center of the street - an incongruous synthesis of two different chains of events. A building collapsed, and it did not. An explosion devastated the surroundings, and it did not. Screaming faces and laughs of joy overlapped each other as if viewed through a kaleidoscopic prism.
The crowd looked on in horror and awe. Who was responsible for tearing apart the fabric of reality?
Izuku groaned. ‘Great, another merge conflict’, he thought. ‘What a pain’.
Easy watching
git stash…
(or rather, how one can use git worktree), by Philomatics on YouTube [5:18].Git tools and sites
git-pr server:
# Contributor submits his/her changes:
git format-patch origin/main --stdout | ssh pr.pico.sh pr create test
# > Patch Request has been created (ID: 1)
# Owner can apply those changes via patch request:
ssh pr.pico.sh pr print 1 | git am -3
Can be self-hosted. Written in Go, MIT licensed.
ls. It knows about symlinks,
extended attributes, and Git (like file status in Git repo, Git repo status,
or ignoring files mentioned in .gitignore). Written in Rust, MIT licensed.
See the documentation.ifcmerge is written in Perl and published under the GPLv3 license).git submodules for managing arbitrary external dependencies.
Written in Go, MIT licensed.
git log --all --date-order --pretty="%h|%p|%d" into a textarea.
act user guide for more documentation.
act.This edition of Git Rev News was curated by Christian Couder <christian.couder@gmail.com>, Jakub Narębski <jnareb@gmail.com>, Markus Jansen <mja@jansen-preisler.de> and Kaartic Sivaraam <kaartic.sivaraam@gmail.com> with help from Štěpán Němec and Rubén Justo.