Carl Worth <cworth@xxxxxxxxxx> writes: > I complained about this when I first encountered git, and back then I > said what I thought I wanted was "git diff HEAD" by default. I was > totally wrong, since diff from the index is so obviously correct for > resolving a conflict. Junio even responded to my complaints by > providing a new "git status -v -a" but frankly I've never used > it. I guess my responding to whatever you said was wasted effort, and if you do not like "git add" this time, I should not be surprised. That's kind of sad ;-). Jokes aside. I do not remember who advocated for making "git status" the preview of "git commit" to happen. Was that also you? I wonder how many people use this form: git status -v path1 path2... Because if even somebody who wanted to have "commit preview" in "git status" does not use it for that intended purpose, I think we can reuse the good command name for something more useful, such as "git explain". > I'd really like "git diff" to be what I want more often. Running diff with index is what I do almost all the time. I think "more often" is different from person to person, but if "git diff" says nothing on a file that I know I added (and you cannot argue you do not remember it was a new file here --- you know you added it and that is why you are complaining about not seeing it), I'd be happy that I did not accidentally edited it to munge what I added -- because I add a file only when it is in a presentable, good state, in a good enough shape to take a snapshot (not necessarily good enough to commit, though). And it is not just limited to adding the contents of a path that happened to be told git for the first time. Adding the contents of a path that was known to git also happens only when it is in a presentable good state. So running "git diff" and not seeing what I added before is a GOOD THING. > So I suppose I could implement the "add path without updating content" > I want by doing something like: > > mv file file.tmp > touch file > git update-index --add file > mv file.tmp file > > There. That gives me the result I want without breaking any git > internals, (since I'm just building a new operation on top of existing > git primitives). Sure, what you want is "git add --no-add newfile", and I can understand that mode of operation if you are always going to commit with "git commit -a". Maybe we can have a config variable that makes "commit -a" and "add --no-add" the default for these two commands, and we do not have to change anything else. One minor detail I wonder about is what mode bits would you give to that placeholder entry. > I think the best would be: > > git update-index --all > > which would still allow room for: > > git add --all Wasn't it you who said "all" is ambiguous (all known to git vs all in this directory)? - 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