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
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 confus
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 modificatio
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' '--show-pref
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
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))
>
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))
> ce_smudge_racily_clea
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 o
8 matches
Mail list logo
