Re: [PATCH/RFC] add--interactive: ignore all internal submodule changes
- Date: Thu, 11 Jan 2018 18:06:11 +0700
- From: Duy Nguyen <pclouds@xxxxxxxxx>
- Subject: Re: [PATCH/RFC] add--interactive: ignore all internal submodule changes
On Thu, Jan 11, 2018 at 2:47 AM, Stefan Beller <sbeller@xxxxxxxxxx> wrote:
> On Wed, Jan 10, 2018 at 3:06 AM, Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx> wrote:
>> For 'add -i' and 'add -p' the only action we can take on a dirty
>> submodule entry (from the superproject perspective) is its SHA-1. The
>> content changes inside do not matter, at least until interactive add has
>> --recurse-submodules or something.
>> Ignore all dirty changes to reduce the questions 'add -i' and 'add -p'
>> throw at the user when submodules are dirty.
>> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx>
>> $DAYJOB started to use submodules and this annoys me so much when I
>> use 'git add -p'. I'm neither very familiar with add--interactive nor
>> submodules code but this seems to work. Hopefully it's a correct
> I would think this fixes your problem and it looks correct.
> However I wonder about some subtle detail:
> the "dirty" setting will ignore anything inside the submodule, and
> only pay attention to the delta in gitlinks between HEAD and index.
Wait, why does diff-files, the command about worktree and index, look
at HEAD? Testing, testing... no I think it still works as expected
> ~/w/git/temp/z $ git ls-files --stage foo
160000 41521690bee4b76ad108a403b79415f8591a5592 0 foo
> ~/w/git/temp/z $ git -C foo rev-parse HEAD
> ~/w/git/temp/z $ ../git diff --ignore-submodules=dirty foo
diff --git a/foo b/foo
index 4152169..3bc15b2 160000
@@ -1 +1 @@
-Subproject commit 41521690bee4b76ad108a403b79415f8591a5592
+Subproject commit 3bc15b2e78ec3a5c5ea27715f20adaa2669446b1
> ~/w/git/temp/z $ ../git diff-files --ignore-submodules=dirty foo
:160000 160000 41521690bee4b76ad108a403b79415f8591a5592
0000000000000000000000000000000000000000 M foo
If I reset foo/.git/HEAD back to 4152169... then diff-files
--ignore..=dirty returns empty. So I think it does check submodule's
> Maybe we'd want to have a mode "dirty-except-submodule-HEAD",
> which would ignore all submodule worktree changes, but if its HEAD
> is different than the gitlink in the superproject index or HEAD, such that
> checking out a different revision inside the submodule is not lost
> when staging things in the superproject for a new commit?