Using merge --pull

[Michael Gliwinski]

On Saturday 16 January 2010 15:34:58 Eli Zaretskii wrote:
> > Date: Sat, 16 Jan 2010 09:39:57 -0500
> > From: Gordon Tyler <gordon at doxxx.net>
> >
> > > And a related question: if "bzr merge" does not find any conflicts,
> > > what is the reason for it not to commit the merges automatically right
> > > away?
> >
> > Just because it merged without conflicts doesn't mean that the result is
> > semantically correct. The two-step merge -> commit should actually be
> > merge -> test -> fix if necessary -> commit.
>
> Thanks, that makes sense.  But similarly, I could test _after_
> committing, fix whatever needs fixing, then commit the changes, right?
> Assuming the merge is in the branch where I'm developing a feature,
> and the source is the parent branch to which I will eventually submit
> my changes, there really is no difference between these two, is there?

That depends.  If you don't mind having commits from trunk (or parent) 
intermingled with your commits in your branch history then I suppose not.  
There was a discussion about having some way of allowing the separation of 
changes merged from a branch from changes you had to make to have them "fit 
in", but that would also require being able to commit conflicts.

You could probably rather easily automate 'merge + commit if no conflicts' but 
that is not the same as 'merge --pull' as the effect on history is different.

> Could it be that the current operation is biased towards a use-case of
> accepting merges from a less trusted branch to a more trusted one (or
> to a trunk), where the person who merges may wish to reject the
> changes if they don't pass the tests?  If so, won't "bzr uncommit" fix
> that use-case?  And the person who does this is anyway likely to be
> more experienced with Bazaar than the one in the previous use-case, so
> the possible complication of uncommitting is not a serious one.  By
> contrast, less experienced users who started a branch just to try
> things out would be served better by automatically committing from the
> parent upon a merge.

I'd say as it is now it easily supports both, and it's ultimately up to you 
how you use it (which includes automating it if it fits your workflow), but 
if it did by default do some shortcut like that, it would break for other 
workflows (e.g. where a policy dictates test before commit or simply when 
someone prefers to review merges before committing).



-- 
Michael Gliwinski
Henderson Group Information Services
9-11 Hightown Avenue, Newtownabby, BT36 4RT
Phone: 028 9034 3319

**********************************************************************************************
The information in this email is confidential and may be legally privileged.  It is intended solely for the addressee and access to the email by anyone else is unauthorised.
If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful.
When addressed to our clients, any opinions or advice contained in this e-mail are subject to the terms and conditions expressed  in the governing client engagement leter or contract.
If you have received this email in error please notify support at henderson-group.com

John Henderson (Holdings) Ltd
Registered office: 9 Hightown Avenue, Mallusk, County Antrim, Northern Ireland, BT36 4RT.
Registered in Northern Ireland
Registration Number NI010588
Vat No.: 814 6399 12
*********************************************************************************