Roan Kattouw wrote: > The only thing that may be different, depending on what our workflow > ends up being, is that messages that have been added in some branch > that hasn't been merged to trunk yet will not automatically be picked > up by TWN for translation. This is technically already the case, but > branches aren't very common at this time and will likely become more > common with Git. If we end up with a first-review-then-merge-to-trunk > workflow...
What workflow would we be using? It's fine that git supports many ways to be used but the important one is how would mw be used, and probably each one is thinking that it would be used in a slightly different way. I'm not a proficient git user. I see benefits from a DVCS. Automatically merging/umerging a revision to 1.17/wmf with a checkbox at CR would be cool, for instance. Stacking several commits before one push also looks nice. How would that be presented to the reviewer? As a single diff, as several ones? Note that this could already be done with svn (if they are easy diffs). Even with some kind of review-before-merge approach we would still need a trunk from which to work usually, and the stable reviewed branch would advance behind it. (Do git patch queue work like that?) Backing out changesets would be easier, and they could be continued in a forked branch, but I'm not sure that looks nice. Robla says that it will mean less reviewing problems. It may decrease them, but there will still be "errors noticed just after pushing" (ie. separate changes that should be just one logical change). The benefits for working with branches would just be those derived from better merging. We can already review a branch (although nobody likes to), or perform a review by files. And still, having a DVCS won't avoid silly merging errors. A DCVS also complicates some things. There is an entry barrier to pass. Revision number such as r12345 is really easy (still, I'd like having a summary attached to revision names), and we use them everywhere* . Talking about revision 0fda45694 is ugly. Mercurial also has revision numbers, but they follow the revisions at the working copy, not those at the master repo. * Which is good. I am proud for example on how we reference the relevant commits on bugzilla, so the path from bug to fix is trivial. On some projects, that is hard, and you have to end up comparing the bug closing date with near commits. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
