> 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

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


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.

Reply via email to