Re: [PATCH 2/2] submodule.c: correctly handle nested submodules in is_submodule_modified

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> sanity check: What does this do for a "2" line indicating a sub-submodule
> that has been renamed that contains an untracked file?  Do we need to
> rely on some other indication to show this as a change?

Oh. :(

In case of 'u' and '2' we need to set DIRTY_SUBMODULE_MODIFIED
additionally. will fix in a reroll.

>
> Enumerating some more cases, since I keep finding myself getting lost:
>
>  - if the HEAD commit of "sub" changes, we show this as " M sub".
>    What should we show if the HEAD commit of "sub/subsub" changes?
>    I think this should be " m".
>
>  - if "sub" is renamed, we show this as "R  sub -> newname".
>    What should we show if "sub/subsub" is renamed?  It is tempting
>    to show this as " m".
>
>  - if "sub" is deleted, we show this as "D  sub". What should we
>    show if "sub/subsub" is deleted? I think this is " m".

All these cases are ' m', which I agree with, as it is a "modification
that cannot be git-add'ed in the superproject".

We might be inclined to later come up with  ' d' for a deleted nested
submodule, but I do not think it is worth the effort.

Thanks,
Stefan



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]