Skip to content

Git commit plugin

Jonathan Verner requested to merge verner/kdevelop:git-commit-plugin into master

This merge request implements a toolview which helps in preparing useful, selfcontained commits. It allows picking and choosing which changes to stage and then, when they are ready, to commit them to the repo. The merge requests has the full history so it 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 motivation for the toolview and a short description of the functionality
  • a description of the changes
  • 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, commitStaged) and the ability to get extended state for files (combining the index and worktree state --- the ExtendedState enum)

  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...).
Edited by Ben Cooksley

Merge request reports