https://bugzilla.wikimedia.org/show_bug.cgi?id=59892

--- Comment #4 from christ...@quelltextlich.at ---
(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
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

Reply via email to