Quoting Johannes Sixt <j.sixt@xxxxxxxxxxxxx>: > Please don't top-post. > > Nathan Yergler schrieb: >> Can you elaborate on why doing -i automatically is a bad idea in this >> case? [It may really be, I don't pretend to have enough knowledge >> about git's internals to make a reasoned argument.] This was >> unexpected behavior for me as I'd always experienced "git add path && >> git commit" and "git commit path" as being equivalent and so I assumed >> they would work equivalently in this situation. > > They are not equivalent. 'git add path && git commit' commits changes to > path *in addition* to what is already staged before you run this command > sequence. But 'git commit path' commits *only* changes to path, leaving > other changes that might be staged uncommitted. > > It may become obvious why the latter behavior is unwanted if a merge is in > progress: The merge left changes (and conflicts) in the index; but with > 'git commit path' you say that you are not interested in what the index has. Your explanation is a good answer to Nathan's misunderstanding; "git add path && git commit" and "git commit path" are different. But Nathan's first sentence is a different matter. I do not think it is coming from the same confusion, and I think the question is a valid one. Your answer does not explain why it is a bad idea to change the behavior of "git commit path" to what "git commit -i path" does during a merge. The answer of course can be "because it changes the behavior people are very much used to." -- Nanako Shiraishi http://ivory.ap.teacup.com/nanako3/ -- 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
