Changes to our Git infrastructure

[Milian Wolff]

On Wednesday 24 December 2014 00:20:18 Ben Cooksley wrote:
> Hi all,
> 
> As has been made evident in the prior thread there are quite a few
> interesting ideas floating around about what our Git infrastructure
> should be capable of.
> 
> Our current one was constructed when KDE first seriously migrated to
> Git following the Gitorious experiments, and it shows. (As a sysadmin
> I can attest that parts of it are held together by digital glue and
> tape).
> 
> Before we go ahead and jump to a new platform though - we need to know
> what we want.
> Can everyone please suggest what they think are the things they'd like
> to see feature wise?
> 
> In doing so, please refrain from mentioning any existing solutions -
> all we want to do at this point is construct a wishlist of what people
> would like to see the system be capable of.
> 
> Items that we (sysadmin) would like to see community comment on
> include the code review system, clone and scratch repositories and how
> they function, and whether people would be bothered by repository
> locations changing as they move around. Also useful would be comment
> on how anongit and other systems that rely on the Git infastructure
> work.

Here's a list of things that I'd like to have for my workflow, which is 
basically two folded: On one hand, I actively develop new software and new 
features. On the other hand, I spent a considerable amount of KDE time 
reviewing other peoples work.

## The Developer

For productivity, I'd love to have the ability to push changes directly from 
the command line to somewhere others can then review the code. This should 
support both, individual commits as well as feature branches. I.e. when 
pushing a merge request for review, I still want others to see individual 
commits. Updating such reviews should be trivial and keeps the review history 
intact. I can just continue hacking and push new changes as they come without 
influencing the previous patches sent for review.

Optimally, I'm never forced to go to a website to manipulate the review. I.e. 
to add reviewers, or select branches or other metadata. Nor do I want to be 
forced to manually "publish" a review, I just pushed it for review after all.

## The Reviewer

Here, my biggest wish reflects that of the developer: I want to be able to see 
the developers intent, i.e. individual commits that make up one bigger 
mergeable hunk. I want to comment directly on lines of code in the patch. The 
patch should be displayed as easily readable as possible, with syntax 
highlighting and side-by-side diff view. As much as possible should be shown 
on a single page, I do not want to be forced to navigate between different 
files or the like, I need to see the big picture.

Optimally, I could apply hotfixes, such as whitespace changes, directly when 
doing the review. Finally, once the review is good to go, I want to click a 
button (or better: hotkey) to merge the patch into the upstream branch.

Furthermore, I'd like to use the same review mechanism for post-review. When a 
patch is triggering problems, I'd like to start a discussion in the context of 
the commit that was merged. Again, I want to annotate source lines. So rather 
than sending mails to kde-commits which are then lost, I want to have that 
tracked on a website for others to see.

Bye, HTH

-- 
Milian Wolff
mail at milianw.de
http://milianw.de