On Thu, 2013-03-28 at 10:22 -0400, Dale R. Worley wrote:
> > When apply is done and I run "git status -s", the files that were
> > specified as deleted in the diff are marked as " D" but the files that
> > were specified as added in the diff are marked as "??" (untracked), not
> > " A" as I'd expected.  Running "git commit" then will commit the deletes
> > but the added files continue to be untracked, not added (of course).
> OK, I'm not familiar with "git status -s".  I suggest that you do "git
> status" instead and read the output carefully.

The -s flag just prints a shorthand version of the output.  Using -s vs.
not -s does not change the results.  With -s the output is simpler to
read carefully :-).

> According to my understanding, "git status" should report that some
> files have been changed, some deleted, and some added, but it should
> report that *none* of these changes have been staged.

Well, what do you mean by "report that some files have been added"?
What's the status you'd expect to see for those files?  I would expect
to see them listed prefixed with "new file:".  But in fact they're
listed in the "untracked files" section.

> And if you do "git commit", it will object that nothing has changed.

I'm running "git commit -a", which commits all the files that Git knows
about.  This commits the modified and deleted files.  Since these new
files are untracked, or not known to Git, they are not committed.

If I go and run "git add newFile.h" for one of the untracked new files,
now it shows up in "git status" output as a "new file" in the "Changes
to be committed" section, and "git commit -a" will add it as expected.

> In regard to "the files that were specified as added in the diff are
> marked as "??" (untracked)", that is completely correct -- the files
> haven't beed added to the index and are not present in the head
> commit, so they aren't tracked.  ("A file is tracked if it is in the
> base commit of the repository or if it is in the index." -- from my
> writeup of the basics of Git.)

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.

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".

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.

However, I'll work around this by using the --index flag; I can always
un-stage afterwards if I need to.

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