git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCHv3] Add branch management for releases to gitworkflows

From
Nanako Shiraishi <nanako3@lavabit.com>
Date
Nov 13, 2009, 23:10 UTC
Message-ID
<20091114081040.6117@nanako3.lavabit.com>
In-Reply-To
<4AFDE421.5050307@fastmail.fm>
Quoting Raman Gupta <rocketraman@fastmail.fm>
Show 26 quoted lines
> 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?
It is irrelevant that you can cherry-pick to 'maint'.

You can, and Junio does, cherry-pick some commits from master to maint from time to time. But even if you have such cherry-picked commits on the maintenance branch, the result, with zero or more other maintenance commits on top, is always merged back to the master branch (you can look at "gitk origin/maint origin/master" to see yourself).

So when Junio tags the release from the tip of the master branch, it is a superset of the maintenace branch; it is irrelevant if maint has some commits that are cherry-picked from master.

-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
Previous: Raman GuptaNext: Raman Gupta
Message 7 of 16 in “Add branch management for releases to gitworkflows”
  1. rocketraman@fastmail.fmNov 12, 2009
  2. [PATCHv3] Add branch management for releases to gitworkflowsrocketraman@fastmail.fm, Nov 12, 2009
  3. skillzero@gmail.comNov 12, 2009
  4. Raman GuptaNov 12, 2009
  5. Nanako ShiraishiNov 13, 2009
  6. Raman GuptaNov 13, 2009
  7. Nanako ShiraishiNov 13, 2009
  8. Raman GuptaNov 14, 2009
  9. Björn GustavssonNov 14, 2009
  10. Nanako ShiraishiNov 14, 2009
  11. Raman GuptaNov 14, 2009
  12. Junio C HamanoNov 15, 2009
  13. Thomas RastNov 15, 2009
  14. Raman GuptaNov 18, 2009
  15. Thomas RastNov 18, 2009
  16. Nanako ShiraishiNov 19, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.