On 19 July 2016 at 17:10, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote:> Tim’s repo is using "status checks” and not only protected branch.Yep, I think the main benefit (so far) over just protected branches would be that we can also guarantee sane timestamps on master, which should mean we can reconstruct the llvm-project umbrella uniquely when its script goes down or something else weird happens. I think that's a useful ability to have, and can't really think of a way to do it if you can't trust a commit's time (commit-date here, not author-date). I'm not sure how theoretical that issue is though. It would also alter the usual git workflow, which is unfortunate. You'd have to explicitly run "git llvm-verify" before pushing to master (or "git llvm-push", or whatever). Tim.
On 19 July 2016 at 17:54, Tim Northover <t.p.northover at gmail.com> wrote:> Yep, I think the main benefit (so far) over just protected branches > would be that we can also guarantee sane timestamps on master, which > should mean we can reconstruct the llvm-project umbrella uniquely when > its script goes down or something else weird happens.Actually, now that I think about it, you wouldn't necessarily get a perfect *re*construction (the umbrella would be triggered by a push so could still have a different order if each push is picked up immediately and one commit-date lags). What you would get is a better (not perfect) guarantee of each umbrella commit having a sane state, after script downtime. That's seems less persuasive to me. Tim.
> On Jul 19, 2016, at 6:00 PM, Tim Northover <t.p.northover at gmail.com> wrote: > > On 19 July 2016 at 17:54, Tim Northover <t.p.northover at gmail.com> wrote: >> Yep, I think the main benefit (so far) over just protected branches >> would be that we can also guarantee sane timestamps on master,What about linear history? Does not this require the "status checks”? — Mehdi>> which >> should mean we can reconstruct the llvm-project umbrella uniquely when >> its script goes down or something else weird happens. > > Actually, now that I think about it, you wouldn't necessarily get a > perfect *re*construction (the umbrella would be triggered by a push so > could still have a different order if each push is picked up > immediately and one commit-date lags). > > What you would get is a better (not perfect) guarantee of each > umbrella commit having a sane state, after script downtime. That's > seems less persuasive to me. > > Tim.