Feature: Resolve rebase conflicts

[Murmele]

• [x] Unittests
• [x] All TODOs removed
• [x] ~~Toolbar buttons for aborting and continuing the rebase~~ Moved next to the commit button
• [ ] Merge conflicts and mergetool are enabled!

[Murmele]

@exactly-one-kas I implemented it rawly now. What do you think about the toolbuttons or do you see a better location?

[exactly-one-kas]

I think that aborting and continuing rebases should be handled like merges; otherwise the merge operations would also habe to be placed on the toolbar for consistency

[Murmele]

I think that aborting and continuing rebases should be handled like merges; otherwise the merge operations would also habe to be placed on the toolbar for consistency

The second image is good. But maybe we can then also move the merge out. I think it is quite hidden. I did not know ^^

[Murmele]

I moved the rebase buttons. I added also the merge abort button there or should I let it in the menubar only, or should I delete it from the menubar then?

[Murmele]

@exactly-one-kas do you understand why the unittest fails with that exact repository? For some reason I have a nullptr exception

[exactly-one-kas]

Does the unit test only fail with that exact repository? Considering the stack strace it seems to me that it should fail with any repository.

I'd guess that this happens because the unit tests are run with an offscreen / dummy QT backend that doesn't create actual windows and therefore has no window handles.

Try the following:

• Rename w_handler to w_handle
• Use int size = kSize * (w_handle ? w_handle->devicePixelRation() : 1);

[exactly-one-kas]

I moved the rebase buttons. I added also the merge abort button there or should I let it in the menubar only, or should I delete it from the menubar then?

I'd say that all buttons regarding rebasing and merging should be with the commit button (after all, the "commit merge" button is the merge button), so that new users have an easier time finding these options. Personally, I think that this location is the more logical one than the toolbar or menu bar

However, "abort merge" and "abort rebase" should also be present in the "branch" menu as that's where users currently expect them to be. We should keep them there for a while and phase them out for v2 / the next major redesign

[Murmele]

Yes exactly it fails only with this repository, If I replace the zip filename by another in that location it runs through.

[Murmele]

I moved the rebase buttons. I added also the merge abort button there or should I let it in the menubar only, or should I delete it from the menubar then?

I'd say that all buttons regarding rebasing and merging should be with the commit button (after all, the "commit merge" button is the merge button), so that new users have an easier time finding these options. Personally, I think that this location is the more logical one than the toolbar or menu bar

However, "abort merge" and "abort rebase" should also be present in the "branch" menu as that's where users currently expect them to be. We should keep them there for a while and phase them out for v2 / the next major redesign

Good idea, I will mark it so we don't forgett to remove it at some point

[Murmele]

This is how the stacktraces look like. During load the setDiff is called 6 times.

What I have seen is that for rebaseConflicts Repository, the number of commits is not zero as for the other

In 13_singleHunkNoStaged, a dirty working directory is present, inrebaseConflicts it is not. So maybe my INIT_REPO() macro is wrong

happens during the Test::refresh call

fixed in b4828839a880ae74d57b61e5254323a940006603

[Murmele]

@exactly-one-kas

Currently if we are executing a git command like "git checkout ..." Gittyup does not react on it, because the index is not changed and therefore Gittyup does not get any notification. (With GitExtension it is the same) The question is shall we implement something like that or just ignoring it? So the user has to manually refresh.

The indexer application is running in it's own process and watches the changes of the index, but not if only the branch changes.

[exactly-one-kas]

Currently if we are executing a git command like "git checkout ..." Gittyup does not react on it, because the index is not changed and therefore Gittyup does not get any notification. (With GitExtension it is the same) The question is shall we implement something like that or just ignoring it? So the user has to manually refresh.

The indexer application is running in it's own process and watches the changes of the index, but not if only the branch changes.

Watching .git/HEAD would be an option

The indexer only needs to do its thing whenever the index changes or a new commit has been created or fetched, switching branches doesn't matter there

[Murmele]

Watching .git/HEAD would be an option

hmm yes. So we need another application always looking there. I think this goes beyond this scope.

[exactly-one-kas]

hmm yes. So we need another application always looking there. I think this goes beyond this scope.

Why would this need to be in another application? Change detection happens in the same process from another thread (see src/watcher/RepositoryWatcher.cpp)

[Murmele]

hmm yes. So we need another application always looking there. I think this goes beyond this scope.

Why would this need to be in another application? Change detection happens in the same process from another thread (see src/watcher/RepositoryWatcher.cpp)

You are right sorry. This will work so we will react on .git/HEAD changes and then we are doing a refresh? Would you like to implement ^^ I am completely full next weeks. Maybe I can go on a little bit with the libgit2 update ....

[Murmele]

@exactly-one-kas can we merge this? I think implementing watching .git/HEAD can be done separately because it affects all commands executed in command line not only rebase

[exactly-one-kas]

Yep, works for me