qcommit: Add ui to select code to commit at the hunk level

[Russ Brown]

This kinda follows on from bug #306690.

Allow parts of each modified file to be included or excluded from the commit. Similar to how git gui does it, this would be a great time saver in many cases (removing many steps from one of the shelf's use cases).

With this in place, qcommit becomes a comprehensive "commit constructor", allowing the user to specify exactly what to commit all in one window, and would elevate qbzr to total Rock Star status. :)

[Mark Hammond (mhammond)]

This is a big ask of 'qcommit' when bzr's commit machinery doesn't support it. It may also create new usability issues if we try and change the "mental model" of bzr into something else.

Maybe we just need a 'qshelve' implementation?

[Lukáš Lalinský (luks)]

I don't mind breaking the "bzr mental model" at all. QBzr has never intended to follow it, it was just the easy way to start. Integrated hunk selector seems much better to me than a separate tool. Having the separate tool would be nice, but I'd use it as part of qcommit way more ofren.

[Russ Brown (pickscrape)]

For me it just fits the workflow better. Doing it via shelve means I first have to shelve what I *don't* want to commit, then commit what I do want to commit, and then unshelve. Allowing hunks to be selected in qcommit would allow me to just select the things I *do * want to commit, and commit them in one logical step.

[Mark Hammond (mhammond)]

Fair enough: but for me personally, I prefer a workflow where I checkin exactly what I just tested - and that means I *must* remove anything I don't want to checkin before testing. However, its clear that your mileage varies; I certainly will not object!

[Russ Brown (pickscrape)]

I see your point, and I actually often do it like that myself.

In this use case I basically complete my work and then perform a 'commit flurry' (usually at most two or three of them) where the last commit results in my working copy being completely committed. The rationale is that the each individual commit represents one logical change, which in turn should make it easier for the reader to follow than dealing with one large patch.

For example:

 * commit 1 (add new framework feature)
 * commit 2 (change existing code to use the new framework feature)
 * commit 3 (add completely new code also using the new framework feature).

In such circumstances the new framework feature is often easier to write if you are actually using it (assuming the absence of a test suite, and even then an actual use-case is often still useful). So you either do the three commits as above, or you just dump one big commit containing all of those three things. That makes it harder to point someone at the change that introduced the framework feature, since it is intermingled with the code making use of it, while the other two commits are also useful for pointing at as standalone examples of how to use the new framework feature.

Or maybe my brain just works in a weird way. :)

[Alexander Belchenko (bialix)]

Although I think qshelve will be much better, especially if user can run it directly from qcommit dialog.
See https://bugs.launchpad.net/qbzr/+bug/326268