No subject

[Jonathan Verner]

Hi,


I've been working on a toolview to stage and commit changes to git.
The motivation for this follows below. I am now in a stage where the
toolview is already useful and would be happy for some feedback. I've
created a merge request on invent.kde.org:


https://invent.kde.org/kde/kdevelop/-/merge_requests/128


(or do I need to create a review request on Phabricator?). Currently I
included the full history, so that the merge request has quite a few
commits. I am not sure if this is prefered or whether I should rewrite
the history squashing the commits to reduce this number.


What follows is


a) a motivation for the toolview and a short description of the

functionality

b) a description of the changes

c) one concrete code questions I've come across and haven't been able to

figure out on my own


Motivation

----------------


Something I've been missing from kdevelop and is the ability to
"prepare" my commits. My typical workflow is that I work on a project
and typically end up with a lot of unrelated changes. When I finish
for the day I wan't to organize the changes into commits each of which
achieves a single reasonably self contained logical change. This means
I need a way to pick an choose changes from a single file which will
go into a given commit. Git, having the concept of a staging area,
makes this possible and I currently use the excellent git cola to make
up the commit. However, an integration with kdevelop would

provide some benefits (code highlighting in the diffs, goto-source
functionality...).


The way this merge requests integrates these ideas is as follows:
there is a new toolview (currently named Git Commit) which consists of
a simple form to compose a commit message and a treeview showing

a list of project with each project showing up to four areas: staging,
worktree, conflicts, untracked. Each area lists files with changes in
the area. The user can click on a file to open a diff tab in the main
document window. In this tab he can select lines/hunks which he wants
to act on (stage the changes in the lines) to move them between the
respective areas. When

he is happy with the changes in the staging area, he can use the commit form

to prepare a message and commit the changes.


Overview of the changes in the merge request

--------------------------------------------------------------------


The changes can be split into the following:


1) I needed to do some changes in kdevplatform/vcs (mostly extending the

VcsDiff class to handle diff hunks & creating sub-diffs, but also a slight

change in VcsStatusInfo)


2) I needed some new jobs in gitplugin (reset, apply) and the ability to

get extended state for files (combining the index and worktree states)


3) I chose to integrate the toolview into the gitplugin, because I have no

experience with other systems except for subversion, which does

not have the concept of a staging area; however, if other vcs plugins

chose to implement the needed functionality (basically the ability to

stage/unstage a patch/diff file and the ability to retrieve a status),

it should be easy to make the toolview work with them too; in that

case it could be extracted into a separate plugin; The changes to

gitplugin to integrate the toolview consist of:

New files:

-- repostatusmodel.h,cpp ... implements a model (based on

projectchangesmodel) representing the staged/unstaged/untracked/

conflicting changes

-- toolview.h,cpp, simplecommitform.h,cpp ... implement the gui widgets


Changes:

-- in addition to the changes under 2) above, gitplugin.h,cpp has been

modified to create the repostatus model & toolview in the plugin

constructor


Questions

---------------


- Is there a way to get to the results of the semantic highlighting
(ideally in the form of a list of attributes for given source lines)?
I didn't find out how to copy semantic highlighting over to the diff;
right now I open the source document, create a moving range and use it
to access line attributes which I then copy over to the the diff;
however, this only gives me basic syntax highlighting (even if the
source document is already fully semantically highlighted...).


Wow, that was quite a bit of text. Anyway, I would be happy for any response.


Cheers,


Jonathan