From: Colin Watson <cjwatson@ubuntu.com>
To: grub-devel@gnu.org
Subject: Re: Bazaar workflow for GRUB
Date: Mon, 18 Jan 2010 18:15:37 +0000 [thread overview]
Message-ID: <20100118181536.GV5847@riva.ucam.org> (raw)
In-Reply-To: <20100118094915.342a0469@svelte>
On Mon, Jan 18, 2010 at 09:49:15AM -0800, Colin D Bennett wrote:
> Do you want to mention how GRUB committers should merge features to the
> official trunk branch? I think the appropriate process, assuming
> (1) either a merge directive or a feature branch provides the change
> the we want to merge, and (2) we already have a local mirror branch of
> GRUB's trunk branch:
>
> # 1. Update local trunk mirror.
> cd trunk
> bzr pull
>
> # 2. Merge the feature branch or merge directive.
> bzr merge URL_OF_BRANCH
> # (Or bzr merge /path/to/merge_directive.patch)
> # If there are conflicts reported, fix them and use “bzr resolve” to
> # mark them as resolved.
> [ make grub ... and test it ]
>
> # 3. Commit the change locally.
> bzr commit
>
> # 4. Push to the upstream trunk.
> bzr push :parent
> # (The :parent argument can be omitted after the first time you do
> # this, since Bazaar will remember the given location from that
> # point on as the “push location” for the local branch.)
> # Note that in the unlikely event that someone happened to commit to
> # upstream trunk in the meantime since you did “bzr pull”, Bazaar
> # will tell you that the branches have diverged. You should try
> # again, doing “bzr pull --overwrite” and go back to step 2.
I recommend using a checkout for trunk, because that way bzr takes out a
write lock on the branch when you start committing and doesn't release
it until it's finished; it also warns you immediately if you're out of
date rather than making you commit and try to push before you find out.
This is a much more robust workflow for shared branches in my
experience.
The workflow for a trunk checkout, based on what you have above, is
simply:
# 1. Update local trunk checkout.
cd trunk
bzr update
# 2. Merge the feature branch or merge directive.
bzr merge URL_OF_BRANCH
# (Or bzr merge /path/to/merge_directive.patch)
# If there are conflicts reported, fix them and use “bzr resolve” to
# mark them as resolved.
[ make grub ... and test it ]
# 3. Commit the change.
bzr commit
# If someone happened to commit to upstream trunk since you did “bzr
# update”, Bazaar will tell you that you need to update again.
--
Colin Watson [cjwatson@ubuntu.com]
next prev parent reply other threads:[~2010-01-18 18:15 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-14 9:31 Bazaar workflow for GRUB BVK Chaitanya
2010-01-14 20:19 ` Bruce Dubbs
2010-01-18 17:49 ` Colin D Bennett
2010-01-18 18:15 ` Colin Watson [this message]
2010-01-18 20:48 ` Colin D Bennett
2010-01-19 22:40 ` Robert Millan
2010-01-19 4:27 ` BVK Chaitanya
2010-01-19 11:04 ` Colin Watson
2010-01-19 4:21 ` BVK Chaitanya
2010-01-19 10:52 ` Michal Suchanek
2010-01-19 14:49 ` Colin D Bennett
2010-01-19 14:59 ` Michal Suchanek
2010-01-19 23:09 ` Robert Millan
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=20100118181536.GV5847@riva.ucam.org \
--to=cjwatson@ubuntu.com \
--cc=grub-devel@gnu.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.