Platonides wrote: > What I have trouble with is in imagining the UI for reviewing a topic > branch, with perhaps several commits per "step".
To me the concept of topic is to lamely tag a commit as being part of specific area of code such as API, Parser, tests. We could probably tweak Gerrit to automatically assign a set of reviewer just on the basis of the topic name. If someone is working on a big changes having several steps, I would prefer we use a branch (for now the sandbox system). Then each final commit will be one of the step and all the intermediate/fixing commits would be patchsets. One could also submit all their patchsets and have them submitted in reversed date order. The submission of the first patch that has an already merged parent will then trigger a merge commit of all the changes. An example with some doc rewrite I did which was merged by Sam in mediawiki/core.git: $ git log --oneline --graph d11d328^..444ab87 * 444ab87 Merge changes Icfd267a9,If956c0a1,I0e232273,Ia84494c8,Ib70e0046,If2c01a11,I40196371 |\ | * 4a69fce prettify documentation | * 12e608e converts '@fixme' to '@todo FIXME' | * d5737f8 update @param @return doc in several files | * bcf0010 prettify filerepo documentation | * 9aa825f prettify SkinTemplate:makeLink documentation | * 1dd38a7 move parameter doc under @param | * aab43dd escape tags and entity in doxygen comments * | 1a9246e ChannelFeed now marked as an abstract class * | f3f985c remove unneeded @abstract |/ * d11d328 Merge "Fixed Language::isValidBuiltInCode exception." * 75f5bda Fixed Language::isValidBuiltInCode exception. $ I made my changed in sequence and based on d11d328. Submitted all of them then Sam submitted all my change submitting aab43dd as the last. Gerrit then happily merged them. > Always registering as a merge, has such as storing the merger name as > the commiter, but I'd like keeping them as fest-forwards having for > one-commit changes. A strategy could be setup where we always merge as to know from git history who actually applied the change but do a fast forward when the submitter is the patch author. Still messy though, I can live without the merge commits. > I think the history would easily get hard to browse. One can filter out merge commit by passing `--no-merges` to `git log` > Also, I don't like how when browsing a merge (eg. gitk) you are not > shown the actual changes to the repository (which for us is the > left-parent). Anyone knows of a way to do so? A merge commit does not really have any change by itself. I just do a diff against the merge parent such as: git diff 444ab87^ 444ab87 The related changelist would be: git log --oneline 444ab87^..444ab87 -- Antoine "hashar" Musso _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
