Bugzilla – Full Text Bug Listing
| Summary: | removing done commits from synchronized view | ||
|---|---|---|---|
| Product: | [Technology] EGit | Reporter: | dark_knight <dschramm> |
| Component: | UI | Assignee: | Project Inbox <egit.ui-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | minor | ||
| Priority: | P3 | CC: | b.muskalla, dariusz.luksza, dschramm, eclipse, ilya.ivanov, matthias.sohn, remy.suen, sam.davis, stefan.hansel |
| Version: | 0.12 | ||
| Target Milestone: | 2.0-M2 | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
|
Description
dark_knight
As I wrote on the forum (http://www.eclipse.org/forums/index.php/m/672359/), EGit because of this bug right now is a bit unintuitive compared to known processes from CVS and Mercurial. Personally I very often use the Synchronize view to commit changes (my own QA) and it's very annoying, that commited files are not removed so that I can concentrate on the uncomitted ones. *** Bug 324255 has been marked as a duplicate of this bug. *** I've pushed fix for this issue: http://egit.eclipse.org/r/#change,3559 merged as 0d431cd13fd8699cae5ace94be148a960d0f98af this bug should be re-opened for indigo SR2. after commit, the file stays in the synchronize view (it disappeared in SR1). however the ">" mark to show it needs to be committed does disappear. *** Bug 357175 has been marked as a duplicate of this bug. *** additionally, the "diff" that's shown in the compare editor is against the initial version, so if subsequent changes are made, and the compare editor is re-opened, the already committed changes are shown. it seems the "baseline" commit used by the synchronize view (i.e. HEAD) is not being updated after a commit. i.e. the baseline commit is not tracking HEAD properly. Sounds like this should be reopened... this leaves egit in indigo sr2 in a horribly unusable state FWIW. how can anybody use synchronize view since updating? does everyone out there use some snapshot that I'm missing? Or they haven't updated ? Or maybe no one uses synchronize view. I cannot reproduce this bug in current nightly build. David, could you test this and verify does this doesn't appear any more ? I updated to today's daily, 2.0.0.2012040307. It still happens to me. I change a file in java perspective, right click on the project, select Team->Synchronize Workspace. The sync. view shows the modified file with a ">". Right click the file, select commit, enter a message commit. The ">" disappears next to the file, but the file is still shown and the project now shows an "up" arrow with a 1, indicating we have 1 commit to push to upstream. In my opinion the file should not be shown at all. Switch back to java view and edit the file again, team->synchronize workspace. Now double click the file, it will show the changes from the 1st commit and 2nd commit together in the compare editor, which is completely bogus. Now click push. No change. (It's not updating the local tracking branch - this can be confirmed with command line git). Now click "pull", and finally all is as it should be. FYI, I'm using git repository ".git" in project root directory, cloned by command line, then attached via Team->Share. Overall, it seems that the HEAD commit which is the baseline for the synchronize view is stuck at the point when the view opened, instead of moving forward commit by commit. OK, think that I understood you point, an this is an intended behaviour rather then a bug ;) Unfortunately workspace model isn't perfect for synchronize purposes in DVCS, the 'Git Commits' model is more suitable for handling such tasks. Workspace model will present you *all* incoming and outgoing changes squashed together (by outgoing I understand outgoing commits and not committed changes). You will not see incoming or outgoing commits, only changes that they made to working copy. Some time ago we decided on this approach to eliminate possibility that people forgot to push theirs changes to upstream. I understood that this can be confusing, but this is how things works; of course we can change this is you have strong enough arguments or better idea ;) Maybe in some cases 'Synchronize Workspace' action should be called 'Synchronize with Upstream' or 'Synchronize with Origin'. I would also recommend using 'Git Commits' model. Ok. there are a few points here. It seems it has to be a bug that I need to push AND pull. If I've pushed the change, I shouldn't need to immediately pull it back in order to get the UI to update. Command line push doesn't behave that way. I'll look at figuring out what you mean by "git commits" and get back on the other point. Ok. "Git commits" is also broken. If I go in with a modified file, it shows up under "working tree", and if I commit the file it stays there, and doesn't get "moved" to a commit entry for that commit. The view is simply not updating to the new state of the repository. If I go back to java perpective and redo team-sync it shows the new commit, and not under "<working tree>" Furthermore, if I go back to java and undo the change and save the file the sync. view shows "no changes" when in fact the file is changed and needs to be committed, again, the baseline for comparison is not being updated when I commit or push. And this behaviour is different from the CVS sync. view behaviour and different from SR1 behavior. Maybe you can explain the workflow you've engineered the tool for? Most users don't push every commit immediately at all. In my company a developer may make dozens of changes before pushing a buildable codebase, and to pollute the sync view with every change ever made but not pushed is IMHO broken. It becomes impossible to view the most recent changes made to a file, because double clicking the file shows all the changes "squashed" into one as you put it. (In reply to comment #13) > It seems it has to be a bug that I need to push AND pull. If I've pushed the > change, I shouldn't need to immediately pull it back in order to get the UI to > update. Command line push doesn't behave that way. This can be related to bug 317411. (In reply to comment #14) > If I go in with a modified file, it shows up under "working tree", and if I > commit the file it stays there, and doesn't get "moved" to a commit entry for > that commit. The view is simply not updating to the new state of the > repository. I'll investigate it tomorrow and hopefully will come with fix for this soon > Maybe you can explain the workflow you've engineered the tool for? My idea of workflow was: * make changes in workspace * use sync view git commits to compare workspace version with index * move changes to index/commit directly * continue working/commit version from index * (after commit new commit node should appear in sync view) * squash local commits into one if it is needed * push to remote repository currently we don't support "squash commit" operation and it seams that new commit doesn't appear in sync view (as you mentioned above). Also I've just realized that when you have some outgoing commits there is no possibility to compare local changes against repository version (you can compare local changes against index version, version in index against repository or local (with changes from other commits) against version from (let say) origin). Ok. I like your workflow with these two comments: 1. Obviously when a new "commit" is done it needs to appear in "git commits" view. 2. It is absolutely necessary to be able to compare a modified file to index version. Where #2 is broken seems to be that it always compares the file to the remote-HEAD version instead of the index version. In other words, when I double click a file I would want to see the same as what the command line "git diff <file>" would show. (In reply to comment #16) > 2. It is absolutely necessary to be able to compare a modified file to index > version. Currently it is possible to compare: * modified file to index * version in index to version to repository but, you cannot compare directly modified file to version in repository, when you have one or more local commits (it is possible through team > compre with -> version from HEAD, but not from sync. view) > In other words, when I double click a file I would want to see the same as what > the command line "git diff <file>" would show. You'll get such results when you double click on file in <working tree> node inside sync. view. If you would double click on <staged changes> node you will see same as in "git diff --cached <file>" fyi: switching the mode from "git commits" to "workspace" and back to "git commits" causes any just-made commits to now show up. This is a regression introduced by f52917721af7c7dfce44cc655fb3586a811793fb commit. I've already proposed fix for this[1]. There is also one hidden assumption for showing new commits in Git Commits model. "Always launch fetch before synchronization" option in Team > Git > Synchronize should be checked to show outgoing commits. If it is unchecked then Git Commits model after committing changes will show "no new changes". If this is counter-intuitive we can discuss that in separate issue. [1] https://git.eclipse.org/r/#/c/5548 is there any build i can test the proposed fix with? looks like it's still pending bureaucratic red tape. (In reply to comment #20) > is there any build i can test the proposed fix with? looks like it's still > pending bureaucratic red tape. unfortunately our CI instance doesn't expose compiled artefacts. you could try fetch this change on your own and try to compile it. same as other changes in egit project it is waiting for a review from other committers/contributors. merged as 30b41a08b20a144c2300c3785928ba87ff2eace1 |