public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
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

      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