[llvm-dev] Committing with git

Tue Oct 29 18:02:03 PDT 2019

On Tue, Oct 29, 2019 at 7:24 AM Sachkov, Alexey via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> > At the dev meeting I heard Doug Gregor say something like, "what kind of
> dirty animals are you, you just push directly to master!?" Based on that, I
> think other communities may set up workflows where they push branches to
> places, and some automation rebases and updates master asynchronously,
> optionally conditioned on some (light) testing or approval.
>
> Someone has already mentioned rust-lang/rust GitHub project in other
> thread related to GitHub migration: from their contribution guide (
> https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#pull-requests
> ):
>
>
>
> > After someone has reviewed your pull request, they will leave an
> annotation on the pull request with an r+. It will look something like this:
>
> > @bors r+
>
> > This tells @bors, our lovable integration bot, that your pull request
> has been approved. The PR then enters the merge queue, where @bors will run
> all the tests on every platform we support. If it all works out, @bors will
> merge your code into master and close the pull request.
>
> > Depending on the scale of the change, you may see a slightly different
> form of r+:
>
> > @bors r+ rollup
>
> > The additional rollup tells @bors that this change is eligible for to be
> "rolled up". Changes that are rolled up are tested and merged at the same
> time, to speed the process up. Typically only small changes that are
> expected not to conflict with one another are rolled up.
>
>
>
> Just an idea of possible automation which will contribute to stability of
> master on merges
>

This is also how the Swift project is operating, apparently with success.
See this PR for example https://github.com/apple/swift/pull/27773 : the
comment "@swift-ci please smoke test and merge" triggers the CI and the PR
is merged automatically as soon as the builds are passing.
<https://github.com/apple/swift/pull/27773>

We had a round-table on this topic last week, Tom took notes that he'll
share with the list.

-- 
Mehdi

>
>
> *From:* llvm-dev <llvm-dev-bounces at lists.llvm.org> *On Behalf Of *Reid
> Kleckner via llvm-dev
> *Sent:* Tuesday, October 29, 2019 3:21 AM
> *To:* Nemanja Ivanovic <nemanja.i.ibm at gmail.com>
> *Cc:* llvm-dev <llvm-dev at lists.llvm.org>
> *Subject:* Re: [llvm-dev] Committing with git
>
>
>
> Yep, that's the case. I would say that we're no worse off than we were in
> terms of testing, as you note. Previously svn would let us racily commit to
> separate files without testing the new result. Now we're forced to observe
> the race.
>
>
>
> At the dev meeting I heard Doug Gregor say something like, "what kind of
> dirty animals are you, you just push directly to master!?" Based on that, I
> think other communities may set up workflows where they push branches to
> places, and some automation rebases and updates master asynchronously,
> optionally conditioned on some (light) testing or approval.
>
>
>
> Maybe we'll want something like that one day, but for now, we just have to
> pull, rebase, push, and hope.
>
>
>
> On Mon, Oct 28, 2019 at 4:19 PM Nemanja Ivanovic via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> Now that we have switched to git and I had to leave behind my wonderfully
> simple svn workflow I have noticed something curious when committing.
>
>
>
> My typical workflow once my patch is approved on Phabricator has always
> been:
>
> - Update my source tree to latest
>
> - Apply the approved patch
>
> - Rebuild
>
> - Retest
>
> - If all is well, commit
>
>
>
> Having to update again after rebuilding/retesting was extremely rare since
> SVN only prevented the commit if I am modifying the same file(s) that have
> been modified upstream since my update.
>
>
>
> So I tried replicating that workflow with git, but apparently that isn't
> really an option. Apparently git won't let me push if there have been any
> commits upstream at all between my last pull and my push. This means that I
> can never push from a fully tested state since it is almost impossible to
> find a window of 20-30 minutes without any commits (which is how long a
> rebuild/retest takes for me).
>
>
>
> One might argue that this is no worse than what I had with SVN since I
> would commit on top of changes that already happened upstream. But this is
> not always the case. Namely, if an upstream commit modifies the same file,
> causing a semantic conflict, I would not end up committing with the old svn
> workflow whereas I would end up committing with the new git workflow.
>
>
>
> I am not sure if this is something that can be solved (nor if it is
> something that needs to be solved) but I thought I would just bring it up.
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
> --------------------------------------------------------------------
> Joint Stock Company Intel A/O
> Registered legal address: Krylatsky Hills Business Park,
> 17 Krylatskaya Str., Bldg 4, Moscow 121614,
> Russian Federation
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191029/e9a6819e/attachment-0001.html>