https://bugzilla.wikimedia.org/show_bug.cgi?id=59892
--- Comment #4 from [email protected] --- (In reply to comment #2) > it should just splice your change into the new revision if there are > no conflicts. If different patch sets of a change would sit on top of each other or had to share a similar relation, then that might make sense. However, different patch sets of a change are fully unrelated. They can for example come with different parents. So automatically, silently merging in patch sets would bring in the other parents :-( Two patch sets of the same change need not even be connected in the graph of commits (e.g.: when force pushing a ref to a graph with a different, completele unconnected root). Automatically, merging in other patch sets would connect the different graphs :-( And for the issue of the bug's original description ... even if we'd automagically merge in patch sets, assume in addition to MaxSem's good patch set 20, I also uploaded a faulty patch set 20.5 after 20. If we'd automatically merge things, patch set 19, the good patch set 20, but also my faulty patch set 20.5 would get merged into patch set 21, and it would have gone live without review and have broken the site. When editing the commit message through the web UI on a page that shows patch set 19 as most recent patch set, the resulting patch set has the code of patch set 19 with the new commit message. When editing the commit message through the web UI on a page that shows patch set 20 as most recent patch set, the resulting patch set has the code of patch set 20 with the new commit message. Silently merging in other unreviewed parts of newer patch sets in behind the reviewer's back would make reviews only harder. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
