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

[Rupinderjeet Singh <rupinderjeet47@gmail.com>]

Yes, thank you for being so through with the example. I understand now.

I want to ask if you would suggest that local configuration (or any
information required by the project) that is too sensitive to be
tracked in git, should either be kept as 'untracked' files or 'outside
of git repository'.

Since, any merge or similar action can do this, it should be
considered risky to keep files with important information in
.gitignore file.

As an example, when I am working on an android project, I usually add
firebase-integration info and keystore details in the .gitignore,
because I don't want to add them to version control (even by mistake).
I have seen it as a good practice suggested by many devs around me,
codelabs, online courses, and from experienced developers at google
too.

With your explanation, am I correct to think that only the following
kind of information is suitable to be put in .gitignore files?
1. that can be regenerated
2. that doesn't matter when it is lost
3. that isn't used by the files tracked in git repository

Honestly, the name .gitignore implies that git will completely ignore
these files. Overwriting an ignored file does seem like a violation of
the rule present in .gitignore file. But, if the implementation is
intended as you describe, I have definitely learned something new.

Thank you for your answer. My bad for not including the report-file as
text, it slipped my mind.

From,
Rupinderjeet Singh Hans.


On Sun, 16 Oct 2022 at 00:05, Junio C Hamano <gitster@pobox.com> wrote:
>
> 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.