| Interactive rebase a dead end? [message #755342] |
Tue, 08 November 2011 08:29  |
 Stephan Herrmann
Messages: 1853
Registered: July 2009 |
Senior Member |
|
|
OK, git is great for merging so I tried:
- create two local branches B1 and B2 from master using independent patches
- try to rebase B2 on B1
- as there were conflicts I told the merge tool to start with its defaults
- manually edited all conflicts
- commit the result making sure all changed files are selected in the commit dialog.
Afterwards, I found that all conflicts were still marked as conflicts and NOT committed. At the command line I saved "git diff" to a file which indeed contains all my manual changes. Good. But now EGit seems to be in a state where moving is not possible in any direction.
- "Mark as merged" is disabled in all context menus
- None of my local branches is marked as checked out
- I tried overwriting the conflicting files and re-apply the saved patch
- In the help I saw a comment that I would need add the edited files to the git index (WHY? those are not new files???)
After all this I'm currently in a state, where apply patch silently dies:
no complaint, no error logged, but no effect in the workspace.
This seems to be a very dead end. Interactive rebase seems to put the system
into a bogus state, with no obvious way out.
BTW, in retrospect I see one git related error in the logs:
org.eclipse.core.commands.NotEnabledException: Trying to execute the disabled command org.eclipse.egit.ui.team.Commit
Not sure at what point this happened, the error wasn't shown in the UI.
Apart from that the logs only contain "normal" things like NPEs in org.eclipse.compare.internal.merge.DocumentMerger.doDiff and org.eclipse.jdt.internal.ui.text.JavaReconciler.uninstall probably caused by undead compare editors (none were open at that point).
To add insult to injury: at this point the attempt to check out ANY branch gives: Repository state: Rebase interactive.
This repo is not usable from EGit unless I find a way out of this state. EGit doesn't seem to give me a clue.
Has any one seen s.t. like this? Is anybody using rebase with interactive merging? Any steps that I should (not) have done??
best,
Stephan
|
|
|
|
|
|
|
| Re: Interactive rebase a dead end? [message #755483 is a reply to message #755459] |
Tue, 08 November 2011 16:04  |
Stephan Herrmann
Messages: 1853
Registered: July 2009 |
Senior Member |
|
|
Hi Matthias,
thanks for your reply.
Matthias Sohn wrote on Tue, 08 November 2011 16:16In Git land you mark conflicts as resolved using the "add" command hence you should do the same in EGit.
Perhaps one way of communicating this would be to hook into the commit command: if files cannot be committed due to conflicts a dialog could say: "nothing to commit, but n conflicting files are awaiting to be re-added to the index" or s.t. like that.
As an SVN user I would have expected the "Mark as merged" command to do this task. It seems git doesn't actually have a "mark as merged" command? I saw this option in the menu and at the time when I was in dire needed of it it was disabled. This contributed to my panic. Why is that menu action called "Mark as merged"?
Quote:
When you are done with resolving all conflicts and "add"ing them to mark them as resolved you should run "Rebase > Continue" from the repositories view's context menu or from the team menu. This is described in the user guide [1].
I saw it after my posts. Perhaps just some more emphasis and/or a more prominent location for this information would help.
Quote:
Also the merge tool gives a hint at the bottom how to proceed. I agree that we could improve on guiding the user in a better way. Proposals and patches are welcome 
Right now I can only say I looked at the "Merge Tool" (which to me looked like a normal compare editor with no additional functionality, is that the Merge Tool?) searching for ways out and didn't see any hint. Why not add some buttons for resume/skip/abort to the button bar of that tool?
(FWIW: I selected "Use the workspace version ...").
I think conflict resolution requires special guidance because it puts the workspace into a strictly sequential workflow, that almost calls for a modal wizard. The "Next" button should be the most visible of all GUI elements. Currently it is hidden in a sub-menu that normally isn't even there. What about a conflict resolution perspective? This perspective could bring its own toolbar with resume/skip/abort buttons.
I understand that by strictly following the user guide I could have avoided my confusion, but I'm reporting this just as it occurred to me, because I'd love to have a UI that can be used without a user guide
BTW: the p2-ui people at some point defined different personae for capturing different usability requirements. E.g., my user profile regarding EGit would say s.t. like: "knows all about version control in general and is confident that he has groked the main concepts of git. At this point he doesn't want to spend time 'learning git' but needs to just use git during daily work. Expects the tool to give hints when he gets off road".
best,
Stephan
|
|
|
|
Powered by
FUDForum. Page generated in 0.03506 seconds
] 
Search
Help
Register
Login
Home
