all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Strange response after merge from upstream
@ 2009-12-01 19:20 Eli Zaretskii
  2009-12-01 22:04 ` Stefan Monnier
  2009-12-01 22:23 ` Alexander Belchenko
  0 siblings, 2 replies; 21+ messages in thread
From: Eli Zaretskii @ 2009-12-01 19:20 UTC (permalink / raw)
  To: emacs-devel

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)".




^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Strange response after merge from upstream
  2009-12-01 19:20 Strange response after merge from upstream Eli Zaretskii
@ 2009-12-01 22:04 ` Stefan Monnier
  2009-12-01 22:21   ` Andreas Schwab
  2009-12-01 22:23 ` Alexander Belchenko
  1 sibling, 1 reply; 21+ messages in thread
From: Stefan Monnier @ 2009-12-01 22:04 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

> 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





^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Strange response after merge from upstream
  2009-12-01 22:04 ` Stefan Monnier
@ 2009-12-01 22:21   ` Andreas Schwab
  2009-12-02  1:54     ` Stefan Monnier
  0 siblings, 1 reply; 21+ messages in thread
From: Andreas Schwab @ 2009-12-01 22:21 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Eli Zaretskii, emacs-devel

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."




^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Strange response after merge from upstream
  2009-12-01 19:20 Strange response after merge from upstream Eli Zaretskii
  2009-12-01 22:04 ` Stefan Monnier
@ 2009-12-01 22:23 ` Alexander Belchenko
  2009-12-02  4:15   ` Eli Zaretskii
  1 sibling, 1 reply; 21+ messages in thread
From: Alexander Belchenko @ 2009-12-01 22:23 UTC (permalink / raw)
  To: emacs-devel

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.





^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Strange response after merge from upstream
  2009-12-01 22:21   ` Andreas Schwab
@ 2009-12-02  1:54     ` Stefan Monnier
  2009-12-02  2:09       ` Óscar Fuentes
  2009-12-02 10:48       ` Andreas Schwab
  0 siblings, 2 replies; 21+ messages in thread
From: Stefan Monnier @ 2009-12-02  1:54 UTC (permalink / raw)
  To: Andreas Schwab; +Cc: Eli Zaretskii, emacs-devel

>> 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




^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Strange response after merge from upstream
  2009-12-02  1:54     ` Stefan Monnier
@ 2009-12-02  2:09       ` Óscar Fuentes
  2009-12-02  4:29         ` Stefan Monnier
  2009-12-02 10:48       ` Andreas Schwab
  1 sibling, 1 reply; 21+ messages in thread
From: Óscar Fuentes @ 2009-12-02  2:09 UTC (permalink / raw)
  To: emacs-devel

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





^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Strange response after merge from upstream
  2009-12-01 22:23 ` Alexander Belchenko
@ 2009-12-02  4:15   ` Eli Zaretskii
  2009-12-02  4:56     ` Óscar Fuentes
  2009-12-02  6:14     ` Stephen J. Turnbull
  0 siblings, 2 replies; 21+ messages in thread
From: Eli Zaretskii @ 2009-12-02  4:15 UTC (permalink / raw)
  To: Alexander Belchenko; +Cc: emacs-devel

> 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"?





^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Strange response after merge from upstream
  2009-12-02  2:09       ` Óscar Fuentes
@ 2009-12-02  4:29         ` Stefan Monnier
  0 siblings, 0 replies; 21+ messages in thread
From: Stefan Monnier @ 2009-12-02  4:29 UTC (permalink / raw)
  To: Óscar Fuentes; +Cc: emacs-devel

>>>> 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




^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Strange response after merge from upstream
  2009-12-02  4:15   ` Eli Zaretskii
@ 2009-12-02  4:56     ` Óscar Fuentes
  2009-12-02  5:58       ` Eli Zaretskii
  2009-12-02  6:14     ` Stephen J. Turnbull
  1 sibling, 1 reply; 21+ messages in thread
From: Óscar Fuentes @ 2009-12-02  4:56 UTC (permalink / raw)
  To: emacs-devel

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





^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Strange response after merge from upstream
  2009-12-02  4:56     ` Óscar Fuentes
@ 2009-12-02  5:58       ` Eli Zaretskii
  2009-12-02  6:26         ` Óscar Fuentes
  0 siblings, 1 reply; 21+ messages in thread
From: Eli Zaretskii @ 2009-12-02  5:58 UTC (permalink / raw)
  To: Óscar Fuentes; +Cc: emacs-devel

> 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?




^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Strange response after merge from upstream
  2009-12-02  4:15   ` Eli Zaretskii
  2009-12-02  4:56     ` Óscar Fuentes
@ 2009-12-02  6:14     ` Stephen J. Turnbull
  2009-12-02  7:05       ` Óscar Fuentes
  1 sibling, 1 reply; 21+ messages in thread
From: Stephen J. Turnbull @ 2009-12-02  6:14 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Alexander Belchenko, emacs-devel

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.




^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Strange response after merge from upstream
  2009-12-02  5:58       ` Eli Zaretskii
@ 2009-12-02  6:26         ` Óscar Fuentes
  2009-12-02 10:53           ` Eli Zaretskii
  0 siblings, 1 reply; 21+ messages in thread
From: Óscar Fuentes @ 2009-12-02  6:26 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Óscar Fuentes, emacs-devel

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




^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Strange response after merge from upstream
  2009-12-02  6:14     ` Stephen J. Turnbull
@ 2009-12-02  7:05       ` Óscar Fuentes
  2009-12-02 14:29         ` Stefan Monnier
  2009-12-02 17:55         ` Alexander Belchenko
  0 siblings, 2 replies; 21+ messages in thread
From: Óscar Fuentes @ 2009-12-02  7:05 UTC (permalink / raw)
  To: emacs-devel

"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





^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Strange response after merge from upstream
  2009-12-02  1:54     ` Stefan Monnier
  2009-12-02  2:09       ` Óscar Fuentes
@ 2009-12-02 10:48       ` Andreas Schwab
  1 sibling, 0 replies; 21+ messages in thread
From: Andreas Schwab @ 2009-12-02 10:48 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Eli Zaretskii, emacs-devel

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."




^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Strange response after merge from upstream
  2009-12-02  6:26         ` Óscar Fuentes
@ 2009-12-02 10:53           ` Eli Zaretskii
  2009-12-02 14:31             ` Stefan Monnier
  0 siblings, 1 reply; 21+ messages in thread
From: Eli Zaretskii @ 2009-12-02 10:53 UTC (permalink / raw)
  To: Óscar Fuentes; +Cc: ofv, emacs-devel

> 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.




^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Strange response after merge from upstream
  2009-12-02  7:05       ` Óscar Fuentes
@ 2009-12-02 14:29         ` Stefan Monnier
  2009-12-02 17:44           ` Óscar Fuentes
  2009-12-02 17:55         ` Alexander Belchenko
  1 sibling, 1 reply; 21+ messages in thread
From: Stefan Monnier @ 2009-12-02 14:29 UTC (permalink / raw)
  To: Óscar Fuentes; +Cc: emacs-devel

> `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




^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Strange response after merge from upstream
  2009-12-02 10:53           ` Eli Zaretskii
@ 2009-12-02 14:31             ` Stefan Monnier
  2009-12-02 17:40               ` Eli Zaretskii
  0 siblings, 1 reply; 21+ messages in thread
From: Stefan Monnier @ 2009-12-02 14:31 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: ofv, Óscar Fuentes, emacs-devel

> 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




^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Strange response after merge from upstream
  2009-12-02 14:31             ` Stefan Monnier
@ 2009-12-02 17:40               ` Eli Zaretskii
  0 siblings, 0 replies; 21+ messages in thread
From: Eli Zaretskii @ 2009-12-02 17:40 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: ofv, oscarfv, emacs-devel

> 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 ;-)




^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Strange response after merge from upstream
  2009-12-02 14:29         ` Stefan Monnier
@ 2009-12-02 17:44           ` Óscar Fuentes
  2009-12-02 19:37             ` Stefan Monnier
  0 siblings, 1 reply; 21+ messages in thread
From: Óscar Fuentes @ 2009-12-02 17:44 UTC (permalink / raw)
  To: emacs-devel

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





^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Strange response after merge from upstream
  2009-12-02  7:05       ` Óscar Fuentes
  2009-12-02 14:29         ` Stefan Monnier
@ 2009-12-02 17:55         ` Alexander Belchenko
  1 sibling, 0 replies; 21+ messages in thread
From: Alexander Belchenko @ 2009-12-02 17:55 UTC (permalink / raw)
  To: emacs-devel

Ó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.





^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Strange response after merge from upstream
  2009-12-02 17:44           ` Óscar Fuentes
@ 2009-12-02 19:37             ` Stefan Monnier
  0 siblings, 0 replies; 21+ messages in thread
From: Stefan Monnier @ 2009-12-02 19:37 UTC (permalink / raw)
  To: Óscar Fuentes; +Cc: emacs-devel

>>> `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




^ permalink raw reply	[flat|nested] 21+ messages in thread

end of thread, other threads:[~2009-12-02 19:37 UTC | newest]

Thread overview: 21+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-12-01 19:20 Strange response after merge from upstream Eli Zaretskii
2009-12-01 22:04 ` Stefan Monnier
2009-12-01 22:21   ` Andreas Schwab
2009-12-02  1:54     ` Stefan Monnier
2009-12-02  2:09       ` Óscar Fuentes
2009-12-02  4:29         ` Stefan Monnier
2009-12-02 10:48       ` Andreas Schwab
2009-12-01 22:23 ` Alexander Belchenko
2009-12-02  4:15   ` Eli Zaretskii
2009-12-02  4:56     ` Óscar Fuentes
2009-12-02  5:58       ` Eli Zaretskii
2009-12-02  6:26         ` Óscar Fuentes
2009-12-02 10:53           ` Eli Zaretskii
2009-12-02 14:31             ` Stefan Monnier
2009-12-02 17:40               ` Eli Zaretskii
2009-12-02  6:14     ` Stephen J. Turnbull
2009-12-02  7:05       ` Óscar Fuentes
2009-12-02 14:29         ` Stefan Monnier
2009-12-02 17:44           ` Óscar Fuentes
2009-12-02 19:37             ` Stefan Monnier
2009-12-02 17:55         ` Alexander Belchenko

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.