> From: Paul Smith <p...@mad-scientist.net> > > Maybe I should restate. The problem is that if I run "git apply" > followed by "git commit -a", the files that were modified and deleted > are both committed, but new files from the patch are not committed.
That is true. > I sort of understand it from a Git point of view, since unlike modified > or deleted files there's no way to have a state of "added but not > staged" in Git. Nevertheless, to me this is an unexpected difference in > behavior between change/delete/add files in "git apply". Mostly it's because you're using "git commit -a", which doesn't really do what you want, which is "commit all the changes in the working directory". "git commit -a" means "commit all the changes to the files that *Git is already tracking* in the working directory. If you want to commit *all* changes, you want to do "git add --all ; git commit". If you think about it, in many situations "git commit -a" is what a software developer wants to use. Various trash files can accumulate in a working copy; you usually only want to commit files that have been specially pointed out as being valuable. > As an example of the kind of problem this creates, if I have a workspace > with some untracked files in it and then I run "git apply", I now have > no way to tell which files were created as part of the "git apply" and > should be added to my commit with "git add", and which were there before > and should not be added. You really, really shouldn't use "git apply" unless the working copy is clean. (Unless you want to combine the changes that "git apply" makes with all the changes that are already present to make one commit.) Dale -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.