On Tuesday 2013-01-15 13:20 -0800, Gregory Szorc wrote:
> This seems to make sense. My only concern is if there is a scenario
> where you absolutely need to push without incurring a build (think
> merge commit where you don't have control over the previous
> commits). I'm not sure why we'd do that,
On 15/01/2013 23:52, Daniel Holbert wrote:
In that scenario (if it exists) you could always use the build API (and
the shortcut red-stopsign buttons on TBPL) to effectively get what you want.
Killing running builds would mean needing to clobber all machines for
all platforms for that tree (unt
On 01/15/2013 01:20 PM, Gregory Szorc wrote:
> This seems to make sense. My only concern is if there is a scenario
> where you absolutely need to push without incurring a build (think merge
> commit where you don't have control over the previous commits). I'm not
> sure why we'd do that, so I'm inc
On 1/15/13 1:11 PM, Ehsan Akhgari wrote:
Hi all,
Currently, DONTBUILD only takes affect if it's set on the tip of the
changesets that you push. This can cause problems when merging between
different trees if the target tree is a full subset of the origin tree
(i.e., fast-forward merges in git t
Hi all,
Currently, DONTBUILD only takes affect if it's set on the tip of the
changesets that you push. This can cause problems when merging between
different trees if the target tree is a full subset of the origin tree
(i.e., fast-forward merges in git terminology) when the top-most changeset
is
5 matches
Mail list logo