All of lore.kernel.org
 help / color / mirror / Atom feed
From: Clemens Buchacher <drizzd@aon.at>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, johannes.schindelin@gmx.de, raa.lkml@gmail.com
Subject: Re: [PATCH] modify/delete conflict resolution overwrites untracked file
Date: Tue, 16 Dec 2008 00:02:05 +0100	[thread overview]
Message-ID: <20081215230205.GA19538@localhost> (raw)
In-Reply-To: <7vej09w0hy.fsf@gitster.siamese.dyndns.org>

On Mon, Dec 15, 2008 at 02:13:13PM -0800, Junio C Hamano wrote:
> 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.

  reply	other threads:[~2008-12-15 23:03 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-10 20:12 [PATCH] modify/delete conflict resolution overwrites untracked file Clemens Buchacher
2008-12-10 20:51 ` Junio C Hamano
2008-12-10 21:11   ` Clemens Buchacher
2008-12-10 23:36     ` Junio C Hamano
2008-12-11  8:07       ` Clemens Buchacher
2008-12-11  8:13         ` Junio C Hamano
2008-12-15  0:46 ` Clemens Buchacher
2008-12-15  1:03   ` Junio C Hamano
2008-12-15  3:34     ` Junio C Hamano
2008-12-15  9:34       ` Johannes Schindelin
2008-12-15 10:35         ` Junio C Hamano
2008-12-15 11:03           ` Johannes Schindelin
2008-12-15  9:59       ` Clemens Buchacher
2008-12-15 10:22         ` Junio C Hamano
2008-12-15 10:50           ` Mike Ralphson
2008-12-15 11:09             ` Johannes Schindelin
2008-12-15 11:45               ` Mike Ralphson
2008-12-15 22:13           ` Junio C Hamano
2008-12-15 23:02             ` Clemens Buchacher [this message]
2008-12-16  0:16               ` Junio C Hamano
2008-12-16  1:09                 ` Jakub Narebski
2008-12-28 11:44           ` Clemens Buchacher
2008-12-28 22:21             ` Junio C Hamano
2008-12-28 23:53               ` Clemens Buchacher

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20081215230205.GA19538@localhost \
    --to=drizzd@aon.at \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=johannes.schindelin@gmx.de \
    --cc=raa.lkml@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.