<div dir="ltr">On Thu, Apr 26, 2018 at 6:14 PM, Greg Grossmeier <span dir="ltr"><<a href="mailto:greg@wikimedia.org" target="_blank">greg@wikimedia.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">First, we now disallow multi-sync patch deployments. See T187761[0].<br>
This means that the sync order of files is determined by git commit<br>
parent relationships (or Gerrit's "depends-on"). This is to prevent SWAT<br>
deployers from accidentally syncing two patches in the wrong order.<br></blockquote><div><br></div><div>Is full scap now fast enough that sync-file is no longer necessary? Discussion on that task seems to say "no".<br><br>I'd hate to see people mangling[1] the git log by submitting and merging patch chains for updating individual files of a single logical change just to satisfy this SWAT requirement. I'd hate even more if people do that in mediawiki/core master (versus splitting an existing patch while backporting), to the point where I'd recommend -2ing such patch-chains there.<br></div><br></div><div class="gmail_quote">[1]: "mangling" both in that it would introduce unnecessary changes and in that looking at a single change doesn't let you see the changes to other files that should logically be grouped with it.<br></div><div class="gmail_quote"><br><br></div><div class="gmail_quote">P.S. So if someone has a change that needs to touch 2 files in both branches, they'd use up the whole smaller SWAT window for that one change because they'd need 2 patches (1 per file) that both count double (because two branches)?<br></div><div class="gmail_quote"><br clear="all"></div><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Brad Jorsch (Anomie)<br>Senior Software Engineer<br>Wikimedia Foundation</div></div></div>
</div></div>