Community
Participate
Working Groups
1- open any review 2- checkout the code of a particular patchset and keep the default name ending 3- modify the code and make a new commit 4- try to checkout the code again => nothing happens but I am not pointing to the commit of the review Note that I do have the correct commit in my git repo but it does not become checked-out. Personally, I think that using branch names for checkout intelligence is fragile. Can't we use sha1s?
Did you refresh the content of the editor after doing the commit? I have not tried but I think that the problem comes from the fact that even though you pushed something new to the server, the in-memory copy of the review we have is not updated (e.g. does not know about the new revision) and as such when you do a checkout there is nothing to do since you are from the point of the view of the editor on the most up-to-date revision.
(In reply to Pascal Rapicault from comment #1) > Did you refresh the content of the editor after doing the commit? > > I have not tried but I think that the problem comes from the fact that even > though you pushed something new to the server, the in-memory copy of the > review we have is not updated (e.g. does not know about the new revision) > and as such when you do a checkout there is nothing to do since you are from > the point of the view of the editor on the most up-to-date revision. It's simpler than that. I didn't push anything new to the server. The problem is that I kept using the branch name for my own changes, but then, when I want to checkout the original code, it finds the modified branch with the same branch name. I believe the same issue will happen if I append a review commit and then want to checkout the original code.
So far we have been using the branch name as a "hint"/"trick" to know if we were on the right branch. We are now seeing the limit of this approach and it can get confusing to the user. Ideally we should be dealing with the commit id directly instead of playing this trick with branches. However I'm not sure how much work is involved in switching to this approach. In the interim, there are a couple things we could do: - If we are already on the right branch or when we switch to an existing branch, we should check that the last commit on the branch is the expected commit id (we get the commit id from the revision info iirc). - If we are not on the right branch we could inform the user
New Gerrit change created: https://git.eclipse.org/r/74802
How to test the solution: 1- Check out a review -> this create a new branch: ORIGINAL 2- Create a new branch from that branch (Git view -> Branches-> local -> switch to new branch (BRANCH 2) 3- checkout the ORIGINAL branch for this review (From Git repository) 4- Do a modification and a commit (You will not push that commit to Gerrit) 5- Verification: Open the GIT repository the current review branch (ORIGINAL) has a different commit Id display beside the branch name than the other branch (BRANCH 2) you created earlier. The other branch (BRANCH 2) has the same commit Id than the commit Id of the review 6-From the ChangeDetailEditor view, try to check-out again the same patchset from the same review again. --> It will says that there is a branch with the same name which is different, but it is also proposing the other branch (BRANCH 2)you created from the original branch before the modification
Gerrit change https://git.eclipse.org/r/74802 was merged to [master]. Commit: http://git.eclipse.org/c/egerrit/org.eclipse.egerrit.git/commit/?id=81e3bba04410150b619d407980ce133cf957b3ea
Available in EGerrit build >=565 Review: https://git.eclipse.org/r/#/c/74802/ Display potential branches matching the same commit id, same default branch name and branch having the same change Id Allow double-clicking on a branch to switch to it
