Clemens Buchacher [off-list ref] writes:
By default, checkout and fast-forward merge will overwrite ignored
files. Make this behavior configurable.
Just mentionning an alternative, or complementary approach:
Instead of overwritting completely a .gitignore-d file, Git could
rename it, and warn the user kindly. For example:
$ git merge
...
Warning: existing ignored file 'foo' renamed to 'foo~'
(in case foo~ already exists, it's possible to use numbered backups
just like "mv --backup=existing" does for example)
That could complement your patch if core.overwriteignored is a
multiple-choice option instead of a Boolean:
- "overwrite" => current behavior
- "refuse" => your proposal
- "rename" => my proposal
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
Am 23.08.2010 11:37, schrieb Matthieu Moy:
Clemens Buchacher [off-list ref] writes:
quoted
By default, checkout and fast-forward merge will overwrite ignored
files. Make this behavior configurable.
Just mentionning an alternative, or complementary approach:
Instead of overwritting completely a .gitignore-d file, Git could
rename it, and warn the user kindly. For example:
You've got my vote. This is the only option that combines safety with
minimal configuration hassle.
I didn't know about this subtle difference between .gitignore and
.git/info/exclude. And while this makes sense I expect a sizable
percentage of users will never even know that .git/info/exclude exists.
And in practice I guess a lot of files will get added to .gitignore even
though they only are relevant to one user (out of carelessness or
ignorance). I know I have added patterns without making a conscious
decision about their relevance to others.
On Mon, Aug 23, 2010 at 03:56:39PM +0200, Holger Hellmuth wrote:
You've got my vote. This is the only option that combines safety with
minimal configuration hassle.
I didn't know about this subtle difference between .gitignore and
.git/info/exclude. And while this makes sense I expect a sizable
percentage of users will never even know that .git/info/exclude exists.
I don't know if this subtle difference was even intentional. But it
makes sense, and we simply need to make it explicit by documenting
it and by making it optional.
And in many cases, that behavior makes sense. Imagine a generated
file is accidentally added to git, later removed from version
control and added to .gitignore instead. A common scenario, I am
sure.
Now if you start merging, rebasing or bisecting with such a
history, you _will_ run into this problem all the time.
Renaming is certainly a possibility, but it does not really solve
the problem. We will end up with a bunch of renamed, possibly
precious files in our work tree, which means we have to clean up
manually anyways.
So I think it is better to make the decision whether or not a file
is precious at the time it is added to .gitignore. In other words,
never add precious files to .gitignore, but add them to
.git/info/exclude instead.
And in practice I guess a lot of files will get added to
.gitignore even though they only are relevant to one user (out of
carelessness or ignorance). I know I have added patterns without
making a conscious decision about their relevance to others.
Then you have been using it wrong, just like I have.
Ignorant/careless users may still make that mistake, but if git
does not overwrite such files by default, at least they made a
conscious decision at some point to take that risk.
That is if we can make it the default.
Clemens