Re: Rebase doesn't restore branch pointer back on out of memory
On 10/03/2012 03:47 PM, Alexander Kostikov wrote: Expected behaviour: - restore branch to pre-rebase location on out of memory exception - not to fall with out of memory in the first place. But for our repository that could be fixed only after either: --- a) msysgit would have x64 binary (currently it's not available) --- b) rebase -m option could be used by default somehow (currently it's not possible so specify default -m) There are already some logic in "rebase" that will handles failures. And in the case of failures, the behavior is that "rebase" will just stop and not modify the branch. That allows you can go back to the pre-rebase state by "rebase --abort". In your case, it's possible that "rebase" is failing at unexpected places, and the error wasn't caught. I tried a few simple cases by forcing some commands to fail during a rebase, but I couldn't reproduce the behavior that you're having. It might help if we can figure out which part of "rebase" or "git" is failing (or running out of memory). And since you're using msysgit, I guess another possible source of the problem is be that msysgit is not catching the error properly, or not relying the error back to git properly. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Rebase doesn't restore branch pointer back on out of memory
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 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Rebase doesn't restore branch pointer back on out of memory
> 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 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 > > 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Rebase doesn't restore branch pointer back on out of memory
> 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 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 > 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 >> >> 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Rebase doesn't restore branch pointer back on out of memory
On 10/04/2012 05:09 PM, Alexander Kostikov wrote: Full script is uploaded to https://dl.dropbox.com/u/10828740/rebase.log Here is the last page: Judging from that log, I'm pretty sure "rebase" is failing at "format-patch". I was able to reproduce the issue you're having: "rebase" finished and modified the branch even though it actually failed. "rebase" is not catching that error. I'll try to come up with a patch to fix it later tonight, so that "rebase" will fail correctly. And when it does, you'll be able to do "rebase --abort" to go back to your original state. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Rebase doesn't restore branch pointer back on out of memory
Thanks, Andrew! I'm looking forward for the patch. On Thu, Oct 4, 2012 at 3:52 PM, Andrew Wong wrote: > On 10/04/2012 05:09 PM, Alexander Kostikov wrote: >> >> Full script is uploaded to >> https://dl.dropbox.com/u/10828740/rebase.log Here is the last page: > > Judging from that log, I'm pretty sure "rebase" is failing at > "format-patch". I was able to reproduce the issue you're having: "rebase" > finished and modified the branch even though it actually failed. > > "rebase" is not catching that error. I'll try to come up with a patch to fix > it later tonight, so that "rebase" will fail correctly. And when it does, > you'll be able to do "rebase --abort" to go back to your original state. > -- Alexander Kostikov -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Rebase doesn't restore branch pointer back on out of memory
'format-patch' is failing due to out of memory, and the error not being caught. So 'rebase' thinks 'am' has completed successfully and continue on with cleanup. i.e. move_to_original_branch So the user loses commits from the original head, and have to rely on reflog to return to the original head. Since the exit status of 'format-patch' is not available, we have to use || with 'format-patch' to handle the error. Also, when 'format-patch' fails, the state_dir does not necessarily exist, so I'm putting the 'format-patch-failed' file inside GIT_DIR. Is there a better location to put such a file? The way I handle the error feels a bit bruteforced. Any suggestions on a better way to handle the error? I also thought about separating 'format-patch' and 'am' into two separate commands, and use an intermediate file to store the output of 'format-patch'. But the intermediate file could get very big, so it didn't seem like a good idea. Andrew Wong (1): rebase: Handle cases where format-patch fails git-rebase--am.sh | 37 +++-- 1 file changed, 35 insertions(+), 2 deletions(-) -- 1.8.0.rc0.18.gf84667d -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Rebase doesn't restore branch pointer back on out of memory
For the 'format-patch' part, originally I was going to do something like:
git format-patch ... || {
...
}
But later I thought it's better to use a consistent style as the following
'am' part.
For the 'am' part, if we kept the following line at the end of the if-block:
fi && move_to_original_branch
then, before exiting the if-block, we would have to do something like:
test 0 != $ret && false
which seems a bit ugly to me. So I removed the use of '&&', and rearrange the
'write_basic_state' and 'move_to_original_branch' to make the logic flow a bit
better and easier to read.
Andrew Wong (1):
rebase: Handle cases where format-patch fails
git-rebase--am.sh | 51 +--
1 file changed, 45 insertions(+), 6 deletions(-)
--
1.8.0.rc0.19.gc58a63a.dirty
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Rebase doesn't restore branch pointer back on out of memory
Sorry to bother but I was wondering what would be the release version
that would have this patch.
-- Alexander
On Wed, Oct 10, 2012 at 8:54 PM, Andrew Wong wrote:
>
> For the 'format-patch' part, originally I was going to do something like:
>
> git format-patch ... || {
> ...
> }
>
> But later I thought it's better to use a consistent style as the following
> 'am' part.
>
> For the 'am' part, if we kept the following line at the end of the if-block:
>
> fi && move_to_original_branch
>
> then, before exiting the if-block, we would have to do something like:
>
> test 0 != $ret && false
>
> which seems a bit ugly to me. So I removed the use of '&&', and rearrange the
> 'write_basic_state' and 'move_to_original_branch' to make the logic flow a bit
> better and easier to read.
>
> Andrew Wong (1):
> rebase: Handle cases where format-patch fails
>
> git-rebase--am.sh | 51 +--
> 1 file changed, 45 insertions(+), 6 deletions(-)
>
> --
> 1.8.0.rc0.19.gc58a63a.dirty
>
--
Alexander Kostikov
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Rebase doesn't restore branch pointer back on out of memory
Alexander Kostikov writes: > Sorry to bother but I was wondering what would be the release version > that would have this patch. That depends on how well the people who are interested in this change test it to smoke out potential issues (if any) in it. It currently is on the 'pu' branch. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
