pkgsrc-Users archive

[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
>>> run_specific_rebase():
>>>
>>> >if test 0 != $ret
>>> >then
>>> >        test -d "$state_dir" && write_basic_state
>>> >        return $ret
>>> >fi
>>> >
>>> >move_to_original_branch
>>>
>>> I could not reproduce this behaviour outside of git, but I do have a
>>> copy of git repository which triggers this.  Reverting to 1.8.3.3 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
(1.8.3.3 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).

-- 
Kind regards,
Jan Danielsson



Home | Main Index | Thread Index | Old Index