Re: Merge with local conflicts in new files

[Pavel Roskin <proski@gnu.org>]

Hello, Junio!

On Tue, 2006-05-16 at 16:28 -0700, Junio C Hamano wrote:
> Santi <sbejar@gmail.com> writes:
> 
> > 2006/5/17, Junio C Hamano <junkio@cox.net>:
> >>  - You have not told git that these files matter.
> >
> > For me it is the other way, all my files matter but git can do
> > whatever it wants with the ones it controls.
> 
> You really do not mean that.
> 
> If you told git a file matters, and have local modifications to
> the file in the working tree that you have not run update-index
> yet, merge and apply should be careful not to overwrite your
> changes that is not ready while doing whatever thing they have
> to do.  And they are careful, because you have told git that
> they matter, and the way you tell git that they matter is to
> have entries for them in the index.

I'm afraid this approach, while understandable from the technical
standpoint, could prevent git from ever becoming a version control
system that "just works" without any porcelains.

I know a person who refuses to use any version control.  If he
encountered this situation, he would never try any version control
again.

After all, we are talking about files in the _working_ directory.  It's
not merely a transient appendix to the repository.  git is not the only
player here.  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.

Merging a branch should not cause an irreparable loss of user data.  The
same applies to other commands.  Exceptions can be made for commands
that are specifically meant to clean user data, for commands with
special options (e.g. --force or --hard), and for the files explicitly
marked as transient (e.g. in .gitignore).

-- 
Regards,
Pavel Roskin