[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: 2013Q3 freeze pre-announcement
On 09/14/13 15:13, Sergey Svishchev wrote:
>>> git 1.8.4's rebase scripts misbehave in 6.1 -- if automatic merge
>>> fails and you are asked to merge manually, you cannot continue the
>>> rebase since .git/rebase-apply is deleted. Somehow, this 'if' block
>>> is not 'returning' and execution continues after 'fi'. It's sourced
>>> from libexec/git-core/git-rebase--am by libexec/git-core/git-rebase in
>>> >if test 0 != $ret
>>> > test -d "$state_dir" && write_basic_state
>>> > return $ret
>>> I could not reproduce this behaviour outside of git, but I do have a
>>> copy of git repository which triggers this. Reverting to 184.108.40.206 works.
>> Have you reported this upstream? I think they are the people most
>> likely to fix this.
> Not yet -- at this point I'm not sure where the bug is, their code or
> our shell.
I don't know if it's related, but if I run "git pull" (git 1.8.4
(220.127.116.11 does not appear to be affected) on NetBSD 6.1) in a repository
with no local changes, git thinks I've made a lot of changes -- which
includes conflicts, oddly enough.
For whatever reason if I run "git fetch && git pull" I can avoid
triggering the problem.
(I mention this simply as a temporary work-around if anyone else is
running into the problem).
Main Index |
Thread Index |