unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Óscar Fuentes" <oscarfv@telefonica.net>
To: Eli Zaretskii <eliz@gnu.org>
Cc: "Óscar Fuentes" <ofv@wanadoo.es>, emacs-devel@gnu.org
Subject: Re: Strange response after merge from upstream
Date: Wed, 02 Dec 2009 07:26:06 +0100	[thread overview]
Message-ID: <87y6ll51tt.fsf@telefonica.net> (raw)
In-Reply-To: <E1NFiEV-0001DH-0v@fencepost.gnu.org> (Eli Zaretskii's message of "Wed, 02 Dec 2009 00:58:35 -0500")

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




  reply	other threads:[~2009-12-02  6:26 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87y6ll51tt.fsf@telefonica.net \
    --to=oscarfv@telefonica.net \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=ofv@wanadoo.es \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).