Git development
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Tomas Pospisek <tpo@sourcepole.ch>
Cc: git@vger.kernel.org
Subject: Re: Bug? file at the same time being deleted and not registered
Date: Mon, 24 May 2010 04:24:30 -0400	[thread overview]
Message-ID: <20100524082430.GA18755@coredump.intra.peff.net> (raw)
In-Reply-To: <alpine.DEB.2.00.1005240932130.7107@tpo-laptop>

On Mon, May 24, 2010 at 10:02:14AM +0200, Tomas Pospisek wrote:

> >Can you try running the output of "git diff-files --name-only" and "git
> >ls-files -o" through xxd or something that would show individual bytes?
> >My suspicion is that the "a_file" shown in each may not be bit-for-bit
> >identical.
> 
>  $ git diff-files --name-only
>  $ # no output at all

Hrm, I had originally thought that your "git status" output showed
a_file as deleted in the working tree, which is why I suggested
diff-files. But looking at your output again, I see that it is scheduled
for deletion. In other words, the index entry has been removed entirely,
as if "git rm --cached a_file" had been issued.

So I think I was on the wrong track with the filename-munging, then.
Sorry to lead you astray. But the problem is that your index is missing
or bogus, which is even weirder.

Looking at your strace dump, I see it writing out the index (it writes
to index.lock and then renames it into place). Can you take a look at
your .git/index file? It should be 104 bytes and look something like:

  $ xxd .git/index
  0000000: 4449 5243 0000 0002 0000 0001 4bfa 367d  DIRC........K.6}
  0000010: 0000 0000 4bfa 367d 0000 0000 0000 0900  ....K.6}........
  0000020: 0099 801d 0000 81a4 0000 03e8 0000 03e8  ................
  0000030: 0000 0000 e69d e29b b2d1 d643 4b8b 29ae  ...........CK.).
  0000040: 775a d8c2 e48c 5391 0006 615f 6669 6c65  wZ....S...a_file
  0000050: 0000 0000 1f80 d668 c07b 5955 8678 4360  .......h.{YU.xC`
  0000060: 8215 6238 89be 9b4d

It won't match byte-for-byte because there is stat information in there,
but you should see a_file.

If it's empty or 32 bytes, then that explains what status is reporting
(but the question still remains how we got into that state).

-Peff

  reply	other threads:[~2010-05-24  8:24 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-23 21:09 Bug? file at the same time being deleted and not registered Tomas Pospisek
2010-05-23 23:44 ` Jeff King
2010-05-24  8:02   ` Tomas Pospisek
2010-05-24  8:24     ` Jeff King [this message]
2010-05-24  8:29       ` Tomas Pospisek
2010-05-24  8:49         ` Jeff King
2010-05-24  9:26           ` Tomas Pospisek
2010-05-24 10:32           ` Tomas Pospisek
2010-05-24 14:46             ` Tomas Pospisek

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=20100524082430.GA18755@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=tpo@sourcepole.ch \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox