Re: Merge with local conflicts in new files

From: Martin Langhoff <martin.langhoff@gmail.com>
Date: May 17, 2006, 08:50 UTC
Message-ID: <46a038f90605170150x361892abv8df226aa899f1a95@mail.gmail.com>
In-Reply-To: <1147852052.31879.50.camel@dv>

On 5/17/06, Pavel Roskin <proski@gnu.org> wrote:

> If a file doesn't "belong" to git, it belongs to its
> "supreme commander", i.e. the user, and should be approached with utmost
> care.

+1 here. Unknown files are precious (to take an Arch term) until git is told otherwise.

> special options (e.g. --force or --hard), and for the files explicitly
> marked as transient (e.g. in .gitignore).

I think that if we turn into clobbering files listed in .gitignore users will probably be screaming bloody murder. No git op should clobber untracked files...

Arch has this strange concept of allowing you to list 'junk' files. I could never figure out why it would want my authorization to remove files randomly. For all its faults, cvs does the right thing -- it will say 'checkout/update of foo.c blocked by foo.c in directory'. And if you force it with -C it will rename the local file to .#originalname-local or something like that.

Even the files I think of as junk are actually useful and should not be messed up with. Editor temp files, for instance, are often listed in .gitignore, and if you ask me, they are junk. Except while I am working with my editor! ;-)

Another case is .project files from IDEs like Eclipse. People list them in .cvsignore so that they are not committed, and yet preserved. The user probably has a lot of personal settings there.

cheers,

martin