Questions developing VCS plugin

Frank Fischer frank-fischer at
Fri May 19 19:46:23 UTC 2017

Am 18.05.2017 um 02:18 schrieb Aleix Pol:
> On Mon, May 15, 2017 at 9:23 PM, Frank Fischer
> <frank-fischer-vZE0Uux9YSu64FcheEUf7Q at> wrote:
>> 1. pull: should this method just pull changesets from remote or should
>> it also update the working directory? The git plugin seems to call "git
>> pull", so fetching the changesets and updating the working directory
>> (unless there are some conflicts). The mercurial plugin calls "hg pull",
>> which does not update the working directory. What is the desired
>> behaviour? What should happen if there is a conflict? Should the changes
>> be merged? How?
> It's not set in stone. What do you think that would be best for your users?
> Personally I'd say it's worth having the changes integrated but tools vary.

I would also prefer to have the changes integrated, but the mercurial
plugin seems to behave differently. That's why I asked. I'm just
wondering whether there should be a well-defined behaviour that each vcs
plugin should follow. Or should "pull" just do "what the typical user of
that vcs expects" (so it is okay that different vcs behave differently)?
Usually I prefer a fixed, reliable, consistent behaviour independent
from the underlying vcs.

But nn principle I can live with both options. (Have pull only "pull"
changes without integrating would be okay, too, as KDevelop could just
automatically call "update" afterwards.) I just wanted to know if there
is something like "the" correct way ;)

>> 2. mergeBranch: how to deal with conflicts? Is there some way to
>> initiate a graphical merge (in kdevelop)? The git plugin just seems to
>> call "git merge", but what happens in the case of a conflict?
> Exactly the same case as pull.
> In git what happens is that you get the conflicted files you have to
> resolve an commit. Much like would happen on the console...

Okay, but should the method somehow display the result to the user, e.g.
in some kind of dialog together with possible subsequent actions (cancel
the merge, start some merge tool (maybe something integrated in
KDevelop?), leave conflict markers, ...)? Currently the only information
a user could get seems to be the console output ...


More information about the KDevelop-devel mailing list