On Tue, Nov 23 2021, Elijah Newren wrote:
> On Tue, Nov 23, 2021 at 5:19 PM Ævar Arnfjörð Bjarmason
> <avarab@xxxxxxxxx> wrote:
>> Doesn't this series also change the behavior of e.g.:
>>
>> cd contrib/subtree
>> git rm -r ../subtree
>
> Yes, of course!
>
> Before:
>
> $ cd contrib/subtree
> $ git rm -r -q ../subtree/
> $ ls -ld ../subtree/
> ls: cannot access '../subtree/': No such file or directory
> $ git status --porcelain
> fatal: Unable to read current working directory: No such file or directory
> $ git checkout HEAD ../subtree/
> fatal: Unable to read current working directory: No such file or directory
>
> After:
>
> $ cd contrib/subtree
> $ git rm -r -q ../subtree/
> $ ls -ld ../subtree/
> drwxrwxr-x. 1 newren newren 0 Nov 23 19:18 ../subtree/
> $ git status --porcelain
> D contrib/subtree/.gitignore
> D contrib/subtree/COPYING
> D contrib/subtree/INSTALL
> D contrib/subtree/Makefile
> D contrib/subtree/README
> D contrib/subtree/git-subtree.sh
> D contrib/subtree/git-subtree.txt
> D contrib/subtree/t/Makefile
> D contrib/subtree/t/t7900-subtree.sh
> D contrib/subtree/todo
> $ git checkout HEAD ../subtree/
> Updated 10 paths from c557be478e
>
> Very nice fix, don't you think?
I'd be more sympathetic to this for the "checkout" etc. commands, but
once I add a "-f" to that "rm" I'm *really* expecting it to rm the
directory, but it won't anymore because it's in the underlying library
function.
But if the goal is to get "git status" and the like working isn't a much
more pointed fix to have setup.c handle the case of getting ENOENT from
getcwd() more gracefully. I.e. currently (and even with your patches):
$ (mkdir blah && cd blah && rmdir ../blah && git status)
fatal: Unable to read current working directory: No such file or directory
Whereas if we do e.g.:
diff --git a/strbuf.c b/strbuf.c
index b22e9816559..3f9a957ff9d 100644
--- a/strbuf.c
+++ b/strbuf.c
@@ -600,6 +600,16 @@ int strbuf_getcwd(struct strbuf *sb)
return 0;
}
+ if (errno == ENOENT){
+ const char *pwd = getenv("PWD");
+
+ if (pwd) {
+ warning(_("unable to getcwd(), but can read PWD, limping along with that..."));
+ strbuf_addstr(sb, pwd);
+ return 0;
+ }
+ }
+
/*
* If getcwd(3) is implemented as a syscall that falls
* back to a regular lookup using readdir(3) etc. then
We'll get:
$ (mkdir blah && cd blah && rmdir ../blah && GIT_DISCOVERY_ACROSS_FILESYSTEM=1 ~/g/git/git status)
warning: unable to getcwd(), but can read PWD, limping along with that...
On branch master
Your branch is up to date with 'origin/master'.
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: ../strbuf.c
no changes added to commit (use "git add" and/or "git commit -a")
I think that getenv("PWD") trick is widely supported, and once we get
past that we seem OK. The relative path to strbuf.c is even correct.
Currently you'd need to set GIT_DISCOVERY_ACROSS_FILESYSTEM=1 because we
run into another case in setup.c where we're not carrying that ENOENT
forward, but we could just patch strbuf_getcwd() or that subsequent code
to handle this edge case.
>> If so then re the "spidey sense" comment I had earlier: There's no rm
>> codepaths or tests changed by this series,
>
> That's not correct; I explicitly added a new rm test in the first
> patch in my series. Further, that same test was modified to mark it
> as passing by this particular patch you are commenting on.
Sorry about that, I didn't look carefully enough.
>> so the implementation of
>> doing it at this lower level might be casting too wide a net.
>
> I'm getting the vibe that you are assuming I'm changing these two
> functions without realizing what places might be calling them;
> basically, that I'm just flippantly changing them. Ignoring the
> ramifications of such an assumption, if this vibe is correct[...]
Sorry no, I didn't mean to imply that. I snipped the rest, but hopefully
this answers the questions you had well enough (and in the time I have
for this reply):
I'm not concerned that you didn't research this change well enough, I
just find it a bit iffy to introduce semantics in git around FS
operations that don't conform with that of POSIX & the underlying OS. My
*nix system happily accepts an "rm -rf" or an "rmdir" of the directory
I'm in, I'd expect git to do the same.
But whatever research we do on in-tree users we're left with changing
behavior for users in the wild, e.g. a script that cd's to each subdir
in a repo, inspects something, and if it wants to remove that does an
"git rm -r" of the directory it's in, commits, and expects the repo to
be clean afterwards.
I did follow/read at least one of the the original discussions[1] a bit,
and some earlier discussion I'm vaguely recalling around bisect in a
subdir.
If the underlying goal is to address the UX problem in git of e.g. "git
status" and the like hard-dying I wonder if something in the direction
of the setup.c/strbuf.c change above might be more of a gentle change.
That approach of a more gentler setup.c also has the benefit of having
git work when it ends up in this situation without the git commands
having landed it there, as in the above "rmdir" example.
Anyway, I really didn't have time to look at this very carefully. I just
remember looking into this with bisect/status etc. in the past, and
thinking that these problems were solvable in those cases, i.e. they
were just being overly anal about ENOENT, and not falling back on "PWD"
etc.
1. https://lore.kernel.org/git/YS3Tv7UfNkF+adry@xxxxxxxxxxxxxxxxxxxxxxx/
