Re: Merge with local conflicts in new files

From: Pavel Roskin <proski@gnu.org>
Date: May 17, 2006, 07:47 UTC
Message-ID: <1147852052.31879.50.camel@dv>
In-Reply-To: <7vu07p35xn.fsf@assigned-by-dhcp.cox.net>

Hello, Junio!

On Tue, 2006-05-16 at 16:28 -0700, Junio C Hamano wrote:

Show 17 quoted lines

> 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