Duy Nguyen <pclouds@xxxxxxxxx> writes: > On Thu, Aug 23, 2018 at 4:15 AM Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: >> > The remaining question becomes scripts. A script might do >> > >> > ... modify old-file and create new-file ... >> > git add new-file >> > git commit -m "some great message" >> > >> > which would trip this error. For that matter, humans might do that, >> > too. Could the check detect this case (where the only changes in the >> > index are additions of new files) and treat it as non-destructive? >> >> (where the only changes in the index are additions of new files *that >> match the worktree*) > > I don't think my change would affect this case. If "git commit" does > not change the index by itself, there's no point in stopping it. I think the above example forgets "-a" on the final "git commit" step. With it added, I can understand the concern (and I am sure you would, too). The user is trying to add everything done in the working tree, and "commit -a" would catch all changes to paths that were already tracked, but a separate "add" is necessary for newly created paths. But adding a new path means the index no longer matches HEAD, and the "commit -a" at the final step sweeps the changes to already tracked paths---failing that because there "already is something staged" will break the workflow.
