Bugzilla – Full Text Bug Listing
| Summary: | double commands showing on repository page | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Susan McCourt <susan> | ||||
| Component: | Git | Assignee: | Malgorzata Janczarska <malgorzata.tomczyk> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | malgorzata.tomczyk, Szymon.Brandys | ||||
| Version: | 0.5 | Flags: | susan:
review+
|
||||
| Target Milestone: | 1.0 RC2 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows 7 | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
I noticed several live "fetching branches" operations in the popup today before seeing the double buttons. I think you can reproduce by simply invoking "pull" twice, the second time while the commits/branches sections are still repopulating. Not only duplicate commands where shown in the repositories page, also contents of Working Directory, Commits, Branches and Tags could appear duplicated. This commit fixes the problem while displaying: https://orion.eclipse.org/git/reviewRequest.html#ssh://git.eclipse.org/gitroot/orion/org.eclipse.orion.client.git_32ca01109e251068938eb80c1096c8d1478b95bf I have to say, it was a lot harder to make the problem happen during testing than when I opened the bug. I used to get this all the time, and I had to try a lot harder to make it happen. That said, I couldn't get it to happen with the fix. I was seeing some other differences in the self hosted workspace (error markers on some tags) but I verified that these were appearing self hosted even without the commit. I decided it must be client/server mismatch or else some other bug in HEAD. I was able to verify that the fix didn't introduce these problems, and I never got the double commands. All that said, I pushed the fix. There was one <div> tag that still had a </list> tag, and I pushed that in a separate commit. I got to wondering what these <list> tags were for and opened bug 391708 for that. (In reply to comment #3) > All that said, I pushed the fix. > There was one <div> tag that still had a </list> tag, and I pushed that in a > separate commit. I don't see it in master and I really want it to get into todays build, so I corrected this "</list>" problem and pushed it to master. (In reply to comment #4) > (In reply to comment #3) > > All that said, I pushed the fix. > > There was one <div> tag that still had a </list> tag, and I pushed that in a > > separate commit. > > I don't see it in master and I really want it to get into todays build, so I > corrected this "</list>" problem and pushed it to master. thanks for spotting this, Gosia! Something must have failed on the push. Now when I open this commit, the commit page has a TypeError and git status is showing this change as outgoing. I'll see if I can reproduce. |
Created attachment 221163 [details] screenshot I'm finding it pretty common in my workflows to end up with "double git commands" in the branches list on git pages. I'm pretty sure the problem is that whatever operation is populating the branches list is not cancelled if the page hash changes. So a common scenario might be: - open a repo page - the sections start populating, branches always seems to be quite slow, at least for my clone - at some point pick a link to another repo page. (for example, choose "See Full Status" from a repo page, or pick the repo link in the breadcrumb from the status page) - now you are on a "new page" - you end up with double commands for branches A "band-aid" solution would be to empty the section heading whenever rerendering section commands, but I think the real issue is that the "fetch branches operation" should either be cancelled on transition, or else see if you are already fetching the branches and if so, reuse the operation (that would be quite nice for saving time!)