2012/2/7 Junio C Hamano <gitster@xxxxxxxxx>: > It still is not clear to me how best to sell this change to the end-user > community. > > IIRC, the original motivation of intent-to-add "add -N" was in response to > users who curse Git because they often forget to add new files before > committing, and they wanted to say "Here I have a new file, it is not > complete yet, but I do not want it left out of the commit. While my memory > is fresh, let me tell Git to keep an eye on it, so that it can remind me > if I forget to add the final contents." For them, the current "did you > forget to add them? If so tell me the final contents for at least the > paths you will be changing with this commit" error was a perfect safety > solution. > > It turned out that the benefits described we see above in the context, > "This is useful, among other things, ...", were of more value, and for > these use cases, i-t-a entries ceased to mean "I may forget, so I am > telling you now, please remind me when I say commit." And "did you > forget?" error is hinderance for them. > > But does that mean nobody will ever need "please remind me lest I forget"? > Just the original requestor of the "add -N" feature may still be using > git, but more importantly, isn't it the case that those who have been > using it merely for the other side effect (e.g. 'git diff') sometimes want > the "please remind me" safety? > > I suspect that some among 1 million Git users would want the "please > remind me", so a solution with configuration variable without command line > override is not ideal (command line without any configurability is fine as > long as we have a good default). Which is why I prefer adding a new configuration variable (and optionally a command line option) instead of deprecating current behavior, because (being lazy) I never be able to find "some among 1 million" so I'm fine with assuming there are some among 1 million that favors safety over convenience. > I am beginning to think "safety by default, which can be turned off by > learned users, but still can be turned on on demand" may be a lot easier > to sell this. That is: > > - commit.ignoreIntentToAdd defaults to `false`; the default will never > change. The users can set it to `true`. > > - "commit --ignore-intent-to-add" can be used without setting the > configuration or to defeat an explicit `false`, for a one-shot request. > > - "commit --honor-intent-to-add" can be used to defeat an explicit > `true`, for a one-shot request. > > The third one is a bit funny, as it is a way to bring back safety when the > user earlier decided that he does not need that kind of safety (i.e. "I > only say 'add -N' for `diff` and stuff, I will never forget to add real > contents before committing"), so it will almost never be used, because > these users who set 'ignoreIntentToAdd = true' do _not_ expect Git to help > them in remembering to add the real contents. And having to add a funny > option just for the sake of completeness is often an indication that there > is something fundamentally wrong in the system that the option tries to > express an interface into it. Well, that --honor-intent-to-add could be renamed as --no-ignore-intent-to-add. The --[no-]ignore-intent-to-add pair functions as a way to override default behavior/config var. No extra could required. "git commit -h" just does not show it. We need better option/config names though, --ignore-intent-to-add looks way too long to type and it's not clear what it does without looking up "git add -N". -- Duy -- 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