crashing git rebase
josef...@gmail.com
https://github.com/josef-pkt/statsmodels/commits/cleanup_mc4
is a branch that I tried to rescue from a crashed rebase, but now it
crashes again on rebase.
Is it possible to get a clean rebase of this on a linux machine, or we
just have to live with a messier history?
It merges without problems into master, but has a a bit weird history.
If it helps, I still have the backup of the branch before the broken
rebase, missing the last three commits.
Josef
Yaroslav Halchenko
rebase?
On Wed, 23 Nov 2011, josef...@gmail.com wrote:
> I have a branch that causes git rebase to crash leaving a mess behind.
> https://github.com/josef-pkt/statsmodels/commits/cleanup_mc4
> is a branch that I tried to rescue from a crashed rebase, but now it
> crashes again on rebase.
--
=------------------------------------------------------------------=
Keep in touch www.onerussian.com
Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic
Yaroslav Halchenko
I guess ;-)
On Wed, 23 Nov 2011, Yaroslav Halchenko wrote:
> and by 'crashing' you mean actual crash of git or just conflicts during
> rebase?
--
josef...@gmail.com
<yarik...@gmail.com> wrote:
> for me seems just to fail with conflicts which just need to be resolved
> I guess ;-)
When I merged it into a tmp master, I didn't get any conflicts. Maybe
the conflict is within the branch?
>
> On Wed, 23 Nov 2011, Yaroslav Halchenko wrote:
>> and by 'crashing' you mean actual crash of git or just conflicts during
>> rebase?
crashing I mean segfault, a windows popup: this program did something
nasty and needs to be closed
E:\Josef\eclipsegworkspace\statsmodels-git\statsmodels-josef>git
rebase upstream/master
First, rewinding head to replay your work on top of it...
Applying: ENH/REF: mctools, started cleanup of StatTestMC
Applying: ENH: try_mctools: add plot to example
Applying: ENH: mctools: add docstrings and TODOs for StatTestMC
Applying: ENH: stats: add Lillifors normality test and tabledist, need
refactoring
Applying: ENH/Doc: lilliefors: use tabledist, tabledist: add docstrings
<here I get the popup: git.exe has stopped working, after closing the
popup it continues with:>
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
fatal: Unable to create
'e:/Josef/eclipsegworkspace/statsmodels-git/statsmodels-josef/.git/index.lock':
File exists.
If no other git process is currently running, this probably means a
git process crashed in this repository earlier. Make sure no other git
process is running and remove the file manually to continue.
Failed to merge in the changes.
Patch failed at 0005 ENH/Doc: lilliefors: use tabledist, tabledist:
add docstrings
When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To restore the original branch and stop rebasing run "git rebase --abort".
--------------------------
Thanks for looking,
Josef
josef...@gmail.com
I just kept typing: git rebase --skip
and it continued to the end without any more crashes
https://github.com/josef-pkt/statsmodels/compare/master...cleanup_mc5
looks ok, but I haven't checked yet whether it really has all changes
from the branch
Josef
Yaroslav Halchenko
> nasty and needs to be closed
ah... on linux I didn't observe any such evil behavior -- just stopped
upon a conflict as it should have
> When I merged it into a tmp master, I didn't get any conflicts. Maybe
> the conflict is within the branch?
well -- that branch is indeed non-trivial and includes merges with
messages such as
Merge branch 'b0cfbb77d2e7f098e82948e9521f2ae62980e913' into cleanup_mc4
rebase crashed git, every change was merge conflict
;-) so I guess rebasing (with two places in master which were starting points
for different subbranches within cleanup_mc4) would be non-trivial.
alternative to automated rebasing is just to go and cherry-pick all the commits
(which is probably what rebase does any ways) manually in the order you like
them to appear and resolve conflicts along the way as well.
Otherwise I do not see some magic facility which should figure things out ;-)
if I were you I would have just merged it into master and be 'done' ;)
Yaroslav Halchenko
> https://github.com/josef-pkt/statsmodels/compare/master...cleanup_mc5
> looks ok, but I haven't checked yet whether it really has all changes
> from the branch
which is as easy as just diffing with that "temporary master" where you
had it merged with master (which is a common practice of paranoid me
whenever I am doing rebasing or manual cherry-picking)
josef...@gmail.com
<yarik...@gmail.com> wrote:
>> crashing I mean segfault, a windows popup: this program did something
>> nasty and needs to be closed
>
> ah... on linux I didn't observe any such evil behavior -- just stopped
> upon a conflict as it should have
>
>> When I merged it into a tmp master, I didn't get any conflicts. Maybe
>> the conflict is within the branch?
>
> well -- that branch is indeed non-trivial and includes merges with
> messages such as
>
> Merge branch 'b0cfbb77d2e7f098e82948e9521f2ae62980e913' into cleanup_mc4
> rebase crashed git, every change was merge conflict
>
> ;-) so I guess rebasing (with two places in master which were starting points
> for different subbranches within cleanup_mc4) would be non-trivial.
that was my previous attempt to recover from the rebase crash. Since I
didn't have a backup of the changes, I needed to create some temporary
place to stash the changes that were lost in the crashed rebase.
I wanted to do a selective, cherrypicking merge, but obviously
something went wrong. Loose/unattached (or headless or whatever they
are called) checkouts or states confuse the ... out of me.
git rebase --ignore can drop quite a lot:
changes that were lost and I needed to copy over by hand
https://github.com/josef-pkt/statsmodels/commit/01cbf00d3cc20353a260194baa4e352c0ec36808
(Winmerge is still faster than line by line merge conflict resolution)
Josef
Yaroslav Halchenko
On Wed, 23 Nov 2011, josef...@gmail.com wrote:
> > ;-) so I guess rebasing (with two places in master which were starting points
> > for different subbranches within cleanup_mc4) would be non-trivial.
> that was my previous attempt to recover from the rebase crash.
git rebase --abort
iirc should do that for you, didn't it?
> something went wrong. Loose/unattached (or headless or whatever they
> are called) checkouts or states confuse the ... out of me.
me too ;) but if that happens and I know that this is the correct
"position", I remember shasum for current location, then
git checkout master
git reset --hard THAT_SHASUM
> changes that were lost and I needed to copy over by hand
> https://github.com/josef-pkt/statsmodels/commit/01cbf00d3cc20353a260194baa4e352c0ec36808
why not cherrypick?
> (Winmerge is still faster than line by line merge conflict resolution)
well -- if you know which "side" to take there is always -X option for
merge (and thus cherry-pick which as I had discovered surprisingly
is based on merge)
josef...@gmail.com
<yarik...@gmail.com> wrote:
>
> On Wed, 23 Nov 2011, josef...@gmail.com wrote:
>> > ;-) so I guess rebasing (with two places in master which were starting points
>> > for different subbranches within cleanup_mc4) would be non-trivial.
>> that was my previous attempt to recover from the rebase crash.
>
> git rebase --abort
>
> iirc should do that for you, didn't it?
I didn't want to abort but continue over the problematic changes. I
wanted to pull in the loose changes in the half done rebase, but
instead of cherry-picking one change set it looks like I pulled in the
entire merge branch a second time.
(I did rebase --abort several times until I realized that there is no
clean way to get over it.)
>
>> something went wrong. Loose/unattached (or headless or whatever they
>> are called) checkouts or states confuse the ... out of me.
> me too ;) but if that happens and I know that this is the correct
> "position", I remember shasum for current location, then
>
> git checkout master
> git reset --hard THAT_SHASUM
>
>> changes that were lost and I needed to copy over by hand
>> https://github.com/josef-pkt/statsmodels/commit/01cbf00d3cc20353a260194baa4e352c0ec36808
> why not cherrypick?
I'm scared of it, since merging in some changes (during rebase) got me
into the mess in the first place. This way it's just a new commit.
>
>> (Winmerge is still faster than line by line merge conflict resolution)
>
> well -- if you know which "side" to take there is always -X option for
> merge (and thus cherry-pick which as I had discovered surprisingly
> is based on merge)
never tried, sounds a bit risky
Thanks,
Josef
Yaroslav Halchenko
> > well -- if you know which "side" to take there is always -X option for
> > merge (and thus cherry-pick which as I had discovered surprisingly
> > is based on merge)
> never tried, sounds a bit risky
that is a beauty of git -- you can risk safely ;-) just remember your
previous location (shasum) and you would always be able to get back with
git reset --hard (I also usually keep gitk --all running in the
background view of which I update upon each action -- then all those
"loose" ends remain visible so I could inspect them, or just to reset to
them or any previous location if I desire). and there is always git
reflog
so with git -- you are very safe ;-) just inspect changes/differences
and you should be ok
Skipper Seabold
FWIW, I abuse cherry-pick all the time, even for many changes. It's
how I got the SVAR branch in to shape and also how I merged in the
discrete-refactor. For the latter, I cherry-picked it into a new
branch created off master and then merged no-ff back to master (after
checking in mastertmp, of course), because I couldn't get a clean
merge from the old branch for some reason.
Skipper Seabold
Is anything going on with your cleanup_misc branch as well? I've never
seen this before. If I check it out into a new branch off of the main
repo and try to rebase on master all the commits disappear, but the
changes are there. If I checkout a new branch off master and try to
cherry-pick your changes, as soon as I cherry-pick the oldest one
0af9314, I have all the changes from the subsequent commits. Any ideas
what's going on? Path of least resistance is to cherry-pick the one
change and change the commit message to reflect all the changes.
Aside:
Skipper
josef...@gmail.com
I only tried a plain merge of cleanup_misc into master and there I
only have one merge conflict (shifted #), after resolving the merge
looks clean.
If you do a rebase on current master, then I guess you will get stuck
in the middle of the rebase with the merge conflict.
rebase doesn't report applying any changes after rewinding, so
something got stuck without error message (or there is nothing to
apply).
I don't think I did anything "funny" with the cleanup_misc branch,
just regular commits.
Josef
>
> Aside:
>
> Skipper
>
Skipper Seabold
The problem is that Wes already merged this on October 30th, but the
PR was left open. That was fun.
Skipper
josef...@gmail.com
Oops, I need to remove some branches.
this reminds me, you might have a new change in ecdf which IIRC has
also been merged.
Josef
>
> Skipper
>
Skipper Seabold
We just need to close pull requests after they're merged. No reason to
leave any of them open. I closed the qq-plot as well. If there are
outstanding issues, it shouldn't be merged. If we do merge, then we
should close the PR and outstanding issues should be made an Issue.
> this reminds me, you might have a new change in ecdf which IIRC has
> also been merged.
>
The PR is closed, so it won't show up there. I'd need to submit a new
one. I added interpolation as an option other than the step function
and confidence intervals. I need to check the new confidence intervals
more closely. I'm not totally sure that the index lines up for them. I
just added them when I came across them in Wasserman's 'All of
Nonparamteric Statistics.' The reference says there are tighter ones
but that these are simple, so I just added them in.
Skipper
josef...@gmail.com
What happens in future merges if you keep working on a branch that has
already been merged (possibly with a rebase)?
BTW: how good is Wasserman compared to Haerdle?
Josef
>
> Skipper
>
Skipper Seabold
Ideally, nothing. It should be fine, since the code will be the same
and it will recognize the commits already in master. Here, there are
going to be merge conflicts because of the recent PR on ECDF, but I
can patch it up pretty easily on the merge.
> BTW: how good is Wasserman compared to Haerdle?
>
I don't know Hardle all that well, but I may check it out for my
recent cross-val changes in KDE. (Preview: using Cython for the linbin
function gets us a 100x speed-up and 200-300x+ using also joblib.)
Overall, it's okay. It's comprehensive enough to let you know what's
out there, but not comprehensive enough on the details for my taste.
Comes in around 250 pages, and e.g., KDE cross-val covered in 1 page
and maybe 50 words.
Skipper