Re: [RFC] git-am: handling unborn branches

Paul Tan [off-list ref] writes:

Hmm, thinking about it, the equivalent C code would be greatly
affected by whatever behavior we go with, so I think we should try
fixing the behavior first.

I am glad to see that sometimes people see the light when I say
one of the greatest strength in scripted Porcelains is that they are
far easier to modify than those writtein in C ;-)

This was done really quickly, but I think this may fix it:
...
However, it assumes that the contents of the index are from the failed
merge. If the user modified the index before running git-am --skip,
e.g. the user added a file, then that file would be deleted, which may
not be desired...

I do not think that is worth worrying about; if users made changes
unrelated to what "git am" asked them to help it apply by modifying
the working tree and updating the index, don't they "lose" their
changes the same way anyway, whether it is a new file or an existing
one?