On Tue, 19 Jan 2010 11:52:27 +0100 Michal Suchanek <hramr...@centrum.cz> wrote:
> 2010/1/19 BVK Chaitanya <bvk.gro...@gmail.com>: > > On Mon, Jan 18, 2010 at 11:19 PM, Colin D Bennett > > <co...@gibibit.com> wrote: > > >>> > >>> # 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 > > Perhaps they did not know or did not need to. AFAICT there isn't any > rebase feature in bzr so sending these is the only option for longer > lasting local branches. There is actually a ‘rebase’ plugin for bzr (“bzr branch lp:bzr-rebase $HOME/.bazaar/plugins/rebase” to install for a user). I'm not sure how ‘bzr send’ is in some way more useful if a rebase operation was not available, however. > > didn't want to introduce something new. Is its format compatible > > with regular patch tool? > > Yes, they do include something that looks like a regular patch. > Did not try applying it, though. The output of ‘bzr send’ normally includes three parts: 1. Merge directive. This specifies what branch the patch is against as well as other information about it. This can be the only part if the changes are available in a publicly accessible branch. 2. Patch. This is standard unified diff format and can be applied with the patch command. 3. Revision bundle. This contains the actual complete revision data for the changes. Each individual committed revision including log messages, renamed files, merge history, etc., is included in the revision bundle. This is a chunk of binary data encoded to ASCII. When the revision bundle is provided, no public branch containing the patch's changes is required to be available. In short, the ‘bzr send’ output can be treated as a standard patch for review purposes as well as for application using the patch command, but using ‘bzr merge’ for merge these special patches provides richer history and much better automatic merges than would be obtained by using the standard patch command. Regards, Colin
signature.asc
Description: PGP signature
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel