commit path sorting for Git and guidelines

[Alexander van Loon]

With the import of commits from Git going again, automatic commit path sorting doesn’t seem to be working for Git? Is it not 
implemented yet?

I’m always using Chromium to access Enzyme, because rekonq doesn’t work (well). Is that rekonq’s fault or Enzyme’s fault? 
And I still encounter the 99 commits saved bug often, because the first commit often refuses to save. Do others still 
encounter this bug as well?

Can everyone take a look at http://community.kde.org/Commit_Digest_Guidelines and change them if necessary? If I 
remember correctly, Danny said on the mailing list he would take a look at them, but so far I’m the only one who has ever 
edited them. I’d especially like some input on the question of what we do with commits mentioning that a branch is merged, 
which occur often since the Git migration. See the Uncertain section on the wiki page.

As far as I know commits made to a branch will reach the review first, followed by a branch merge last. If I’m correct these 
branches are clones of the trunk or head, and they’re some kind of isolation cell were developers can work on features 
without disrupting the stability of head. Considering that the interesting commits mentioning the new features being worked 
on in a certain branch are supposed to be included already, and that the banch merge commits are very nondescriptive and 
merely tells us that the features are from then on part of head, I don’t think we should include them, or should we?