Hello, I admit this is somewhat of a corner case, still it happens in the reality of our admin team ... Initially this was noticed after upgrading the OS from Debian buster (with git 2.20.1) to Debian bullseye (with git 2.30.2). (wgit is just a wrapper for git to call it from my ~/src/git.) This is the good ("old") case: uwe@taurus:~/tmp/8d92fb29270$ wgit version git version 2.25.2.7.g0bbd0e8b5233 uwe@taurus:~/tmp/8d92fb292706$ wgit init Initialized empty Git repository in /home/uwe/tmp/8d92fb292706/.git/ uwe@taurus:~/tmp/8d92fb292706$ mkdir subdir uwe@taurus:~/tmp/8d92fb292706$ cd subdir/ uwe@taurus:~/tmp/8d92fb292706/subdir$ wgit init Initialized empty Git repository in /home/uwe/tmp/8d92fb292706/subdir/.git/ uwe@taurus:~/tmp/8d92fb292706/subdir$ cd .. uwe@taurus:~/tmp/8d92fb292706$ echo content > subdir/somefile uwe@taurus:~/tmp/8d92fb292706$ wgit add subdir/somefile uwe@taurus:~/tmp/8d92fb292706$ wgit status On branch master No commits yet Changes to be committed: (use "git rm --cached <file>..." to unstage) new file: subdir/somefile with 8d92fb292706, the following happens: uwe@taurus:~/tmp/8d92fb292706$ wgit version git version 2.25.2.8.g8d92fb292706 uwe@taurus:~/tmp/8d92fb292706$ wgit init Initialized empty Git repository in /home/uwe/tmp/8d92fb292706/.git/ uwe@taurus:~/tmp/8d92fb292706$ mkdir subdir uwe@taurus:~/tmp/8d92fb292706$ cd subdir/ uwe@taurus:~/tmp/8d92fb292706/subdir$ wgit init Initialized empty Git repository in /home/uwe/tmp/8d92fb292706/subdir/.git/ uwe@taurus:~/tmp/8d92fb292706/subdir$ cd .. uwe@taurus:~/tmp/8d92fb292706$ echo content > subdir/somefile uwe@taurus:~/tmp/8d92fb292706$ wgit add subdir/somefile uwe@taurus:~/tmp/8d92fb292706$ wgit status On branch master No commits yet Untracked files: (use "git add <file>..." to include in what will be committed) subdir/ nothing added to commit but untracked files present (use "git add" to track) So git after 8d92fb292706 doesn't add files from a subdirectory if said subdirectory is tracked in git, too. While I'm not sure which of the two behaviours is the bogus one, this is a change in behaviour that I guess wasn't intended in 8d92fb292706. Is this something that needs fixing? Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | https://www.pengutronix.de/ |
Attachment:
signature.asc
Description: PGP signature