Strange response after merge from upstream

Strange response after merge from upstream

[Eli Zaretskii]

I created a repository with a trunk/ and quickfixes/ branches in it,
just like the wiki says.  I waited a day without making any
modifications in quickfixes/ (it looks like the bzr repository is only
updated once a day), and then did a "bzr pull" in trunk/ and "bzr
merge; bzr commit" in quickfixes/.  Strangely, "bzr missing" after
that in quickfixes/ says I "have 1 extra revision(s)" and shows all
the files merged from the trunk.  Is that expected? it surprised me,
because I thought the result would be a branch that is an exact copy
of the trunk, and thus has no "extra revision(s)".

Re: Strange response after merge from upstream

[Stefan Monnier]

> I created a repository with a trunk/ and quickfixes/ branches in it,
> just like the wiki says.  I waited a day without making any
> modifications in quickfixes/ (it looks like the bzr repository is only
> updated once a day),

The bzr repository in svannah is not auto-updated at all, AFAIK.  Is it?

> and then did a "bzr pull" in trunk/ and "bzr merge; bzr commit" in
> quickfixes/.  Strangely, "bzr missing" after that in quickfixes/ says
> I "have 1 extra revision(s)" and shows all the files merged from the
> trunk.  Is that expected? it surprised me, because I thought the
> result would be a branch that is an exact copy of the trunk, and thus
> has no "extra revision(s)".

As you've made a "commit", you created a new revision which is not in
the upstream branch.


        Stefan

Re: Strange response after merge from upstream

[Andreas Schwab]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> The bzr repository in svannah is not auto-updated at all, AFAIK.  Is it?

It's a manual process which I run once a day.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Strange response after merge from upstream

[Alexander Belchenko]

Eli Zaretskii пишет:
> I created a repository with a trunk/ and quickfixes/ branches in it,
> just like the wiki says.  I waited a day without making any
> modifications in quickfixes/ (it looks like the bzr repository is only
> updated once a day), and then did a "bzr pull" in trunk/ and "bzr
> merge; bzr commit" in quickfixes/.  Strangely, "bzr missing" after
> that in quickfixes/ says I "have 1 extra revision(s)" and shows all
> the files merged from the trunk.  Is that expected? it surprised me,
> because I thought the result would be a branch that is an exact copy
> of the trunk, and thus has no "extra revision(s)".

Yes, after merge you did commit, therefore you have 1 extra revision (just committed).

You may want to use `bzr merge --pull` to get equivalent of git fast-forward merge.
merge --pull will pull new changes from other branch if possible, thus make your branch a copy of
the other branch. Or it will do merge when 2 branches are diverged, i.e. both branches has new
commits, not present in other branch.

Re: Strange response after merge from upstream

[Stefan Monnier]

>> The bzr repository in svannah is not auto-updated at all, AFAIK.  Is it?
> It's a manual process which I run once a day.

Interesting.  And the "new" repositories are "compatible" with the old
ones?  I thought such incremental updates of git->bzr conversions were
not possible with fast-import,


        Stefan

Re: Strange response after merge from upstream

[Óscar Fuentes]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> The bzr repository in svannah is not auto-updated at all, AFAIK.  Is it?
>> It's a manual process which I run once a day.
>
> Interesting.  And the "new" repositories are "compatible" with the old
> ones?  I thought such incremental updates of git->bzr conversions were
> not possible with fast-import,

This seems to answer your question:

http://bazaar-vcs.org/BzrFastImport#Mirroring%20of%20Foreign%20Repositories

OTOH, I just executed a `bzr pull' on my bzr branch created some days
ago and got a pile of new revisions.

-- 
Óscar

Re: Strange response after merge from upstream

[Eli Zaretskii]

> From: Alexander Belchenko <bialix@ukr.net>
> Date: Wed, 02 Dec 2009 00:23:46 +0200
> 
> Eli Zaretskii пишет:
> > I created a repository with a trunk/ and quickfixes/ branches in it,
> > just like the wiki says.  I waited a day without making any
> > modifications in quickfixes/ (it looks like the bzr repository is only
> > updated once a day), and then did a "bzr pull" in trunk/ and "bzr
> > merge; bzr commit" in quickfixes/.  Strangely, "bzr missing" after
> > that in quickfixes/ says I "have 1 extra revision(s)" and shows all
> > the files merged from the trunk.  Is that expected? it surprised me,
> > because I thought the result would be a branch that is an exact copy
> > of the trunk, and thus has no "extra revision(s)".
> 
> Yes, after merge you did commit, therefore you have 1 extra revision (just committed).

I understand that, but that commit was because merge by itself does
not commit the changes I pulled from the mainline.  Without the
commit, bzr was even less happy.

I guess I expected to see nothing from "missing" after these
operations, since really the branch is an exact copy of the upstream.
Evidently, that's not "missing"'s logic and purpose.  "bzr diff" did
come up empty-handed, as expected.

> You may want to use `bzr merge --pull` to get equivalent of git fast-forward merge.
> merge --pull will pull new changes from other branch if possible, thus make your branch a copy of
> the other branch. Or it will do merge when 2 branches are diverged, i.e. both branches has new
> commits, not present in other branch.

I don't know git.  How is "merge --pull" different from merge followed
by commit? would it avoid the "1 extra revision" in the output of
"missing"?

Re: Strange response after merge from upstream

[Stefan Monnier]

>>>> The bzr repository in svannah is not auto-updated at all, AFAIK.  Is it?
>>> It's a manual process which I run once a day.
>> Interesting.  And the "new" repositories are "compatible" with the old
>> ones?  I thought such incremental updates of git->bzr conversions were
>> not possible with fast-import,
> This seems to answer your question:
> http://bazaar-vcs.org/BzrFastImport#Mirroring%20of%20Foreign%20Repositories
> OTOH, I just executed a `bzr pull' on my bzr branch created some days
> ago and got a pile of new revisions.

Cool, thanks,


        Stefan

Re: Strange response after merge from upstream

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

> I understand that, but that commit was because merge by itself does
> not commit the changes I pulled from the mainline.  Without the
> commit, bzr was even less happy.
>
> I guess I expected to see nothing from "missing" after these
> operations, since really the branch is an exact copy of the upstream.
> Evidently, that's not "missing"'s logic and purpose.  "bzr diff" did
> come up empty-handed, as expected.

On one branch you used `pull', which adds revisions on top of those you
previously had. So if you pulled 10 revisions, you have 10 more
revisions on the history of that branch.

On the other branch you merged the missing revisions and then you had to
commit the merge after resolving conflicts, if any. You end with 10
revisions coming from the parent branch plus one revision from your
commit totalling 11. If the source tree ends being indentical on both
cases, it is just by chance. Nothing prevents you from editing the files
before the post-merge commit.

The key here is that the final history of those branches allows them to
contain different working files, i.e. you can't guarantee that the
branches have not diverged looking at the set of revisions they contain
and how they arranged on its DAG. One branch has a revision that is
unknown by the other.

As you probably already know, each revision has a revision-id that makes
it unique and is used for checking its existence on a branch, no matter
if it was originated there or arrived via pull or merge. That two
branches ends containing the same source code is irrelevant if the
revisions they contain and their arrangement on the respective DAGs
makes the branches non-equivalent.

>> You may want to use `bzr merge --pull` to get equivalent of git
>> fast-forward merge.  merge --pull will pull new changes from other
>> branch if possible, thus make your branch a copy of the other
>> branch. Or it will do merge when 2 branches are diverged, i.e. both
>> branches has new commits, not present in other branch.
>
> I don't know git.  How is "merge --pull" different from merge followed
> by commit?

merge -pull does this:

if branches-diverged?
  yes: merge  (you need to explicitly commit afterwards)
  no : pull   (no need to commit)

> would it avoid the "1 extra revision" in the output of "missing"?

Yes, because your quickfixes/ branch did not diverged from the branch
you pulled from, so it will do a `pull', like you did on your trunk
branch.

-- 
Óscar

Re: Strange response after merge from upstream

[Eli Zaretskii]

> From: Óscar_Fuentes <ofv@wanadoo.es>
> Date: Wed, 02 Dec 2009 05:56:35 +0100
> 
> merge -pull does this:
> 
> if branches-diverged?
>   yes: merge  (you need to explicitly commit afterwards)
>   no : pull   (no need to commit)
> 
> > would it avoid the "1 extra revision" in the output of "missing"?
> 
> Yes, because your quickfixes/ branch did not diverged from the branch
> you pulled from, so it will do a `pull', like you did on your trunk
> branch.

Thanks, but it doesn't seem to work here: after "bzr pull" in trunk/
and "bzr merge --pull" in quickfixes/, "bzr missing" still says that I
"have 1 extra revision(s)" and cites the commit from yesterday.  That
could be understandable, but it also says I'm "missing 27 revision(s)"
and seems to show the changes just merged from the trunk.

Does this happen because of yesterday's "commit" after "merge"?  Do I
understand correctly that, to get rid of this, I need to "merge --pull"
all the way, and even a single "merge; commit" will force the branches
to diverge no matter what?  Is there a way of ``resyncing'' the branch
with the trunk, so that "bzr missing" shows no missing/extra
revisions?

Or did I do something wrong?

Re: Strange response after merge from upstream

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > How is "merge --pull" different from merge followed by commit? 
 > would it avoid the "1 extra revision" in the output of "missing"?

Maybe.

- "bzr merge" always merges, and you must commit.
- "bzr pull" does a trivial merge and commit if your local branch's
  tip revision is an ancestor of the remote revision, otherwise it
  aborts without changing anything.  (A successful pull is also called
  a "fast forward".)
- "bzr merge --pull" does the equivalent of "bzr pull" if possible,
  otherwise it does "bzr merge".  This means you will have to commit
  separately when your local branch contains unpushed changes even if
  you get a clean merge; only for a fast forward do you avoid the
  commit step.

The above assumes there are no uncommitted local changes.  If there
are, all of the above commands abort without doing anything.

Re: Strange response after merge from upstream

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> merge -pull does this:
>> 
>> if branches-diverged?
>>   yes: merge  (you need to explicitly commit afterwards)
>>   no : pull   (no need to commit)
>> 
>> > would it avoid the "1 extra revision" in the output of "missing"?
>> 
>> Yes, because your quickfixes/ branch did not diverged from the branch
>> you pulled from, so it will do a `pull', like you did on your trunk
>> branch.
>
> Thanks, but it doesn't seem to work here: after "bzr pull" in trunk/
> and "bzr merge --pull" in quickfixes/, "bzr missing" still says that I
> "have 1 extra revision(s)" and cites the commit from yesterday.  That
> could be understandable, but it also says I'm "missing 27 revision(s)"
> and seems to show the changes just merged from the trunk.
>
> Does this happen because of yesterday's "commit" after "merge"?

Yes, for the 1 extra revision. I don't know from where come the missing
27 revisions if you already merged those.

You can see the stuff you merged on the last commit on quickfixes/ with

bzr log -n1 -l30

(show one level of merge history, 30 commits maximum)

See if the revisions listed there are the same `bzr missing' lists.

> Do I understand correctly that, to get rid of this, I need to "merge
> --pull" all the way, and even a single "merge; commit" will force the
> branches to diverge no matter what?

Yes.

> Is there a way of ``resyncing'' the branch with the trunk, so that
> "bzr missing" shows no missing/extra revisions?

Omitting the "27 missing revisions" and going back to the scenario you
described on your original post, a solution for this is to push that
extra revision into trunk. It is not the right solution, though, if your
`trunk' branch is intended to be a mirror of upstream's `trunk'. Other
solution is to uncommit, if you didn't commited more stuff to
quickfixes/ :

bzr uncommit
bzr revert

A brute-force solution is to delete the quickfixes/ branch (`rm -rf
quickfixes/' will do fine) and create another with the same name. This
is acceptable as far as you have no useful local commits there, of
course.

> Or did I do something wrong?

It depends. Sometimes the right thing is to pull, sometimes you want to
merge. For your local mirror of upstream's trunk, you always want to
pull. For the rest of the branches, if you already have local commits,
`merge' is your only option. Once you send the local commits upstream,
you can pull again.

-- 
Óscar

Re: Strange response after merge from upstream

[Óscar Fuentes]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Eli Zaretskii writes:
>
>  > How is "merge --pull" different from merge followed by commit? 
>  > would it avoid the "1 extra revision" in the output of "missing"?
>
> Maybe.
>
> - "bzr merge" always merges, and you must commit.

Correct.

> - "bzr pull" does a trivial merge and commit if your local branch's
>   tip revision is an ancestor of the remote revision, otherwise it
>   aborts without changing anything.  (A successful pull is also called
>   a "fast forward".)

`pull' never merges because there is nothing that can cause
conflicts. The scenario where `pull' works is this:

my_mirror:  A B C D

upstream :  A B C D E F

After pull:

my_mirror:  A B C D E F

upstream :  A B C D E F

It is impossible to get a conflict here. It just adds the revisions to
the DAG. However, if you have something like this:

my_branch:  A B C D X

upstream :  A B C D E F

conflicts may arise and you must merge to obtain

my_branch:  A-B-C-D-X------M
                   \--E-F-/

upstream :  A B C D E F

M is the commit you make after the merge, aka the "merge point".

Even if the branches didn't diverged, a `merge' creates a different
graph than a `pull'. This is the state before the operations:

upstream :  A B C D E F

my_pull  :  A B C D

my_merge :  A B C D

This is after:

upstream :  A B C D E F

my_pull  :  A B C D E F

my_merge :  A-B-C-D-X------M
                   \--E-F-/

This is most obvious on the output of `bzr log'.

"fast forward" is git lingo.

[snip]

-- 
Óscar

Re: Strange response after merge from upstream

[Andreas Schwab]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Interesting.  And the "new" repositories are "compatible" with the old
> ones?  I thought such incremental updates of git->bzr conversions were
> not possible with fast-import,

Works fine with --{import,export}-marks.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Strange response after merge from upstream

[Eli Zaretskii]

> From: =?utf-8?Q?=C3=93scar_Fuentes?= <oscarfv@telefonica.net>
> Cc: Óscar_Fuentes <ofv@wanadoo.es>,  emacs-devel@gnu.org
> Date: Wed, 02 Dec 2009 07:26:06 +0100
> 
> > Is there a way of ``resyncing'' the branch with the trunk, so that
> > "bzr missing" shows no missing/extra revisions?
> 
> Omitting the "27 missing revisions" and going back to the scenario you
> described on your original post, a solution for this is to push that
> extra revision into trunk. It is not the right solution, though, if your
> `trunk' branch is intended to be a mirror of upstream's `trunk'. Other
> solution is to uncommit, if you didn't commited more stuff to
> quickfixes/ :
> 
> bzr uncommit
> bzr revert

Thanks, these two followed by "bzr merge --pull" seem to have solved
the issue.  I will use "merge --pull" from now on, as long as no
development goes on on quickfixes/, and see if it stays in sync.

> It depends. Sometimes the right thing is to pull, sometimes you want to
> merge. For your local mirror of upstream's trunk, you always want to
> pull. For the rest of the branches, if you already have local commits,
> `merge' is your only option. Once you send the local commits upstream,
> you can pull again.

Yes, I understand that much.  I was just surprised to see what sounded
like a branch that only ever merged from the trunk and had no changes
whatsoever would appear as having some changes wrt that trunk.

Re: Strange response after merge from upstream

[Stefan Monnier]

> `pull' never merges because there is nothing that can cause conflicts.

Oh, so that's the misconception from which comes the stupid idea
that --show-base would only apply to merge but not to pull?

FYI, this is not true: it has to merge the incoming patches with the
local uncommitted changes.


        Stefan

Re: Strange response after merge from upstream

[Stefan Monnier]

> Thanks, these two followed by "bzr merge --pull" seem to have solved
> the issue.  I will use "merge --pull" from now on, as long as no
> development goes on on quickfixes/, and see if it stays in sync.

If the branch ever diverges, you won't be able to use `pull' again until
you `push' that branch's changes upstream.


        Stefan

Re: Strange response after merge from upstream

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: =?iso-8859-1?Q?=D3scar?= Fuentes <oscarfv@telefonica.net>,
>   ofv@wanadoo.es,  emacs-devel@gnu.org
> Date: Wed, 02 Dec 2009 09:31:06 -0500
> 
> > Thanks, these two followed by "bzr merge --pull" seem to have solved
> > the issue.  I will use "merge --pull" from now on, as long as no
> > development goes on on quickfixes/, and see if it stays in sync.
> 
> If the branch ever diverges, you won't be able to use `pull' again until
> you `push' that branch's changes upstream.

Yes, of course.  But then I won't be surprised ;-)

Re: Strange response after merge from upstream

[Óscar Fuentes]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> `pull' never merges because there is nothing that can cause conflicts.
>
> Oh, so that's the misconception from which comes the stupid idea
> that --show-base would only apply to merge but not to pull?
>
> FYI, this is not true: it has to merge the incoming patches with the
> local uncommitted changes.

Yes, IMO that feature is so wrong that I forgot about it.

By default, `pull' should refuse to operate if there are local edited
files. If you often work on that scenario, you'll better use a bound
branch and `update' instead of `pull'.

-- 
Óscar

Re: Strange response after merge from upstream

[Alexander Belchenko]

Óscar Fuentes пишет:
> "Stephen J. Turnbull" <stephen@xemacs.org> writes:
> 
>> Eli Zaretskii writes:
>>
>>  > How is "merge --pull" different from merge followed by commit? 
>>  > would it avoid the "1 extra revision" in the output of "missing"?
>>
>> Maybe.
>>
>> - "bzr merge" always merges, and you must commit.
> 
> Correct.
> 
>> - "bzr pull" does a trivial merge and commit if your local branch's
>>   tip revision is an ancestor of the remote revision, otherwise it
>>   aborts without changing anything.  (A successful pull is also called
>>   a "fast forward".)
> 
> `pull' never merges because there is nothing that can cause
> conflicts.

It's not quite true. If you have uncommitted yet changes in your branch, and you do pull from other
branch, then pull will merge your uncommitted changes with pulled changes, and thus could create
conflict. Something like running `cvs update` when you have some changes in the tree.

Re: Strange response after merge from upstream

[Stefan Monnier]

>>> `pull' never merges because there is nothing that can cause conflicts.
>> 
>> Oh, so that's the misconception from which comes the stupid idea
>> that --show-base would only apply to merge but not to pull?
>> 
>> FYI, this is not true: it has to merge the incoming patches with the
>> local uncommitted changes.

> Yes, IMO that feature is so wrong that I forgot about it.

> By default, `pull' should refuse to operate if there are local edited
> files. If you often work on that scenario, you'll better use a bound
> branch and `update' instead of `pull'.

Yes, well, that's indeed my situation, and my branch is bound and I use
`update', tho I also use `pull' because it makes no difference.
The problem is still the same: it doesn't take a --show-base argument.


        Stefan