[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bazaar workflow for GRUB

From: BVK Chaitanya
Subject: Re: Bazaar workflow for GRUB
Date: Tue, 19 Jan 2010 09:51:21 +0530

On Mon, Jan 18, 2010 at 11:19 PM, Colin D Bennett <address@hidden> wrote:
>> * For Occasional Contributors
>> This workflow is recommended for users/developers who want to fix
>> just-one GRUB issue.  This involves a trunk checkout, some local
>> commits (as necessary for fixing the issue) and sending the patch to
>> [[][grub-devel]] mailing
>> list.  GRUB maintainers would take care of committing it to the trunk.
> I would avoid using the word “checkout” except when an actual Bazaar
> checkout (heavyweight or lightweight) is being used.  I think the
> workflow you describe (avoiding checkouts) keeps things simpler since
> checkouts behave differently than branches in some cases, and branches
> with the “pull” command can do everything that a regular checkout can.

Yes, I will replace checkout with "copy" or something.

Yes, I wanted to keep it simple so I suggested bzr branch (instead of
bzr checkout) everywhere.  GRUB branch is small (about 15MB), so IMO
there is not much to gain in checkout than a branch.

>> # create a patch and send to mailing list
>> grub$ bzr diff -r submit: > ~/my-issue-fix.diff
> Why not use “bzr send -o ~/my-issue-fix.patch” to create a merge
> directive+patch+revision bundle?  The benefit of bzr send over plain bzr
> diff is that individual revisions within the change are preserved,
> which can provide richer history.  Merge directives can simply be
> applied with “bzr merge my-issue-fix.patch”.

I haven't seen anybody sending "bzr send" patches in the ML, so I
didn't want to introduce something new.  Is its format compatible with
regular patch tool?

> It is also easy to discard sub-revisions when merging a revision bundle
> into mainline, if for some reason the committer so desires.

bzr revert --forget-merges?

> I would recommend or at least mention the option of creating a shared
> repository before branching the remote branch.  Whenever a branch is
> downloaded to a directory underneath a shared repository in the
> directory hierarchy, its revisions are stored in the shared repository
> instead of directly in the branch directory.  This means the you can
> cheaply clone the branch (or download other remote branches related to
> it, for instance) and the common revisions will not be duplicated on
> your hard disk or re-transferred across the network.
> Before executing the “bzr branch” command, run “bzr init-repo .” in a
> directory under which you wish to put your branches.  After this, all
> other commands will be the same whether a shared repository is in use
> or not.

I will add an entry for this.

> Do you want to mention how GRUB committers should merge features to the
> official trunk branch?

Yeah, I completely forgot about this one.  I need to add a new section.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]