Re: [suggestion] Fail cherry-pick if it overwrites untracked files with the matching file names

[Junio C Hamano <gitster@pobox.com>]

If the situation is about cherry-picking a commit that adds a new
file F to a checkout of another commit that lacks the file F, I
think the command is working exactly as designed.

    $ git init
    $ git commit -m 'initial' --allow-empty
    $ git tag initial
    $ date >file
    $ git add file
    $ git commit -m 'add file'
    $ git tag added
    $ git checkout -b second initial
    ... at this point we are back to the original state
    ... without 'file'
    $ >file
    ... the file is untracked with precious contents
    ... and the presence of it stops a cherry-pick that clobbers it
    $ git cherry-pick added
    error: The following untracked working tree files would be overwritten by merge:
            file
    Please move or remove them before you merge.
    Aborting
    fatal: cherry-pick failed

Now continuing from the above, things get (slightly) interesting

    $ echo file >.gitignore
    $ git cherry-pick added

This will replace "file" with the one from the "added" commit, and
that is because the user marked that the "file" in the working tree
is expendable.

Files in a working tree controlled by git fall into one of three
classes.  Tracked files are those that are known to the index and
appear in "git ls-files" output.  Among the others, ignored files
are those that .gitignore mechanism says are expendable.  The rest
are "untracked", possibly containing valuable contents that should
not be lost as the user may choose to 'git add' them later.

Not just cherry-pick but any merge-related operations, including
"checkout", follow this semantics.  Untracked files are kept, but
ignored files are expendable and will be removed if they are in the
way to complete the operation the user asks.

    $ rm .gitignore
    $ git checkout master
    error: The following untracked working tree files would be overwritten by checkout:
            file
    Please move or remove them before you switch branches.
    Aborting

    $ echo file >.gitignore
    $ git checkout master
    ... this should succeed, removing "file" whose contents were
    ... marked expendable.

Of course, after switching to 'master' (or cherry-picking 'added'),
the project now cares about the 'file'.  After all, it bothered to
add it to keep track of the changes to its contents.  So it is
recommended that you would adjust the contents of .gitignore so that
it no longer is marked as expendable.