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@xxxxxxxxx> 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.
