From: Jani Nikula <jani.nikula@intel.com>
To: Daniel Vetter <daniel@ffwll.ch>, Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>, intel-gfx@lists.freedesktop.org
Subject: Re: [maintainer-tools PATCH] dim: Add helpers to move fixes branches up.
Date: Tue, 03 Oct 2017 13:30:37 +0300 [thread overview]
Message-ID: <8737705xrm.fsf@intel.com> (raw)
In-Reply-To: <20171003082548.vrujbzqu4vnl3fsa@phenom.ffwll.local>
On Tue, 03 Oct 2017, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Mon, Oct 02, 2017 at 11:32:36AM -0700, Rodrigo Vivi wrote:
>> One of main doubts I had when starting maintaining the
>> fixes branches was when to move them, but also how, to-where,
>> and when avoid moving and stay on the current one.
>>
>> So this scripts aims to avoid doubts and mistakes on fixes
>> maintainance besides making all bases more clear and
>> standardized.
>>
>> Cc: Jani Nikula <jani.nikula@intel.com>
>> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
>> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
>> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
>
> I think calling these rebase is not good, and doing an actual rebase is
> also not good really. Here's my thoughts on this:
>
> - I'd call the command "forward"
>
> - It should do a fast forward only, and if that fails, abort. So git merge
> --ff-only. If fast-forward isn't possible I think it should suggest to
> do a dim backmerge, but only if moving forward is really required.
>
> - There's more than drm-intel.git in dim, I think it'd be great if we can
> make this work for other repos. Currently the meaning of the 3 branches
> is hard-coded in dim_push_branch at the end where we call
> update_linux_next. I think it'd be good to extract this information into
> nightly.conf (as an array perhaps, indexed by repo name, with the three
> names, not sure how to do that best). With that you could do a generic
> dim forward(-branch) which would pick the right logic depending whether
> you're on -fixes, -next-fixes or the main feature branch.
>
> Thoughts?
I have a bunch of refactoring in the pipeline relying more and more on
the information in nightly.conf so I suggest holding off until those
have landed.
BR,
Jani.
> -Daniel
>
>> ---
>> dim | 50 ++++++++++++++++++++++++++++++++++++++++++++++++++
>> dim.rst | 13 +++++++++++++
>> 2 files changed, 63 insertions(+)
>>
>> diff --git a/dim b/dim
>> index fc16d114632f..8643bafcd2a5 100755
>> --- a/dim
>> +++ b/dim
>> @@ -918,6 +918,56 @@ function dim_apply_pull
>> return $rv
>> }
>>
>> +function rebase_branch
>> +{
>> + local branch newbase
>> +
>> + branch=${1:?$usage}
>> + shift
>> + newbase=${1:?$usage}
>> + shift
>> +
>> + assert_branch $branch
>> + assert_repo_clean
>> +
>> + $DRY git rebase $newbase "$@"
>> +}
>> +
>> +dim_alias_rf=rebase-fixes
>> +function dim_rebase_fixes
>> +{
>> + local tag commit
>> +
>> + commit=$(git rev-list --tags --max-count=1 --remotes=$DIM_DRM_INTEL)
>> + tag=$(git describe --tags $commit)
>> +
>> + if [[ $tag != *"-rc"* ]]; then
>> + echoerr "Tag $tag is not an -rc one."
>> + return 1;
>> + fi
>> +
>> + rebase_branch drm-intel-fixes $tag "$@"
>> +
>> + if [ $DRY ]; then
>> + return 0;
>> + fi
>> +
>> + if [ $(git rev-parse HEAD) != $commit ]; then
>> + git reset --hard $DIM_DRM_INTEL_REMOTE/drm-intel-fixes
>> + echoerr "ERROR: fixes didn't fully propagated yet, aborting"
>> + fi
>> +}
>> +
>> +dim_alias_rnf=rebase-next-fixes
>> +function dim_rebase_next_fixes
>> +{
>> + local dim_drm_upstream_remote
>> +
>> + dim_drm_upstream_remote=$(url_to_remote $drm_upstream_git)
>> +
>> + rebase_branch drm-intel-next-fixes $dim_drm_upstream_remote/drm-next "$@"
>> +}
>> +
>> function dim_backmerge
>> {
>> local branch upstream patch_file
>> diff --git a/dim.rst b/dim.rst
>> index 65e652e8bc75..a53ef8aa67e2 100644
>> --- a/dim.rst
>> +++ b/dim.rst
>> @@ -376,6 +376,19 @@ apply-pull *branch*
>> -------------------
>> Reads a pull request mail from stdin and merges it into the given *branch*.
>>
>> +rebase-fixes
>> +------------
>> +Rebases drm-intel-fixes to latest Linus tag.
>> +This command is to be used following a Linus "-rc" tag, in order to move
>> +drm-intel-fixes branch up.
>> +It fails if tag is not an -rc tag.
>> +It fails if your current fixes didn't fully propagated yet.
>> +
>> +rebase-fixes-next
>> +-----------------
>> +Rebases drm-intel-next queued into drm-next.
>> +This command is to be used after drm-next is closed for new features.
>> +
>> backmerge *branch* *upstream*
>> -----------------------------
>>
>> --
>> 2.13.5
>>
--
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
prev parent reply other threads:[~2017-10-03 10:31 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-02 18:32 [maintainer-tools PATCH] dim: Add helpers to move fixes branches up Rodrigo Vivi
2017-10-03 8:25 ` Daniel Vetter
2017-10-03 10:30 ` Jani Nikula [this message]
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=8737705xrm.fsf@intel.com \
--to=jani.nikula@intel.com \
--cc=daniel.vetter@ffwll.ch \
--cc=daniel@ffwll.ch \
--cc=intel-gfx@lists.freedesktop.org \
--cc=rodrigo.vivi@intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox