Re: [PATCH] modify/delete conflict resolution overwrites untracked file

From: Clemens Buchacher <drizzd@aon.at>
Date: Dec 15, 2008, 23:02 UTC
Message-ID: <20081215230205.GA19538@localhost>
In-Reply-To: <7vej09w0hy.fsf@gitster.siamese.dyndns.org>

On Mon, Dec 15, 2008 at 02:13:13PM -0800, Junio C Hamano wrote:

Show 11 quoted lines

> You can do a merge inside a dirty work tree, and the merge will fail
> without clobbering your work tree files that are dirty when it needs to be
> able to overwrite to do its job.  The set of "dirty files" in this
> sentence of course includes paths that are modified since HEAD, but it
> also includes also paths that do not exist in HEAD (i.e. "new files").
> 
> But we already caution users that you need to know what you are doing when
> working in such a dirty work tree.  Namely, after a failed merge, your
> next "git reset --hard" will blow away your local modifications.  And
> local modifications in this context includes the files you could have
> added to the index but you haven't.

I strongly disagree. With the suggested behavior I would have to double-check every single untracked file in my tree for conflicts before trying a throw-away merge followed by git reset --hard, for example. The file could even be ignored! Whatever happened to git reset doesn't touch untracked files?

I would even prefer breaking t6023 (until we can properly implement this feature) in order to avoid that.