On 2. 4. 2014 20:53, Jens Lehmann wrote: > Am 01.04.2014 23:59, schrieb Ronald Weiss: >> On 1. 4. 2014 22:23, Jens Lehmann wrote: >>> Am 01.04.2014 01:35, schrieb Ronald Weiss: >>>> On 1. 4. 2014 0:50, Ronald Weiss wrote: >>>>> On 31. 3. 2014 23:47, Ronald Weiss wrote: >>>>>> On Mon, Mar 31, 2014 at 8:58 PM, Jens Lehmann <Jens.Lehmann@xxxxxx> wrote: >>>>>>> As Junio mentioned it would be great if you could teach the add >>>>>>> command also honor the --ignore-submodule command line option in >>>>>>> a companion patch. In the course of doing so you'll easily see if >>>>>>> I was right or not, then please just order them in the most logical >>>>>>> way. >>>>>> >>>>>> Well, if You (or Junio) really don't want my patch without another one >>>>>> for git add, I may try to do it. However, git add does not even honor >>>>>> the submodules' ignore setting from .gitmodules (just tested with git >>>>>> 1.9.1: "git add -u" doesn't honor it, while "git commit -a" does). So >>>>>> teaching git add the --ignore-submodules switch in current state >>>>>> doesn't seem right to me. You might propose to add also support for >>>>>> the ignore setting, to make "add -u" and "commit -a" more consistent. >>>>>> That seems like a good idea, but the effort needed is getting bigger, >>>>> >>>>> Well, now I actually looked at it, and it was pretty easy after all. >>>>> The changes below seem to enable support for both ignore setting in >>>>> .gitmodules, and also --ignore-submodules switch, for git add, on top >>>>> of my patch for commit. >>>> >>>> There is a catch. With the changes below, submodules are ignored by add >>>> even if explitely named on command line (eg. "git add x" does nothing >>>> if x is submodule with new commits, but with ignore=all in .gitmodules). >>>> That doesn't seem right. >>>> >>>> Any ideas, what to do about that? When exactly should such submodule be >>>> actually ignored? >>> >>> Me thinks git add should require the '-f' option to add an ignored >>> submodule (just like it does for files) unless the user uses the >>> '--ignore-submodules=none' option. And if neither of these are given >>> it should "fail with a list of ignored files" as the documentation >>> states. >> >> It's still not clear, at least not to me. Should '-f' suppress the >> ignore setting of all involved submodules? That would make it a >> synonyme (or a superset) of --ignore-submodules=none. Or only if the >> submodule is explicitly named on command line? That seems fuzzy to me, >> and also more tricky to implement. > > Maybe my impression that doing "add" together with "commit" would be > easy wasn't correct after all. I won't object if you try to tackle > commit first (but I have the slight suspicion that similar questions > will arise concerning the "add"ish functionality in commit too. So > maybe after resolving those things might look clearer ;-) There is one big distinction. My patch for commit doesn't add any new problems. It just adds the --ignore-submodules argument, which is easy to implement and no unclear behavior decisions are needed. You are right that when specifying ignored submodules on commit's command line, there is the same problem as with git add. However, it's already there anyway. I don't feel in position to solve it, I'd just like to have "git commit --ignore-submodules=none". With git add however, changing it to honor settings from .gitmodules would change behavior people might be used to, so I would be afraid to do that. Btw add also has the problem already, but only if somebody configures the submodule's ignore setting in .git/config, rather than .gitmodules. I don't know how much real use case that is. As I see it, there are now these rather easy possibilities (sorted from the easiest): 1) Just teach commit the --ignore-submodules argument, as I proposed. 2) Teach both add and commit to --ignore-submodules, but dont add that problematic gitmodules_config() in add.c. 3) Teach both add and commit to --ignore-submodules, and also let add honor settings from .gitmodules, to make it more consistent with other commands. And, make add --force imply --ignore-submodules=none. I like both 1) and 2). I don't like 3), the problem of add with submodules' ignore setting is a bug IMHO (ignore=all in .git/config causes strange behavior, while ignore=all in .gitmodules is ignored), but not directly related to the --ignore-submodules param, and should be solved separately. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html