Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

jj init --git-repo=../dir results in empty checkout #102

Closed
colemickens opened this issue Mar 2, 2022 · 2 comments
Closed

jj init --git-repo=../dir results in empty checkout #102

colemickens opened this issue Mar 2, 2022 · 2 comments

Comments

@colemickens
Copy link
Contributor

Steps to Reproduce the Problem

this would have been the build from my PR #100

cole@porty ~/jjexa -al
drwxr-xr-x - cole  2 Mar 02:11 nixpkgs


cole@porty ~/jjgit -C nixpkgs status
On branch cmpkgs
Your branch is up to date with 'origin/cmpkgs'.

nothing to commit, working tree clean


cole@porty ~/jjmkdir nixpkgs-jj


cole@porty ~/jjcd nixpkgs-jj


cole@porty ~/jj/nixpkgs-jjjj init --git-repo=../nixpkgs
Working copy now at: 4f1d5ded0540
Initialized repo in "/home/cole/jj/nixpkgs-jj/."


cole@porty ~/jj/nixpkgs-jjjj status
Parent commit: 000000000000
Working copy : 4f1d5ded0540
The working copy is clean


cole@porty ~/jj/nixpkgs-jjls -al
total 2
drwxr-xr-x 3 cole cole 3 Mar  2 02:38 .
drwxr-xr-x 4 cole cole 4 Mar  2 02:38 ..
drwxr-xr-x 4 cole cole 4 Mar  2 02:38 .jj


cole@porty ~/jj/nixpkgs-jjjj checkout 4f1d5ded0540
Already on that commit


cole@porty ~/jj/nixpkgs-jjls -al
total 2
drwxr-xr-x 3 cole cole 3 Mar  2 02:38 .
drwxr-xr-x 4 cole cole 4 Mar  2 02:38 ..
drwxr-xr-x 4 cole cole 4 Mar  2 02:38 .jj


cole@porty ~/jj/nixpkgs-jjls -al ../nixpkgs
total 97
drwxr-xr-x  9 cole cole   18 Mar  2 02:11 .
drwxr-xr-x  4 cole cole    4 Mar  2 02:38 ..
drwxr-xr-x 11 cole cole   22 Mar  2 02:11 doc
drwxr-xr-x  8 cole cole   13 Mar  2 02:29 .git
drwxr-xr-x  4 cole cole   10 Mar  2 02:11 .github
drwxr-xr-x  4 cole cole   30 Mar  2 02:11 lib
drwxr-xr-x  3 cole cole    5 Mar  2 02:11 maintainers
drwxr-xr-x  7 cole cole   13 Mar  2 02:11 nixos
# etc

Expected Behavior

To have a checkout after initing from a git repo in another directory.

Actual Behavior

I'm not sure, but I don't seem to have a checkout or an obvious way to manifest one.

Specifications

@colemickens
Copy link
Contributor Author

huh, after I did a jj checkout cmpkgs (my default nixpkgs branch name), it worked for a bit and then I had a checkout.

In retrospect, the jj log output is weird, it's really ancient commits. It seems like whatever it imported by default it picked an odd branch or commit to start from? Is there a command that shows what branch jj is on? I don't see it but I might just be missing it?

@martinvonz
Copy link
Member

martinvonz commented Mar 2, 2022

I think it doesn't check out any commit at all, so it remains checked out on the root commit (the virtual commit with hash 0000000... that's the root of all other commits).

There's a TODO about fixing this here: https://github.com/martinvonz/jj/blob/2a6ab8b6fceab91f35cae697c0c9f1f4de727594/src/commands.rs#L1733-L1734

I don't think my idea there is correct, though; we probably want to use the Git repo's HEAD commit instead. We keep track of the HEAD commit these days (pretty sure that came after that TODO), so it should be an easy fix.

martinvonz added a commit that referenced this issue Mar 29, 2022
When initializing a workspace that shares its working copy with a Git
repo (i.e. `jj init --git-repo=.`), we import refs and HEAD when
creating the `WorkspaceCommandHelper` (as we do for all commands when
the working copy is shared). That makes the explicit import we do in
`cmd_init()` unnecessary. It also makes the checkout of HEAD I added
for the fix of #102 unnecessary. More importantly, as @yuja reported
in #177, it makes the command crash (at least if the repo is small
enough that the two checkouts happen within a second). I think the
problem is that the second checkout tries to create the same commit
except that the Change ID is different (the problem is not the
predecessors as I speculated in the issue tracker). The fix is to
simply avoid doing the redundant work. We still need a proper fix for
#27 eventually.

Closes #177.
martinvonz added a commit that referenced this issue Mar 29, 2022
When initializing a workspace that shares its working copy with a Git
repo (i.e. `jj init --git-repo=.`), we import refs and HEAD when
creating the `WorkspaceCommandHelper` (as we do for all commands when
the working copy is shared). That makes the explicit import we do in
`cmd_init()` unnecessary. It also makes the checkout of HEAD I added
for the fix of #102 unnecessary. More importantly, as @yuja reported
in #177, it makes the command crash (at least if the repo is small
enough that the two checkouts happen within a second). I think the
problem is that the second checkout tries to create the same commit
except that the Change ID is different (the problem is not the
predecessors as I speculated in the issue tracker). The fix is to
simply avoid doing the redundant work. We still need a proper fix for
#27 eventually.

Closes #177.
martinvonz added a commit that referenced this issue Mar 30, 2022
When initializing a workspace that shares its working copy with a Git
repo (i.e. `jj init --git-repo=.`), we import refs and HEAD when
creating the `WorkspaceCommandHelper` (as we do for all commands when
the working copy is shared). That makes the explicit import we do in
`cmd_init()` unnecessary. It also makes the checkout of HEAD I added
for the fix of #102 unnecessary. More importantly, as @yuja reported
in #177, it makes the command crash (at least if the repo is small
enough that the two checkouts happen within a second). I think the
problem is that the second checkout tries to create the same commit
except that the Change ID is different (the problem is not the
predecessors as I speculated in the issue tracker). The fix is to
simply avoid doing the redundant work. We still need a proper fix for
#27 eventually.

Closes #177.
martinvonz added a commit that referenced this issue Mar 30, 2022
When initializing a workspace that shares its working copy with a Git
repo (i.e. `jj init --git-repo=.`), we import refs and HEAD when
creating the `WorkspaceCommandHelper` (as we do for all commands when
the working copy is shared). That makes the explicit import we do in
`cmd_init()` unnecessary. It also makes the checkout of HEAD I added
for the fix of #102 unnecessary. More importantly, as @yuja reported
in #177, it makes the command crash (at least if the repo is small
enough that the two checkouts happen within a second). I think the
problem is that the second checkout tries to create the same commit
except that the Change ID is different (the problem is not the
predecessors as I speculated in the issue tracker). The fix is to
simply avoid doing the redundant work. We still need a proper fix for
#27 eventually.

Closes #177.
martinvonz added a commit that referenced this issue Mar 30, 2022
When initializing a workspace that shares its working copy with a Git
repo (i.e. `jj init --git-repo=.`), we import refs and HEAD when
creating the `WorkspaceCommandHelper` (as we do for all commands when
the working copy is shared). That makes the explicit import we do in
`cmd_init()` unnecessary. It also makes the checkout of HEAD I added
for the fix of #102 unnecessary. More importantly, as @yuja reported
in #177, it makes the command crash (at least if the repo is small
enough that the two checkouts happen within a second). I think the
problem is that the second checkout tries to create the same commit
except that the Change ID is different (the problem is not the
predecessors as I speculated in the issue tracker). The fix is to
simply avoid doing the redundant work. We still need a proper fix for
#27 eventually.

Closes #177.
martinvonz added a commit that referenced this issue Mar 30, 2022
When initializing a workspace that shares its working copy with a Git
repo (i.e. `jj init --git-repo=.`), we import refs and HEAD when
creating the `WorkspaceCommandHelper` (as we do for all commands when
the working copy is shared). That makes the explicit import we do in
`cmd_init()` unnecessary. It also makes the checkout of HEAD I added
for the fix of #102 unnecessary. More importantly, as @yuja reported
in #177, it makes the command crash (at least if the repo is small
enough that the two checkouts happen within a second). I think the
problem is that the second checkout tries to create the same commit
except that the Change ID is different (the problem is not the
predecessors as I speculated in the issue tracker). The fix is to
simply avoid doing the redundant work. We still need a proper fix for
#27 eventually.

Closes #177.
martinvonz added a commit that referenced this issue Mar 31, 2022
When initializing a workspace that shares its working copy with a Git
repo (i.e. `jj init --git-repo=.`), we import refs and HEAD when
creating the `WorkspaceCommandHelper` (as we do for all commands when
the working copy is shared). That makes the explicit import we do in
`cmd_init()` unnecessary. It also makes the checkout of HEAD I added
for the fix of #102 unnecessary. More importantly, as @yuja reported
in #177, it makes the command crash (at least if the repo is small
enough that the two checkouts happen within a second). I think the
problem is that the second checkout tries to create the same commit
except that the Change ID is different (the problem is not the
predecessors as I speculated in the issue tracker). The fix is to
simply avoid doing the redundant work. We still need a proper fix for
#27 eventually.

Closes #177.
martinvonz added a commit that referenced this issue Mar 31, 2022
When initializing a workspace that shares its working copy with a Git
repo (i.e. `jj init --git-repo=.`), we import refs and HEAD when
creating the `WorkspaceCommandHelper` (as we do for all commands when
the working copy is shared). That makes the explicit import we do in
`cmd_init()` unnecessary. It also makes the checkout of HEAD I added
for the fix of #102 unnecessary. More importantly, as @yuja reported
in #177, it makes the command crash (at least if the repo is small
enough that the two checkouts happen within a second). I think the
problem is that the second checkout tries to create the same commit
except that the Change ID is different (the problem is not the
predecessors as I speculated in the issue tracker). The fix is to
simply avoid doing the redundant work. We still need a proper fix for
#27 eventually.

Closes #177.
martinvonz added a commit that referenced this issue Mar 31, 2022
When initializing a workspace that shares its working copy with a Git
repo (i.e. `jj init --git-repo=.`), we import refs and HEAD when
creating the `WorkspaceCommandHelper` (as we do for all commands when
the working copy is shared). That makes the explicit import we do in
`cmd_init()` unnecessary. It also makes the checkout of HEAD I added
for the fix of #102 unnecessary. More importantly, as @yuja reported
in #177, it makes the command crash (at least if the repo is small
enough that the two checkouts happen within a second). I think the
problem is that the second checkout tries to create the same commit
except that the Change ID is different (the problem is not the
predecessors as I speculated in the issue tracker). The fix is to
simply avoid doing the redundant work. We still need a proper fix for
#27 eventually.

Closes #177.
martinvonz added a commit that referenced this issue Mar 31, 2022
When initializing a workspace that shares its working copy with a Git
repo (i.e. `jj init --git-repo=.`), we import refs and HEAD when
creating the `WorkspaceCommandHelper` (as we do for all commands when
the working copy is shared). That makes the explicit import we do in
`cmd_init()` unnecessary. It also makes the checkout of HEAD I added
for the fix of #102 unnecessary. More importantly, as @yuja reported
in #177, it makes the command crash (at least if the repo is small
enough that the two checkouts happen within a second). I think the
problem is that the second checkout tries to create the same commit
except that the Change ID is different (the problem is not the
predecessors as I speculated in the issue tracker). The fix is to
simply avoid doing the redundant work. We still need a proper fix for
#27 eventually.

Closes #177.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants