Re: Rebase doesn't restore branch pointer back on out of memory

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> rebase -i fails with different error:
Also in case of rebase -i the branch pointer is not changed. Thus
nothing to fix there.

-- Alexander

On Thu, Oct 4, 2012 at 2:09 PM, Alexander Kostikov
<alex.kostikov@xxxxxxxxx> wrote:
>> Having the
>> last page of that output should give us enough context as to where it's
>> failing.
> Full script is uploaded to
> https://dl.dropbox.com/u/10828740/rebase.log Here is the last page:
>
> -----------------------------------[code]
> if test -s "$dotest"/rewritten; then
>     git notes copy --for-rewrite=rebase < "$dotest"/rewritten
>     if test -x "$GIT_DIR"/hooks/post-rewrite; then
>         "$GIT_DIR"/hooks/post-rewrite rebase < "$dotest"/rewritten
>     fi
> fi
>
> rm -fr "$dotest"
> git gc --auto
> git rev-parse HEAD
>
> ret=$?
> test 0 != $ret -a -d "$state_dir" && write_basic_state
> exit $ret
> -----------------------------------[/code]
>
>
>> It'd also be interesting to see if "rebase -i" will also workaround the
>> issue.
>
> rebase -i fails with different error:
>
> » git rebase -i master rebase_debug
> fatal: Out of memory, malloc failed (tried to allocate 458753 bytes)
>
> Do you need verbose log for it as well?
>
> -- Alexander
>
>
> On Thu, Oct 4, 2012 at 8:13 AM, Andrew Wong <andrew.kw.w.lists@xxxxxxxxx> wrote:
>> On 10/03/2012 06:35 PM, Alexander Kostikov wrote:
>>>>
>>>> That allows you can go back to the pre-rebase state by
>>>> "rebase --abort".
>>>
>>> rebase --abort command were not available. I guess rebase file was not
>>> created.
>>
>> I meant "rebase --abort" would be available *if* the error was caught by
>> "rebase". But in your case, "rebase" is probably dying somewhere and the
>> error was not caught, causing "rebase" to think that everything completed
>> successfully, and go ahead to update the branch.
>>
>>
>>> Is there a way to include some log verbose mode to detect where
>>> exactly error happens?
>>
>> There isn't any built-in to git itself. But one way to get more info is
>> running the rebase command this way:
>>     env SHELLOPTS="verbose" git rebase <your arguments>
>>
>> That should print out every shell command that rebase executes. Having the
>> last page of that output should give us enough context as to where it's
>> failing.
>>
>> Just a wild guess: rebase is probably failing at the "format-patch" command.
>> It'd also be interesting to see if "rebase -i" will also workaround the
>> issue. But like you said, there's no way set "-i" or "-m" as the default.
>
>
>
> --
> Alexander Kostikov



-- 
Alexander Kostikov
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]