All of lore.kernel.org
 help / color / mirror / Atom feed
From: Raman Gupta <rocketraman@fastmail.fm>
To: Nanako Shiraishi <nanako3@lavabit.com>
Cc: git@vger.kernel.org, trast@student.ethz.ch, gitster@pobox.com
Subject: Re: [PATCHv3] Add branch management for releases to gitworkflows
Date: Fri, 13 Nov 2009 17:56:33 -0500	[thread overview]
Message-ID: <4AFDE421.5050307@fastmail.fm> (raw)
In-Reply-To: <20091114071946.6117@nanako3.lavabit.com>

Nanako Shiraishi wrote:
>  .Update maint to new release
>  [caption="Recipe: "]
>  =====================================
> -* `git checkout maint`
> -* `git merge master`
> +* `git checkout maint`
> +* `git merge --ff-only master`
>  =====================================
>  
> -This 'should' fast forward 'maint' from 'master'. If it is not a fast
> -forward, then 'maint' contained some commits that were not included on
> +This should fast-forward 'maint' from 'master'. If it is not a
> +fast-forward, then 'maint' contained some commits that were not included on
>  'master', which means that the recent feature release could be missing
> -some fixes made on 'maint'. The exception is if there were any commits
> -that were cherry-picked to 'maint' as described above in "Merging
> -upwards". In this case, the merge will not be a fast forward.

I noticed you removed the discussion I added about the situation in
which maint will *not* be a subset of master i.e. when the user has
cherry-picked commits from other branches. This type of cherry-pick is
described as a valid operation, though one to generally be avoided
earlier in the man page. If we tell users that the occasional
cherry-pick to maint is ok, then shouldn't we explain how that affects
the release process?

Cheers,
Raman

  reply	other threads:[~2009-11-13 22:56 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-12 19:46 Add branch management for releases to gitworkflows rocketraman
2009-11-12 19:46 ` [PATCHv3] " rocketraman
2009-11-12 20:08   ` skillzero
2009-11-12 20:30     ` Raman Gupta
2009-11-13 22:19   ` Nanako Shiraishi
2009-11-13 22:56     ` Raman Gupta [this message]
2009-11-13 23:10       ` Nanako Shiraishi
2009-11-14  5:35         ` Raman Gupta
2009-11-14  8:59           ` Björn Gustavsson
2009-11-14  9:01           ` Nanako Shiraishi
2009-11-14 17:27             ` Raman Gupta
2009-11-15  9:14     ` Junio C Hamano
2009-11-15 17:07     ` Thomas Rast
2009-11-18  0:19       ` Raman Gupta
2009-11-18 14:59         ` Thomas Rast
2009-11-19  4:11           ` Nanako Shiraishi

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=4AFDE421.5050307@fastmail.fm \
    --to=rocketraman@fastmail.fm \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=nanako3@lavabit.com \
    --cc=trast@student.ethz.ch \
    /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.