Re: Possible regression: overwriting untracked files in a fresh repo

From: Jeff King <peff@peff.net>
Date: Aug 25, 2009, 01:47 UTC
Message-ID: <20090825014738.GA7655@coredump.intra.peff.net>
In-Reply-To: <20090825013601.GA3515@coredump.intra.peff.net>

On Mon, Aug 24, 2009 at 09:36:01PM -0400, Jeff King wrote:

Show 7 quoted lines

> I don't think this is the right thing to do. We have _no_ current
> branch, which means that everything in the working tree can be
> considered untracked (and therefore precious). So I think the right
> thing to do is barf and say "this untracked file would be overwritten".
> The user can sort it out as appropriate, either deleting files that are
> in the way, or using "-f" themselves (after they make the decision that
> what they have can be overwritten).

Actually, let me clarify that a bit. If we have no branch _and_ we have no index, then everything is untracked. If we do have an index, then we do a two-way merge from the HEAD. So if we have no branch in that case, it makes sense to me to treat every element of the index as an addition, meaning that anything in the new tree that is different should be a conflict.

And that is what my patch does: it pretends that the HEAD is the empty tree, which should produce sane output in both cases:

  $ echo content >file
  $ git checkout -b foo origin ;# origin has 'file' in it
  error: Untracked working tree file 'file' would be overwritten by merge.
  $ git add file
  $ git checkout -b foo origin
  error: Entry 'file' would be overwritten by merge. Cannot merge.

and it even handles the matching-index case when the merge is a no-op:

  $ git show origin:file >file ;# match contents
  $ git checkout -b foo origin
  error: Untracked working tree file 'file' would be overwritten by merge.
  $ git add file
  $ git checkout -b foo origin
  Switched to a new branch 'foo'

-Peff