-
Notifications
You must be signed in to change notification settings - Fork 403
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
Unexpected rebase after jj git fetch
when git.subprocess=true
#5700
Comments
git.subprocess=true
jj git fetch
when git.subprocess=true
Just to clarify, does that mean |
I might find the rootcause: As this is just one of repositories managed by repo. So the |
I don't quite understand how this would be the issue. |
@tw4452852 I implemented the test, you can see it in https://github.com/bsdinis/jj/blob/a835fcee21f8753fcb9fb27a66cb56266e4a4b91/cli/tests/test_git_fetch.rs#L1935 I couldn't find this behaviour. Question though: do you know if We've already had to disable it for |
cc @bnjmnt4n as he is the git expert. fwiw, it might be good to set |
@bsdinis
Seems |
@bsdinis I think so. |
Weird! Doesn't seem to reproduce for me, though. |
Oh, but does that experiment work only on that particular repo for you? Are you able to reproduce it on a new repo? |
@martinvonz |
We have some other git experts from Google who might know that's going on, especially since repo is a Google tool. @nasamuffin, @jonathantanmy, @steadmon. |
@yuja @martinvonz @bsdinis Especially for a bare repo: https://github.com/git/git/blob/e2067b49ecaef9b7f51a17ce251f9207f72ef52d/builtin/fetch.c#L1660-L1662 This explains why Here's stacktrace when updating happens:
|
That whole function was introduced in Git v2.48, which is relatively new and might be why others are not able to reproduce. I'll see if I can download and test this out later. (I also thought the new behavior was to update |
Oh, so it's the feature introduced recently? One weird thing the |
@bnjmnt4n For the non-bare repo this is the case, but not for bare repo though, at least from the implementation (https://github.com/git/git/blob/e2067b49ecaef9b7f51a17ce251f9207f72ef52d/builtin/fetch.c#L1660-L1666):
|
It seems like this might be an implementation bug given the commit description in git/git@b1b713f, which seems to say that this should only happen for mirrored bare repositories. |
My thoughts about this:
|
Maybe another option is adding |
fwiw, all tests passed without Maybe we can also disable |
@tw4452852 could you test out https://github.com/jj-vcs/jj/tree/bsdinis/rtyusmopotyw? |
I'm afraid it doesn't fix this problem, here's log:
IIRC, |
I also did some spelunkings to find out why this issue can't be reproduced on standalone git repo. The reason is that git will treat these repos as non-bare, even when we specify
While this is not the case for the repos managed by repo where |
This causes some issues (e.g., #5700) and is not actively needed.
@tw4452852 yeah, removing |
@bsdinis
|
I don't see a bug report for Git. I suspect no one has reported it there. Let's see what the Git experts in this thread say. Maybe they can confirm that we've understood correctly what bare repos are (in which case it does seem like a bug), or maybe bare repos is a more complicated concept than we think and the new behavior is actually expected. |
@bnjmnt4n did you manage to figure out if this is a bug in |
Yes, it appears that this was a bug in Git. The following patch was published: https://lore.kernel.org/git/[email protected]/, which looks to have been accepted in https://lore.kernel.org/git/[email protected]/. |
So is it ok to close this issue and the corresponding PR? Given that if |
I haven't thought about it in detail, but would it make sense to merge it until people move off buggy Git versions? Or make it conditional on the installed Git version? Update: This was a very naive question. I think it was correctly received as such, but I am adding this edit to make sure. I didn't realize it was a single buggy git version, for example. |
I think the original patch can actually be split. The first commit I think solves your problem (updating the fetch head). The second one is the one that tries to solve this I don't think it's good policy to be merging patches intended for a single buggy git version. |
I think it's also good to merge the fix at our side, given |
One way I was thinking |
This causes some issues (e.g., #5700) and is not actively needed.
Yes. OTOH, it could trigger edge case bug like this, so I'm not sure if which is better overall. |
I think that's fair. The other PR is still ready, can be merged whenever |
I think it's unfortunate that we can't pass the |
I think the hassle of creating and removing temp dirs is probably not worth it. Again, |
Description
Steps to Reproduce the Problem
jj git fetch
git_head()
.Expected Behavior
No rebase happens after
jj git fetch
Actual Behavior
Working-copy is rebased on the latest
git_head()
.Specifications
Reproduce steps on my local environment:
linux
jj 0.26.0-37992412b64f828d078789b2db84d1d291412ab0
The text was updated successfully, but these errors were encountered: