How to recover from total git screwup?
113 views
Skip to first unread message
Simon King
Sep 27, 2019, 2:17:55 PM9/27/19
to sage-...@googlegroups.com
Hi!
At some point I was advised to use "git worktree" to have one py2 and
one py3 installation sharing the same git repository. Till one hour ago,
it worked fine.
Now, if I understand correctly, in my py2 worktree, I was on the develop
branch. There was one branch "foobar" (not its real name) that meanwhile
is fully merged, so that I thought it was safe to do "git branch -d foobar".
However, it seems that my py3 worktree was on that now deleted branch.
I am not totally sure if that's what was happening. Would git really
allow the "git branch -d" operation when another worktree is on that
branch?
In any case, my bash history shows that at some point I did
"git branch -d foobar", and when I am in the py3 worktree, I now get
$ git log
fatal: your current branch 'foobar' does not have any commits yet
Indeed, all files in the Sage tree are untracked, in the py3 worktree.
And that's why "git checkout develop" won't work (it tells me to commit
are stash first).
Can you please tell me how to recover from that mess?
Best regards,
Simon
At some point I was advised to use "git worktree" to have one py2 and
one py3 installation sharing the same git repository. Till one hour ago,
it worked fine.
Now, if I understand correctly, in my py2 worktree, I was on the develop
branch. There was one branch "foobar" (not its real name) that meanwhile
is fully merged, so that I thought it was safe to do "git branch -d foobar".
However, it seems that my py3 worktree was on that now deleted branch.
I am not totally sure if that's what was happening. Would git really
allow the "git branch -d" operation when another worktree is on that
branch?
In any case, my bash history shows that at some point I did
"git branch -d foobar", and when I am in the py3 worktree, I now get
$ git log
fatal: your current branch 'foobar' does not have any commits yet
Indeed, all files in the Sage tree are untracked, in the py3 worktree.
And that's why "git checkout develop" won't work (it tells me to commit
are stash first).
Can you please tell me how to recover from that mess?
Best regards,
Simon
Simon King
Sep 27, 2019, 4:51:05 PM9/27/19
to sage-...@googlegroups.com
On 2019-09-27, Simon King <simon...@uni-jena.de> wrote:
> Indeed, all files in the Sage tree are untracked, in the py3 worktree.
> And that's why "git checkout develop" won't work (it tells me to commit
> are stash first).
>
> Can you please tell me how to recover from that mess?
Perhaps "git checkout -f <branch_name>" in the py3 worktree? Or would
> Indeed, all files in the Sage tree are untracked, in the py3 worktree.
> And that's why "git checkout develop" won't work (it tells me to commit
> are stash first).
>
> Can you please tell me how to recover from that mess?
that do more harm than good? Certainly "git stash" is not a serious
option, as this would be a copy of the whole Sage sources (namely the
diff between a branch with an empty commit history and the Sage
sources).
Best regards,
Simon
Kwankyu Lee
Sep 27, 2019, 7:59:48 PM9/27/19
to sage-devel
On Saturday, September 28, 2019 at 3:17:55 AM UTC+9, Simon King wrote:
Hi!
At some point I was advised to use "git worktree" to have one py2 and
one py3 installation sharing the same git repository. Till one hour ago,
it worked fine.
Now, if I understand correctly, in my py2 worktree, I was on the develop
branch. There was one branch "foobar" (not its real name) that meanwhile
is fully merged, so that I thought it was safe to do "git branch -d foobar".
However, it seems that my py3 worktree was on that now deleted branch.
I am not totally sure if that's what was happening. Would git really
allow the "git branch -d" operation when another worktree is on that
branch?
If you were at foobar in py3 worktree and at develop in py2 worktree, no.
In any case, my bash history shows that at some point I did
"git branch -d foobar", and when I am in the py3 worktree, I now get
$ git log
fatal: your current branch 'foobar' does not have any commits yet
Indeed, all files in the Sage tree are untracked, in the py3 worktree.
And that's why "git checkout develop" won't work (it tells me to commit
are stash first).
Can you please tell me how to recover from that mess?
Why not just add a new shiny py3 worktree and move your untracked files from the old py3 worktree to the new one?
Simon King
Sep 28, 2019, 2:25:33 AM9/28/19
to sage-...@googlegroups.com
Hi Kwankyu,
On 2019-09-27, Kwankyu Lee <ekwa...@gmail.com> wrote:
>> I am not totally sure if that's what was happening. Would git really
>> allow the "git branch -d" operation when another worktree is on that
>> branch?
>>
>
> If you were at foobar in py3 worktree and at develop in py2 worktree, no.
Then what else has happened? According to my bash history, this is
basically what I did:
- I was on foobar branch in my py3 worktree. Foobar is in fact
the same as the branch from trac ticket #28444.
- I went to my py2 worktree and checked out "develop". After "git pull",
I realised that "foobar" already is merged in "develop".
- Still in the py2 worktree, I went to some branch "baz", which is
a few commits ahead of foobar, and at that point was the branch of
trac ticket #28414.
- Since foobar was in develop, I did "git branch -d foobar", still in the
py2 worktree. It worked without complaints. Note: It was "-d",
not "-D".
- Still in py2 worktree, I rebased "baz" on top of "develop", and
force-pushed it to trac ticket #28414.
- I went to my py3 worktree, did "git status", got some hundreds of
pages of output, although I didn't edit any file since my last visit
of the py3 worktree. I tried "git checkout develop", which failed, because
git told me to first commit or stash my changes. I did "git log",
which told me that there were absolutely no commits yet.
>> Can you please tell me how to recover from that mess?
>
>
> Why not just add a new shiny py3 worktree and move your untracked files
> from the old py3 worktree to the new one?
My hope was that I can somehow recover from the mess without rebuilding
all of sage-on-py3. Plus, in "reality" (from my perspective, "reality"
is the opposite to "git history") there are no untracked files. The
files in my py3 worktree are physically the same as those from the git
branch from #28444, that is still available in my py2 worktree.
That's why I thought "git checkout -f develop" in the py3 worktree might
help. But perhaps after that I'd need to rebuild Sage from scratch, too?
Anyway, before trying a forced operation: Would it potentially create
even more mess?
Best regards,
Simon
On 2019-09-27, Kwankyu Lee <ekwa...@gmail.com> wrote:
>> I am not totally sure if that's what was happening. Would git really
>> allow the "git branch -d" operation when another worktree is on that
>> branch?
>>
>
> If you were at foobar in py3 worktree and at develop in py2 worktree, no.
basically what I did:
- I was on foobar branch in my py3 worktree. Foobar is in fact
the same as the branch from trac ticket #28444.
- I went to my py2 worktree and checked out "develop". After "git pull",
I realised that "foobar" already is merged in "develop".
- Still in the py2 worktree, I went to some branch "baz", which is
a few commits ahead of foobar, and at that point was the branch of
trac ticket #28414.
- Since foobar was in develop, I did "git branch -d foobar", still in the
py2 worktree. It worked without complaints. Note: It was "-d",
not "-D".
- Still in py2 worktree, I rebased "baz" on top of "develop", and
force-pushed it to trac ticket #28414.
- I went to my py3 worktree, did "git status", got some hundreds of
pages of output, although I didn't edit any file since my last visit
of the py3 worktree. I tried "git checkout develop", which failed, because
git told me to first commit or stash my changes. I did "git log",
which told me that there were absolutely no commits yet.
>> Can you please tell me how to recover from that mess?
>
>
> Why not just add a new shiny py3 worktree and move your untracked files
> from the old py3 worktree to the new one?
all of sage-on-py3. Plus, in "reality" (from my perspective, "reality"
is the opposite to "git history") there are no untracked files. The
files in my py3 worktree are physically the same as those from the git
branch from #28444, that is still available in my py2 worktree.
That's why I thought "git checkout -f develop" in the py3 worktree might
help. But perhaps after that I'd need to rebuild Sage from scratch, too?
Anyway, before trying a forced operation: Would it potentially create
even more mess?
Best regards,
Simon
Simon King
Sep 28, 2019, 7:05:35 AM9/28/19
to sage-...@googlegroups.com
Here is how to reproduce the git problem at least to some extent:
king@klap:~$ mkdir gittest
king@klap:~$ cd gittest
king@klap:~/gittest$ mkdir A
king@klap:~/gittest$ cd A
king@klap:~/gittest/A$ git init
Initialized empty Git repository in /home/king/gittest/A/.git/
king@klap:~/gittest/A$ touch file1
king@klap:~/gittest/A$ git add file1
king@klap:~/gittest/A$ git commit -m "First"
[master (root-commit) 64e0df0] First
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 file1
king@klap:~/gittest/A$ git worktree add -b foobar ../B master
Preparing ../B (identifier B)
HEAD is now at 64e0df0 First
king@klap:~/gittest/A$ touch file2
king@klap:~/gittest/A$ git add file 2
fatal: pathspec 'file' did not match any files
king@klap:~/gittest/A$ git add file2
king@klap:~/gittest/A$ git commit -m "Second"
[master abd4169] Second
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 file2
king@klap:~/gittest/A$ git branch -d foobar
Deleted branch foobar (was 64e0df0).
king@klap:~/gittest/A$ cd ../B
king@klap:~/gittest/B$ git log
On branch foobar
Initial commit
Changes to be committed:
(use "git rm --cached <file>..." to unstage)
new file: file1
king@klap:~/gittest/B$ ls
file1
I believe it is a bug that git allowed me the "git branch -d foobar"
operation. If someone knowing where to report a git bug agrees that it
is a bug, please go ahead.
But now comes a surprise:
king@klap:~/gittest/B$ git checkout -b new_foobar master
Switched to a new branch 'new_foobar'
king@klap:~/gittest/B$ git status
On branch new_foobar
nothing to commit, working directory clean
king@klap:~/gittest/B$ ls
file1 file2
That's really a surprise. So, I tried the same in my Sage git repository.
Unfortunately it was not successful:
$ git checkout -b t/28414/p_group_cohomology_in_PY3 t/28414/p_group_cohomology_in_py_3
... <listing all Sage source files> ...
Please, commit your changes or stash them before you can switch branches.
Aborting
I wonder what's different. I am still reluctant to do "git checkout -f
<branchname>", but perhaps that would be my best bet.
Best regards,
Simon
king@klap:~$ mkdir gittest
king@klap:~$ cd gittest
king@klap:~/gittest$ mkdir A
king@klap:~/gittest$ cd A
king@klap:~/gittest/A$ git init
Initialized empty Git repository in /home/king/gittest/A/.git/
king@klap:~/gittest/A$ touch file1
king@klap:~/gittest/A$ git add file1
king@klap:~/gittest/A$ git commit -m "First"
[master (root-commit) 64e0df0] First
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 file1
king@klap:~/gittest/A$ git worktree add -b foobar ../B master
Preparing ../B (identifier B)
HEAD is now at 64e0df0 First
king@klap:~/gittest/A$ touch file2
king@klap:~/gittest/A$ git add file 2
fatal: pathspec 'file' did not match any files
king@klap:~/gittest/A$ git add file2
king@klap:~/gittest/A$ git commit -m "Second"
[master abd4169] Second
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 file2
king@klap:~/gittest/A$ git branch -d foobar
Deleted branch foobar (was 64e0df0).
king@klap:~/gittest/A$ cd ../B
king@klap:~/gittest/B$ git log
fatal: your current branch 'foobar' does not have any commits yet
king@klap:~/gittest/B$ git status
On branch foobar
Initial commit
Changes to be committed:
(use "git rm --cached <file>..." to unstage)
new file: file1
king@klap:~/gittest/B$ ls
file1
I believe it is a bug that git allowed me the "git branch -d foobar"
operation. If someone knowing where to report a git bug agrees that it
is a bug, please go ahead.
But now comes a surprise:
king@klap:~/gittest/B$ git checkout -b new_foobar master
Switched to a new branch 'new_foobar'
king@klap:~/gittest/B$ git status
On branch new_foobar
nothing to commit, working directory clean
king@klap:~/gittest/B$ ls
file1 file2
That's really a surprise. So, I tried the same in my Sage git repository.
Unfortunately it was not successful:
$ git checkout -b t/28414/p_group_cohomology_in_PY3 t/28414/p_group_cohomology_in_py_3
... <listing all Sage source files> ...
Please, commit your changes or stash them before you can switch branches.
Aborting
I wonder what's different. I am still reluctant to do "git checkout -f
<branchname>", but perhaps that would be my best bet.
Best regards,
Simon
Simon King
Oct 1, 2019, 3:57:51 AM10/1/19
to sage-...@googlegroups.com
On 2019-09-28, Simon King <simon...@uni-jena.de> wrote:
> I wonder what's different. I am still reluctant to do "git checkout -f
><branchname>", but perhaps that would be my best bet.
I tried, and it seemed to work.
> I wonder what's different. I am still reluctant to do "git checkout -f
><branchname>", but perhaps that would be my best bet.
However, someone who knows about git (i.e., not I) should report the bug
that git allows deletion of a branch that is checked out in another
worktree.
Best regards,
Simon
Kwankyu Lee
Oct 1, 2019, 9:48:48 PM10/1/19
to sage-devel
However, someone who knows about git (i.e., not I) should report the bug
that git allows deletion of a branch that is checked out in another
worktree.
I don't see that bug. This is what happens when I try that: (* denotes the branch on the worktree I am currently on; + denotes branch checked out on other worktrees)
Hera:sage-dev$ g branch
...
develop
master
* picklable-trac28096
...
+ research-base
..
+ temp
trace-trac9704
Hera:sage-dev$ g branch -d temp
error: Cannot delete branch 'temp' checked out at '/Users/kwankyu/GitHub/temp'
Hera:sage-dev$ g branch -d research-base
error: Cannot delete branch 'research-base' checked out at '/Users/kwankyu/GitHub/sage'
Hera:sage-dev$ g version
git version 2.23.0 Simon King
Oct 2, 2019, 4:09:01 AM10/2/19
to sage-...@googlegroups.com
On 2019-10-02, Kwankyu Lee <ekwa...@gmail.com> wrote:
> Hera:sage-dev$ g version
> git version 2.23.0
$ git version
> Hera:sage-dev$ g version
> git version 2.23.0
git version 2.7.4
May that be the problem, then?
In any case, git checkout -f <branchname> did work, and apparently did
no harm. So, I'm back at work...
Best regards,
Simon
E. Madison Bray
Oct 7, 2019, 9:35:37 AM10/7/19
to sage-devel
On Wed, Oct 2, 2019 at 10:09 AM Simon King <simon...@uni-jena.de> wrote:
>
> On 2019-10-02, Kwankyu Lee <ekwa...@gmail.com> wrote:
> > Hera:sage-dev$ g version
> > git version 2.23.0
>
> $ git version
> git version 2.7.4
>
> May that be the problem, then?
Probably. That is a quite old version of git (~9 years old). I agree
>
> On 2019-10-02, Kwankyu Lee <ekwa...@gmail.com> wrote:
> > Hera:sage-dev$ g version
> > git version 2.23.0
>
> $ git version
> git version 2.7.4
>
> May that be the problem, then?
with you that it's a bug but probably one that's long-since been
fixed.
The problem you described sounds like a possible symptom of a larger
bug that was fixed in v2.13:
https://github.com/git/git/blob/53f9a3e157dbbc901a02ac2c73346d375e24978c/Documentation/RelNotes/2.13.0.txt#L79
Just a guess though.
Reply all
Reply to author
Forward
0 new messages