All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Cobbley <david.j.cobbley@linux.intel.com>
To: openbmc@lists.ozlabs.org
Subject: Re: Managing openbmc with subtree
Date: Tue, 7 Aug 2018 10:16:58 -0700	[thread overview]
Message-ID: <9b967642-9c97-c7e5-7114-c024ada10a4f@linux.intel.com> (raw)
In-Reply-To: <8E5317F7-E0B1-4A2F-B047-52B77E1AD13F@fuzziesquirrel.com>

I do agree that we can find a scriptable solution to this, however, I 
feel using the OWNERS plugin provides a much easier workflow for all 
developers, i.e. nothing changes from their perspective.

Additionally, we can still subtree on the back end after code is 
successfully merged into master.

Thanks,
-Dave

On 08/06/2018 11:47 AM, Brad Bishop wrote:
>> On Aug 1, 2018, at 5:53 PM, Dave Cobbley <david.j.cobbley@linux.intel.com> wrote:
>>
>> I posted an initial draft of what permissions could look like in the top level meta-data.
>>
>> https://gerrit.openbmc-project.xyz/#/c/openbmc/openbmc/+/11730/
> At first I was OK with this idea but instead of rushing to something
> I’d like to slow down for a sec and be sure we don’t like the other
> options.
>
> My issue with 11730 is that we wind up with different workflows for
> updating the different subtrees - for example updating meta-virtualization
> is different than updating meta-phosphor.
>
> If we go back to your original workflow where the developer pushes directly
> to the subtree repository instead of openbmc/openbmc, recall we were stuck
> on how to do it:
>
>>>> However at this point, I end up with two commits in the parent repo, one with the squashed changes, and a merge commit.
>>>> I don't know how to do this operation without ending up with a merge commit, do you have any advice here?
>>> To avoid the merge you can skip the subtree pull (which does a merge) and
>>> instead generate a patch:
>>>
>>> git cherry-pick —strategy=subtree -Xsubtree=path/to/subtree <squash-commit>
>
> Elaborating on my suggestion from before - here is a possible workflow.
>
> Consider a repository with two remotes:
>
> $ cat ~/.ssh/config
> Host openbmc.gerrit
>          Hostname gerrit.openbmc-project.xyz
>          Port 29418
>          User user
>          IdentityFile ~/.ssh/my-gerrit-key
>
> $ git remote -v
> meta-phosphor-gerrit    ssh://openbmc.gerrit/openbmc/meta-phosphor (fetch)
> meta-phosphor-gerrit    ssh://openbmc.gerrit/openbmc/meta-phosphor (push)
> openbmc-gerrit  ssh://openbmc.gerrit/openbmc/openbmc (fetch)
> openbmc-gerrit  ssh://openbmc.gerrit/openbmc/openbmc (push)
>
> You can make and commit changes as usual.  When it comes time to push for
> review:
>
> $ git checkout -b phosphor-master meta-phosphor-gerrit/master
> $ git cherry-pick —-strategy=subtree -Xsubtree=meta-phosphor <openbmc/openbmc-sha>
> $ git push meta-phosphor-gerrit HEAD:refs/for/master
>
> This gives us the same process for all subtrees, whether or not they are
> openbmc hosted subtrees.  It also does not require people hacking on a
> subtree to clone OpenBMC when it doesn’t make sense for them to do that,
> such as someone just using the Aspeed BSP layer.
>
> Granted it is a couple extra commands, but it seems like something that could
> be scripted pretty easily.  Thoughts?
>
> -brad
>
>> This will require additional people receive +2 permissions, but the OWNERS plugin will ensure that a patch cannot get merged unless it has +2 from the appropriate people.
>>
>> Thanks,
>> -Dave

  reply	other threads:[~2018-08-07 17:16 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-19 20:08 Managing openbmc with subtree Dave Cobbley
2018-07-20 17:42 ` Dave Cobbley
2018-07-20 17:43 ` Brad Bishop
2018-07-20 17:47   ` Brad Bishop
2018-08-01 21:53   ` Dave Cobbley
2018-08-06 17:30     ` Ed Tanous
2018-08-06 18:47     ` Brad Bishop
2018-08-07 17:16       ` Dave Cobbley [this message]
2018-08-07 19:30         ` Brad Bishop
2018-08-08 22:14           ` Dave Cobbley
2018-08-09 20:16             ` Brad Bishop
2018-08-09 22:23               ` Dave Cobbley
2018-08-10  0:31                 ` Dave Cobbley
2018-08-10  3:17                   ` Brad Bishop
2018-08-10 20:44                     ` Dave Cobbley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9b967642-9c97-c7e5-7114-c024ada10a4f@linux.intel.com \
    --to=david.j.cobbley@linux.intel.com \
    --cc=openbmc@lists.ozlabs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.