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

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

Rupinderjeet Singh <rupinderjeet47@gmail.com> writes:

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

I think it depends on the project and participants may not have
control over it if it is ingrained in the project's build structure,
but a separate place may likely be more appropriate, as it would
reduce the chance of accidental "git add ." adding everything.

> 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

Yes.

> 2. that doesn't matter when it is lost

Natural consequence of the above

> 3. that isn't used by the files tracked in git repository

I do not get this, so I decline to comment ;) Is mylib.o that is
"ignored", created from tracked mylib.c source, used by mymain.c
source that is tracked, when mymain.o would not link without what
mylib.o gives it?

Some other SCMs have an extra class "precious" to handle exactly the
case you have in mind.  You do not accidentally let "git add ." to
slurp them into the committed history, but you do want them to be
left alone.  We don't have it, and that is not because we have any
reason to be against having it.  It is just it didn't happen.

And nobody bothered to explore the ramification of adding the new
class yet.  We know about "checkout" and other mergy operations and
"add", but there probably are trickier interactions with other parts
of the existing system that somebody need to carefully go through
and make sure it does not introduce funny inconsistencies.