Bugzilla – Full Text Bug Listing
| Summary: | Synchronize View: Incoming, Outgoing Mode etc. have no effect | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Technology] EGit | Reporter: | Stefan Lay <stefan.lay> | ||||
| Component: | UI | Assignee: | Project Inbox <egit.ui-inbox> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | dariusz.luksza, eclipse.org, remy.suen, robin | ||||
| Version: | unspecified | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Stefan Lay
This seems to be working properly for me. This works now. Created attachment 179201 [details]
Screenshot: incoming mode showing outgoing+incoming and duplicates
About the previous attached screenshot: You can see the button for incoming changes selected, however you still see outgoing changesets. Additionally many changesets appear twice as outgoing and incoming, with different sha1... Are we sure this bug is fixed? I'm new to git and egit, so I may not understand the whole git process yet, but this sure looks weird. Using egit/jgit 0.9.3 on arch linux 64 bits Well I can explain the presence of duplicate incoming and outgoing: I basically did not synchronize with the proper origin branch, hence the different sha1. As I said, still learning git/egit... Still, the presence of both outgoing and incoming while in incoming mode is weird. It did however point me towards my own mistake. (In reply to comment #4) > About the previous attached screenshot: > You can see the button for incoming changes selected, however you still see > outgoing changesets. Additionally many changesets appear twice as outgoing and > incoming, with different sha1... This is quite possible consider this scenario: - you fetch a commit from yours team member for review and starts reviewing it - in mean time some one else from team has finish reviewing same commit, send his feedback to the author, author has done some improvements and amend this commit. Finally he push it to origin repo - for some reasons you want to compare commit hat you are reviewing with origin so you are fetching current state from origin and now you have two commits that has same message but different SHA-1 It would be perfect if you could describe yours scenario so that we could reproduce it. > Are we sure this bug is fixed? It seams that this isn't fixed. I've use above scenario to reproduce this and it reproduces always. Well my scenario is simple: I cloned mantisbt repository from git://mantisbt.org/mantisbt.git I checked out branch master-1.2.x and created a new branch from it. Made some changes and committed them to my new branch. Then I wanted to synchronize with the origin, except that instead of comparing to origin/master-1.2.x I compared to origin/master. I suppose mantisbt has a workflow of applying changes from the master branch into the master-1.2.x branch, so my screenshot was showing both changesets. It seams that we hit another limitation of Team Framework here. As before it is all because the three way compare relays on local version of file. Team Framework uses instances of IDiff interface to cache change deltas and base on those deltas it sorts changes on incoming and outgoing. When synchronization occurs the Subscriber.getDiff(IResource) and returns instance of IDiff. This method uses standard SyncInfo to IDiff converter (SyncInfoToDiffConverter.getDefault().getDeltaFor(SyncInfo)) with internally uses local file version to determinate change direction. If we want to have proper distinction of incoming and outgoing changes in Git Change Set model we should provide proper implementation of Subscriber.getDiff(IResource) method that would be aware of given source commit that we would like to load data from. The plugin for mercurial does provide a nice synchronize view which could provide some inspiration. However if I remember correctly mercurial stores diff, so that may be why it's easier for them to use the team framework. I couldn't reproduce the problem with the newest version of EGit -> resolving. |