Hi Peff,
Jeff King wrote:
--- a/read-cache.c
+++ b/read-cache.c
@@ -1800,6 +1800,8 @@ int write_index(struct index_state *istate, int newfd)
continue;
if (!ce_uptodate(ce) is_racy_timestamp(istate, ce))
On Sat, Dec 29, 2012 at 02:03:46AM -0800, Jonathan Nieder wrote:
--- a/read-cache.c
+++ b/read-cache.c
@@ -1800,6 +1800,8 @@ int write_index(struct index_state *istate, int newfd)
continue;
if (!ce_uptodate(ce) is_racy_timestamp(istate, ce))
Jeff King wrote:
I can't reproduce here. I can checkout v3.2.35, and I guess that the
patch you are applying comes from f5f1654, but I don't know your
local modification to sound/usb/midi.c.
No local modification. The unstaged change after git am --abort to
recover from a conflicted git am
Jeff King wrote:
Can you give more details?
$ GIT_TRACE=1 git am --abort
trace: exec: 'git-am' '--abort'
trace: run_command: 'git-am' '--abort'
trace: built-in: git 'rev-parse' '--parseopt' '--' '--abort'
trace: built-in: git 'rev-parse' '--git-dir'
trace: built-in: git 'rev-parse'
On Sat, Dec 29, 2012 at 02:34:30AM -0800, Jonathan Nieder wrote:
Jeff King wrote:
I can't reproduce here. I can checkout v3.2.35, and I guess that the
patch you are applying comes from f5f1654, but I don't know your
local modification to sound/usb/midi.c.
No local modification. The
Jeff King wrote:
Hrm. But your output does not say there is a conflict. It says you have
a local modification and it does not try the merge:
That's probably operator error on my part when gathering output to
paste into the email.
In other words, nothing to see there. :) Sorry for the
On Sat, Dec 29, 2012 at 02:34:30AM -0800, Jonathan Nieder wrote:
$ git am --abort
Unstaged changes after reset:
M sound/usb/midi.c
What does your index look like afterwards? Does it have a null sha1 in
it (check ls-files -s)?
$ git diff-index --abbrev HEAD
:100644
We should never need to write the null sha1 into an index
entry (short of the 1 in 2^160 chance that somebody actually
has content that hashes to it). If we attempt to do so, it
is much more likely that it is a bug, since we use the null
sha1 as a sentinel value to mean not valid.
The presence of
8 matches
Mail list logo
