Using merge --pull

[Guy Gascoigne-Piggford]

I have to say that this is exactly the reason why we stopped (very quickly)
recommending merge --pull.  Simply it put folks in the habit of using it all
of the time, and caused them to forget when we absolutely didn't want them
doing so.

We have a mix of developers using branches form the feature branch and ones
just developing in a checkout and overlaying the history of the feature
branch with one of those individual dev branched confused the hell out of
people.  It's easy enough to fix if you notice at the time, but if it's a
few days, it becomes a real pain.

If you know what you are doing, it's a useful tool, but if you don't and use
it blindly, it's just a source of confusion.

Guy


On Sat, Jan 16, 2010 at 3:43 AM, Juanma Barranquero <lekktu at gmail.com>wrote:

> On Sat, Jan 16, 2010 at 12:20, Eli Zaretskii <eliz at gnu.org> wrote:
>
> > I meant merging in a branch, while the source is the trunk or a parent
> > branch.
>
> I know. I was pointing out that if you get into the habit of doing
> "merge --pull" in branches, it's more likely that you will
> accidentally use it in the trunk (gone there, done that, bought the
> t-shirt).
>
> > How do separate commits enter this picture?
>
> I don't understand.
>
>  cd trunk
>  bzr merge ../my-branch
>
> will merge changes from my-branch into trunk, and set the metadata
> info so "bzr commit" will do *one* commit (a merge commit, with
> history visible through -n0). On the other hand,
>
>  cd trunk
>  bzr merge --pull ../my-branch
>
> assuming it does a pull and not a merge, will do as many (automatic)
> commits into trunk as there are in my-branch and not in trunk. So the
> resulting history is different in both cases.
>
>    Juanma
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/bazaar/attachments/20100118/2782492e/attachment.htm