merge conlict?

merge conlict?

[Eli Zaretskii]

> Date: Sun, 24 Jan 2010 23:52:26 -0500
> From: "Mark A. Hershberger" <mhershberger@intrahealth.org>
> To: emacs-diffs@gnu.org
> Subject: [Emacs-diffs] /srv/bzr/emacs/trunk r99379: merge conflict
> Content-Type: text/plain; charset="us-ascii"
> 
> ------------------------------------------------------------
> revno: 99379 [merge]
> committer: Mark A. Hershberger <mhershberger@intrahealth.org>
> branch nick: trunk
> timestamp: Sun 2010-01-24 23:52:26 -0500
> message:
>   merge conflict

What does this "merge conflict" in the commit message mean?  Why do
so many unrelated files (see below) seem to be modified in one go?

> removed:
>   admin/revdiff
> modified:
>   .bzrignore
>   ChangeLog
>   admin/ChangeLog
>   admin/notes/bugtracker
>   configure
>   configure.in
>   doc/emacs/ChangeLog
>   doc/emacs/trouble.texi
>   doc/misc/ChangeLog
>   doc/misc/gnus.texi
>   etc/NEWS
>   lisp/ChangeLog
>   lisp/dired-aux.el
>   lisp/dired.el
>   lisp/emacs-lisp/advice.el
>   lisp/emacs-lisp/assoc.el
>   lisp/indent.el
>   lisp/isearch.el
>   lisp/jka-compr.el
>   lisp/mail/mail-utils.el
>   lisp/mail/rmail.el
>   lisp/mail/rmailmm.el
>   lisp/net/tramp-imap.el
>   lisp/net/tramp-smb.el
>   lisp/progmodes/ada-mode.el
>   lisp/progmodes/cc-defs.el
>   lisp/progmodes/cc-engine.el
>   lisp/term.el
>   lisp/term/xterm.el
>   lisp/textmodes/sgml-mode.el
>   lisp/url/ChangeLog
>   lisp/url/url-util.el
>   lisp/vc-git.el
>   src/ChangeLog
>   src/alloc.c
>   src/coding.c
>   src/filelock.c
>   src/image.c
>   src/keymap.c
>   src/lisp.h
>   src/lread.c
>   src/xdisp.c

Re: merge conlict?

[Glenn Morris]

Eli Zaretskii wrote:

> What does this "merge conflict" in the commit message mean?  Why do
> so many unrelated files (see below) seem to be modified in one go?

I'm confused by this too.

The actual diffs seem to be a lot of recent changes being applied for
a second time. I could understand if there was a message where they
got unapplied first by mistake. But how can the same changes get
applied twice to the trunk?

Also, each of revs 99378-99381 now appears twice, referring to a
different change each time. Eg these are both r99379:

http://lists.gnu.org/archive/html/emacs-diffs/2010-01/msg00146.html
http://lists.gnu.org/archive/html/emacs-diffs/2010-01/msg00106.html

Is this how it supposed to work?

Re: merge conlict?

[Eli Zaretskii]

> Cc: "Mark A. Hershberger" <mhershberger@intrahealth.org>,  emacs-devel@gnu.org
> From: Glenn Morris <rgm@gnu.org>
> Date: Mon, 25 Jan 2010 03:46:51 -0500
> 
> The actual diffs seem to be a lot of recent changes being applied for
> a second time. I could understand if there was a message where they
> got unapplied first by mistake. But how can the same changes get
> applied twice to the trunk?

They are not actually applied twice, as far as the history is
concerned.  Try "bzr log -l100 -n0 --line": you will see them only
once.  But they do appear to be results of Mark's commit, which I
think is incorrect.  Or maybe I'm misinterpreting what "bzr log"
shows.

> Also, each of revs 99378-99381 now appears twice, referring to a
> different change each time. Eg these are both r99379:
> 
> http://lists.gnu.org/archive/html/emacs-diffs/2010-01/msg00146.html
> http://lists.gnu.org/archive/html/emacs-diffs/2010-01/msg00106.html

That might be a problem with the script that mails diffs upon
commits.  Or maybe it just does not show enough information, because
evidently the original commits (by Stefen, Yidong, Dan, yourself etc.)
got moved in the DAG from the mainline to a branch merge (again, if my
interpretation of the log is correct).

> Is this how it supposed to work?

I don't think so.  I suspect some local snafu on Mark's machine, with
a subsequent fix that caused this strange history.  Mark, can you
enlighten us, please?

(Btw, mhershberger@intrahealth.org bounces.)

NEVER use `bzr push' for sending changes upstream (was: merge conlict?)

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

[snip]

> (Btw, mhershberger@intrahealth.org bounces.)

Mark did "merge & push" twice, so it is very likely that that is his
usual workflow. It is *very* damaging for the VC history.

If Mark can't be contacted for telling him to correct his bzr workflow,
his commit rights should be removed. Hopefully he will come here to ask
why he can't commit and then we will explain the problem to him.

Re: NEVER use `bzr push' for sending changes upstream

[Mark A. Hershberger]

Óscar Fuentes <ofv@wanadoo.es> writes:

>> (Btw, mhershberger@intrahealth.org bounces.)

I'll fix that.  “bzr whoami” to the rescue.


> Mark did "merge & push" twice, so it is very likely that that is his
> usual workflow. It is *very* damaging for the VC history.

Appologies.  I'll make any changes suggested in this thread.  I didn't
intend to commit twice.  I got confused by the second conflict.


-- 
http://hexmode.com/

The only alternative to Tradition is bad tradition.
                          — Jaraslov Pelikan

Re: NEVER use `bzr push' for sending changes upstream

[Óscar Fuentes]

mah@everybody.org (Mark A. Hershberger) writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>>> (Btw, mhershberger@intrahealth.org bounces.)
>
> I'll fix that.  “bzr whoami” to the rescue.
>
>
>> Mark did "merge & push" twice, so it is very likely that that is his
>> usual workflow. It is *very* damaging for the VC history.
>
> Appologies.  I'll make any changes suggested in this thread.  I didn't
> intend to commit twice.  I got confused by the second conflict.

Hello Mark.

If there is a reason for not following the worflow described in

http://www.emacswiki.org/emacs/BzrForEmacsDevs

or if you misunderstood something, please describe what's wrong for you
and we'll try to fix it.

Re: merge conlict?

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Sun, 24 Jan 2010 23:52:26 -0500
>> From: "Mark A. Hershberger" <mhershberger@intrahealth.org>
>> To: emacs-diffs@gnu.org
>> Subject: [Emacs-diffs] /srv/bzr/emacs/trunk r99379: merge conflict
>> Content-Type: text/plain; charset="us-ascii"
>> 
>> ------------------------------------------------------------
>> revno: 99379 [merge]
>> committer: Mark A. Hershberger <mhershberger@intrahealth.org>
>> branch nick: trunk
>> timestamp: Sun 2010-01-24 23:52:26 -0500
>> message:
>>   merge conflict
>
> What does this "merge conflict" in the commit message mean?  Why do
> so many unrelated files (see below) seem to be modified in one go?

That's a normal merge of trunk into a branch.  Not much different from
eg. yamaoka@jpl.org-20100121085911-ix6bp10z930y7zn8.

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: merge conlict?

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Date: Mon, 25 Jan 2010 10:26:24 +0100
> Cc: "Mark A. Hershberger" <mhershberger@intrahealth.org>, emacs-devel@gnu.org
> 
> >> revno: 99379 [merge]
> >> committer: Mark A. Hershberger <mhershberger@intrahealth.org>
> >> branch nick: trunk
> >> timestamp: Sun 2010-01-24 23:52:26 -0500
> >> message:
> >>   merge conflict
> >
> > What does this "merge conflict" in the commit message mean?  Why do
> > so many unrelated files (see below) seem to be modified in one go?
> 
> That's a normal merge of trunk into a branch.

Yes, but the "merge conflict" commit message bears some meaning that I
hope Mark will be able to explain.  Obviously, that meaning is not
something Bazaar would know about, or care.

> Not much different from
> eg. yamaoka@jpl.org-20100121085911-ix6bp10z930y7zn8.

That merge is made of Katsumi Yamaoka's changes.  Which is not true
for Mark's merge.  Thus my questions above.

Re: merge conlict?

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

>> Not much different from
>> eg. yamaoka@jpl.org-20100121085911-ix6bp10z930y7zn8.
>
> That merge is made of Katsumi Yamaoka's changes.

I don't understand that sentence.  Can you clarify?

> Which is not true for Mark's merge.

Both commits merge trunk into a branch.  How are they different?

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: merge conlict?

[Óscar Fuentes]

Andreas Schwab <schwab@linux-m68k.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> Not much different from
>>> eg. yamaoka@jpl.org-20100121085911-ix6bp10z930y7zn8.
>>
>> That merge is made of Katsumi Yamaoka's changes.
>
> I don't understand that sentence.  Can you clarify?
>
>> Which is not true for Mark's merge.
>
> Both commits merge trunk into a branch.  How are they different?

Katsumi Yamaoka merges his changes into trunk, which is the normal
practice.

If my guess is right, Mark merged trunk into his private branch, and
then pushed to upstream, which is very wrong.

Re: merge conlict?

[Andreas Schwab]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Andreas Schwab <schwab@linux-m68k.org> writes:
>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>>>> Not much different from
>>>> eg. yamaoka@jpl.org-20100121085911-ix6bp10z930y7zn8.
>>>
>>> That merge is made of Katsumi Yamaoka's changes.
>>
>> I don't understand that sentence.  Can you clarify?
>>
>>> Which is not true for Mark's merge.
>>
>> Both commits merge trunk into a branch.  How are they different?
>
> Katsumi Yamaoka merges his changes into trunk,

No, it merges trunk into a branch.

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: merge conlict?

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Date: Mon, 25 Jan 2010 12:06:01 +0100
> Cc: emacs-devel@gnu.org
> 
> Óscar Fuentes <ofv@wanadoo.es> writes:
> 
> > Katsumi Yamaoka merges his changes into trunk,
> 
> No, it merges trunk into a branch.

Look, Andreas, if you want to help in understanding what, if anything,
is wrong with Mark's commit, please tell that in enough words that
mere mortals can understand.  Otherwise, you are just raising the
noise level, so please leave us alone in this thread and let us find
out the truth our way.  Okay?

Re: merge conlict?

[Óscar Fuentes]

Andreas Schwab <schwab@linux-m68k.org> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> Andreas Schwab <schwab@linux-m68k.org> writes:
>>
>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>
>>>>> Not much different from
>>>>> eg. yamaoka@jpl.org-20100121085911-ix6bp10z930y7zn8.
>>>>
>>>> That merge is made of Katsumi Yamaoka's changes.
>>>
>>> I don't understand that sentence.  Can you clarify?
>>>
>>>> Which is not true for Mark's merge.
>>>
>>> Both commits merge trunk into a branch.  How are they different?
>>
>> Katsumi Yamaoka merges his changes into trunk,
>
> No, it merges trunk into a branch.

That's right for the specific revid you mention. But what matters here
is the effect on trunk's history. Katsumi Yamaoka's merge was merged
back into trunk and it was incorporated as merged history. You can't see
it unless you explictly ask for the merged history. It does not cause
huge diffs, nor large lists of modified files. It is the result of

somebranch $ bzr merge ../trunk
somebranch $ bzr commit
somebranch $ bzr merge ../trunk
somebranch $ bzr commit
somebranch $ bzr merge ../trunk
somebranch $ bzr commit
  < some more repetitions elided >
  <hack something>
somebranch $ bzr commit
somebranch $ cd ../trunk
trunk $ bzr merge ../somebranch
trunk $ bzr commit

which is precisely what he wiki documentation describes. You have a
number of merge commits hiddend in the merged history, but diffs are
fine and only the files edited by the committer are marked as modified
by the change.

OTOH, Mark looks like more

somebranch $ bzr merge URL_TO_UPSTREAM_TRUNK
somebranch $ bzr commit
somebranch $ bzr push URL_TO_UPSTREAM_TRUNK

which causes havoc.

Re: merge conlict?

[Teemu Likonen]

On 2010-01-25 12:27 (+0100), Óscar Fuentes wrote:

> OTOH, Mark looks like more
>
> somebranch $ bzr merge URL_TO_UPSTREAM_TRUNK
> somebranch $ bzr commit
> somebranch $ bzr push URL_TO_UPSTREAM_TRUNK
>
> which causes havoc.

Let's visualize:

    * 0bbf36b (vc-annotate-revision-at-line): Compare
    *   fe8377b * xfns.c (Fx_create_frame): If frame
    |\
    | *   9e63631 Merge from trunk
    | |\
    | |/
    |/|
    * | 7f598d9 (vc-bzr-print-log): Use the more comp
    * |   145ad3a merge
    |\ \
    | * | b1ecfe3 (vc-git-dir-status-goto-stage): Pas
    * | | ddf9279 working version of vc-bzr-revision-

    ^-- This line is the official branch (aka "trunk") after Mark's
        merge-commit-push.

Ok, moving further back in time. The merge in question is the asterisk
below:

    * | |   b8de0d6 merge conflict
    |\ \ \
    | |/ /
    | * |   49a939e Try and fix bug#788, hopefully fo
    | |\ \
    | | * | 85738d0 * keymap.c (shadow_lookup): Add `
    | * | | e0b7353 Use png_sig_cmp to allow linking
    | * | | cabf561 Remove support for adding --signo
    | * | | 2e23485 (xterm-maybe-set-dark-background-

    ^ ^- This is the official branch (aka "trunk").
     \
       This is Mark's personal branch.

Well, technically nothing bad has happened. It's a social question if
it's important to always have the trunk the first parent.

Re: merge conlict?

[Óscar Fuentes]

Teemu Likonen <tlikonen@iki.fi> writes:

> On 2010-01-25 12:27 (+0100), Óscar Fuentes wrote:
>
>> OTOH, Mark looks like more
>>
>> somebranch $ bzr merge URL_TO_UPSTREAM_TRUNK
>> somebranch $ bzr commit
>> somebranch $ bzr push URL_TO_UPSTREAM_TRUNK
>>
>> which causes havoc.
>
> Let's visualize:

I was going to do that. Thanks for saving me the ASCII art. I abhor
doing any kind of visual art :-)

You can view the branch diagram with `bzr qlog'. You need the qbzr
plugin, which is included on most bzr installers and distro
repositories.

[snip]

> Well, technically nothing bad has happened.

Unless you take the "technically" part as "no code was lost", I beg to
differ. A simple `bzr log' will show that the commits of the last few
days are gone from the listing. You need to add the `-n2' parameter to
see them as merged history under Mark's commit. Ideally, you shouldn't
need to look at the merged history except for "serious" branches. Do a
`bzr log -n2' and see how much uninteresting stuff you get. So now part
of the important stuff was moved to the same level as the uninteresting
stuff.

Oh, and apart from this problem and producing a huge diff, it breaks
bisection.

> It's a social question if it's important to always have the trunk the
> first parent.

As you said on a previous message, for bzr it is important to
differentiate the left-most part of the history. The writers of the
BzrForEmacsDevs wiki page were very careful about this point when they
wrote the workflow description.

Re: merge conlict?

[Andreas Schwab]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Unless you take the "technically" part as "no code was lost", I beg to
> differ. A simple `bzr log' will show that the commits of the last few
> days are gone from the listing. You need to add the `-n2' parameter to
> see them as merged history under Mark's commit.

That's only a UI problem.  There is nothing lost in terms of history.

> Oh, and apart from this problem and producing a huge diff, it breaks
> bisection.

How?

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: merge conlict?

[Óscar Fuentes]

Andreas Schwab <schwab@linux-m68k.org> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> Unless you take the "technically" part as "no code was lost", I beg to
>> differ. A simple `bzr log' will show that the commits of the last few
>> days are gone from the listing. You need to add the `-n2' parameter to
>> see them as merged history under Mark's commit.
>
> That's only a UI problem.

A UI problem can be very serious. This one is.

>  There is nothing lost in terms of history.

Right, but the history now is confusing: seems like a number of
revisions for several people came from Mark's branch.

>> Oh, and apart from this problem and producing a huge diff, it breaks
>> bisection.
>
> How?

While bisecting the DAG, either you remain on the left-most part, and
then those revisions are ignored, or traverse the merged history too,
and then you take into account lots of revisions which were intermediate
local points on the development of some feature.

Think how this affects to "find the revision that broke the build."

Re: merge conlict?

[Andreas Schwab]

Óscar Fuentes <ofv@wanadoo.es> writes:

> While bisecting the DAG, either you remain on the left-most part, and
> then those revisions are ignored, or traverse the merged history too,
> and then you take into account lots of revisions which were intermediate
> local points on the development of some feature.

Bisection must always take all parents into account.  Otherwise how can
it find out the exact revision?

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: merge conlict?

[Óscar Fuentes]

Andreas Schwab <schwab@linux-m68k.org> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> While bisecting the DAG, either you remain on the left-most part, and
>> then those revisions are ignored, or traverse the merged history too,
>> and then you take into account lots of revisions which were intermediate
>> local points on the development of some feature.
>
> Bisection must always take all parents into account.  Otherwise how can
> it find out the exact revision?

It seems you are thinking too git'ly

For emacs purposes, you are interested on knowing *who* broke the build
and *when* he incorporated the faulty change into upstream's trunk. For
that, it is enough with traversing the left-most part of the DAG (unless
someone turns the left-most part of his personal branch into the
left-most part of upstream trunk, but this shall not happen)

OTOH, there is no guarantee nor requirement that every revision merged
into trunk meet some quality standards, so traversing those merged
revisions is pretty useless.

Re: merge conlict?

[Andreas Schwab]

Óscar Fuentes <ofv@wanadoo.es> writes:

> It seems you are thinking too git'ly

I'm speaking from experience.

> For emacs purposes, you are interested on knowing *who* broke the build
> and *when* he incorporated the faulty change into upstream's trunk.

It seems pretty useless if cannot find out which revision of a big merge
is to blame.

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: merge conlict?

[Óscar Fuentes]

Andreas Schwab <schwab@linux-m68k.org> writes:

>> For emacs purposes, you are interested on knowing *who* broke the build
>> and *when* he incorporated the faulty change into upstream's trunk.
>
> It seems pretty useless if cannot find out which revision of a big merge
> is to blame.

The idea is to be able to say "Joe's revision X broke the build" and
then is Joe's bussiness to determine which of the revisions he merged on
the revision X broke the build.

There is no concept of "big merge" on bzr. (nor on git, AFAIK) So either
you include the merged revisions and cope with unstable intermediate
points or you ignore them, locate the merge point where the problem was
introduced on mainline, and then proceed to bisect the branch that
originated that merge point.

Re: merge conlict?

[Andreas Schwab]

Óscar Fuentes <ofv@wanadoo.es> writes:

> There is no concept of "big merge" on bzr. (nor on git, AFAIK)

If you merge a long development branch, then that's a big merge.

> So either you include the merged revisions and cope with unstable
> intermediate points or you ignore them, locate the merge point where
> the problem was introduced on mainline, and then proceed to bisect the
> branch that originated that merge point.

That's exactly what bisect does, automagically.  If you are careful with
your history, then this just works.

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: merge conlict?

[Óscar Fuentes]

Andreas Schwab <schwab@linux-m68k.org> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> There is no concept of "big merge" on bzr. (nor on git, AFAIK)
>
> If you merge a long development branch, then that's a big merge.

You know, I know, but how bzr knows?

>> So either you include the merged revisions and cope with unstable
>> intermediate points or you ignore them, locate the merge point where
>> the problem was introduced on mainline, and then proceed to bisect the
>> branch that originated that merge point.
>
> That's exactly what bisect does, automagically.  If you are careful with
> your history, then this just works.

"being careful with you history" means not committing things to local
branches that you wouldn't commit directly to trunk? I think such policy
would be counterproductive, but we already discussed this point on the
past.

Re: merge conlict?

[Andreas Schwab]

Óscar Fuentes <ofv@wanadoo.es> writes:

> You know, I know, but how bzr knows?

??? What does this have to do with bzr?

> "being careful with you history" means not committing things to local
> branches that you wouldn't commit directly to trunk? I think such policy
> would be counterproductive,

It is of great value to make your revisions bisectable.  Again, I'm
speaking from experience.

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: merge conlict?

[Óscar Fuentes]

Andreas Schwab <schwab@linux-m68k.org> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> You know, I know, but how bzr knows?
>
> ??? What does this have to do with bzr?

Read again the thread.

>> "being careful with you history" means not committing things to local
>> branches that you wouldn't commit directly to trunk? I think such policy
>> would be counterproductive,
>
> It is of great value to make your revisions bisectable.  Again, I'm
> speaking from experience.

I do "bisect" maybe twice per year. I commit hundreds of times. Guess
what's more convenient for me.

Re: merge conlict?

[Andreas Schwab]

Óscar Fuentes <ofv@wanadoo.es> writes:

> I do "bisect" maybe twice per year. I commit hundreds of times. Guess
> what's more convenient for me.

What is more convenient for the community?

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: merge conlict?

[Óscar Fuentes]

Andreas Schwab <schwab@linux-m68k.org> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> I do "bisect" maybe twice per year. I commit hundreds of times. Guess
>> what's more convenient for me.
>
> What is more convenient for the community?

For Emacs, I'm pretty sure that it is more convenient to have looser
requirements for committing into private branches than to be able to
bisect into merged history.

Please note that it is not a question of bisect or not bisect. It is
always possible to bisect following the leftmost part of the history (as
long as people do not get accustomed to push their changes onto trunk
and break that) and it is possible to re-create the original branch and
bisect it.

Re: merge conlict?

[Andreas Schwab]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Please note that it is not a question of bisect or not bisect. It is
> always possible to bisect following the leftmost part of the history (as
> long as people do not get accustomed to push their changes onto trunk
> and break that) and it is possible to re-create the original branch and
> bisect it.

That does not help if the bug is buried in the other part.

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: merge conlict?

[Óscar Fuentes]

Andreas Schwab <schwab@linux-m68k.org> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> Please note that it is not a question of bisect or not bisect. It is
>> always possible to bisect following the leftmost part of the history (as
>> long as people do not get accustomed to push their changes onto trunk
>> and break that) and it is possible to re-create the original branch and
>> bisect it.
>
> That does not help if the bug is buried in the other part.

Of course it helps. Do you imply that if the bug was introduced by a
merged revision it will go unnoticed? Bisecting mainline will pinpoint
which merge revision introduced the problem. Then, if the merged history
is long enough, the merged branch is recreated and bisect executed
there. Maybe not as convenient as doing it on a single pass, but not so
annoying to justify extending the strict mainline commit requirements to
private branches.

Re: merge conlict?

[Andreas Schwab]

Óscar Fuentes <ofv@wanadoo.es> writes:

> the merged branch is recreated

What does that mean?

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: merge conlict?

[Óscar Fuentes]

Andreas Schwab <schwab@linux-m68k.org> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> the merged branch is recreated
>
> What does that mean?

You branch from trunk on a way that the result is the branch which was
merged into trunk. For instance, for re-creating the branch that Jan
D. merged into trunk in revision 99383:

bzr branch -r revid:jan.h.d@swipnet.se-20100125074512-yacbu11t5wygm0iz trunk jan-99383

Re: merge conlict?

[Andreas Schwab]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Andreas Schwab <schwab@linux-m68k.org> writes:
>
>> Óscar Fuentes <ofv@wanadoo.es> writes:
>>
>>> the merged branch is recreated
>>
>> What does that mean?
>
> You branch from trunk on a way that the result is the branch which was
> merged into trunk.

How does that magically turn a non-bisectable branch into a bisectable
one?

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: merge conlict?

[Óscar Fuentes]

Andreas Schwab <schwab@linux-m68k.org> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>>>> the merged branch is recreated
>>>
>>> What does that mean?
>>
>> You branch from trunk on a way that the result is the branch which was
>> merged into trunk.
>
> How does that magically turn a non-bisectable branch into a bisectable
> one?

It doesn't. The goal here to selectively apply `bisect' to the parts of
the DAG you are interested on. The left-most part of trunk's DAG should
be bisectable, as it should the left-most part of a big, public branch
like multi-tty was. You are not interested on bisecting my 3 commits
branch that implemented a small feature, are you?

OTOH, maybe we should consider a policy about not merging small personal
branches into trunk. That would require an extra `bzr revert
--forget-merges' before committing to the local trunk mirror plus a bit
of housekeeping, if you follow the distributed workflow described on the
wiki.

Re: merge conlict?

[Andreas Schwab]

Óscar Fuentes <ofv@wanadoo.es> writes:

> You are not interested on bisecting my 3 commits branch that
> implemented a small feature, are you?

Sure I am.  If one of the 3 commits was the one that broke it.  That's
the whole point of bisection.

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: merge conlict?

[Óscar Fuentes]

Andreas Schwab <schwab@linux-m68k.org> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> You are not interested on bisecting my 3 commits branch that
>> implemented a small feature, are you?
>
> Sure I am.  If one of the 3 commits was the one that broke it.  That's
> the whole point of bisection.

And wouldn't you happy enough knowing the commit that merged the 3
commits into trunk?

It is very likely that if strict commit requirements are imposed on
private branches, people will refrain from doing local commits at
all. If you have to think hard and review and test before doing a local
commit, you will delay it as much as possible, or completely avoid
it. So, at the end, you have the same change on the left-most part of
trunk, but after removing the convenience of local branches, with the
subsequent impact on the fun/pace/relax people have hacking on Emacs.

Speaking as a newbie Emacs hacker, it is very encouraging to have the
possibility of working on some feature without worrying about breaking
things until the final point where the change is considered ready for
trunk. OTOH, having to keep every local commit up to trunk standards
looks very stressing. Not mentioning that most non-trivial new features
necessarily start on an unstable state.

Re: merge conlict?

[Andreas Schwab]

Óscar Fuentes <ofv@wanadoo.es> writes:

> And wouldn't you happy enough knowing the commit that merged the 3
> commits into trunk?

How do I know without looking into it?

> It is very likely that if strict commit requirements are imposed on
> private branches, people will refrain from doing local commits at
> all.

It will only require them to polish before pushing.

> Speaking as a newbie Emacs hacker, it is very encouraging to have the
> possibility of working on some feature without worrying about breaking
> things until the final point where the change is considered ready for
> trunk. OTOH, having to keep every local commit up to trunk standards
> looks very stressing. Not mentioning that most non-trivial new features
> necessarily start on an unstable state.

For some unknown reason this appears to work very well with a big
insignificant project.

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: merge conlict?

[Óscar Fuentes]

Andreas Schwab <schwab@linux-m68k.org> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> And wouldn't you happy enough knowing the commit that merged the 3
>> commits into trunk?
>
> How do I know without looking into it?

You can look into them. `bisect' tells you the merge commit. Then either
you read the merged revisions or, if you really enjoy bisecting,
reconstruct its original branch and bisect it.

>> It is very likely that if strict commit requirements are imposed on
>> private branches, people will refrain from doing local commits at
>> all.
>
> It will only require them to polish before pushing.

First, please let's bar the word "push" and its derivatives from Bazaar
discussions.

Second, what you propose is quite a bit of work, and not of the trivial
kind.

>> Speaking as a newbie Emacs hacker, it is very encouraging to have the
>> possibility of working on some feature without worrying about breaking
>> things until the final point where the change is considered ready for
>> trunk. OTOH, having to keep every local commit up to trunk standards
>> looks very stressing. Not mentioning that most non-trivial new features
>> necessarily start on an unstable state.
>
> For some unknown reason this appears to work very well with a big
> insignificant project.

Sorry, I'm not sure what you are referring to here.

Re: merge conlict?

[Andreas Schwab]

Óscar Fuentes <ofv@wanadoo.es> writes:

> First, please let's bar the word "push" and its derivatives from Bazaar
> discussions.

Since when has bzr elided the push command?

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: merge conlict?

[Óscar Fuentes]

Andreas Schwab <schwab@linux-m68k.org> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> First, please let's bar the word "push" and its derivatives from Bazaar
>> discussions.
>
> Since when has bzr elided the push command?

This discussion of ours turned to be too long. You already forgot how
this thread started :-)

Re: merge conlict?

[Stefan Monnier]

> Second, what you propose is quite a bit of work, and not of the trivial
> kind.

I think what Andreas is talking about is not about your temporary local
commits, but rather that before commit your changes into the trunk,
you'll want to rework them into a set of clean logical patches.

My experience is indeed that Bzr helps me keep track of local changes
and work on long-time branches, but usually when it gets time to install
on the trunk, I really port the changes "by hand" rather than just ask
Bzr to merge some (set of) change(s), so that I can clean them up (and
often enough, update&improve them).  Many people use "rebase" for that
clean up.


        Stefan

Re: merge conlict?

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Mon, 25 Jan 2010 21:02:40 -0500
> Cc: emacs-devel@gnu.org
> 
> > Second, what you propose is quite a bit of work, and not of the trivial
> > kind.
> 
> I think what Andreas is talking about is not about your temporary local
> commits, but rather that before commit your changes into the trunk,
> you'll want to rework them into a set of clean logical patches.

Actually, no proposal that's even remotely close to being complete was
ever laid on the table.  Without such a proposal, this thread has long
ago degenerated into useless noise.

> My experience is indeed that Bzr helps me keep track of local changes
> and work on long-time branches, but usually when it gets time to install
> on the trunk, I really port the changes "by hand" rather than just ask
> Bzr to merge some (set of) change(s), so that I can clean them up (and
> often enough, update&improve them).  Many people use "rebase" for that
> clean up.

I agree with Óscar: this is a lot of potentially unnecessary work.

Put yourself in my shoes: in the bidi branch I have roughly 2-3
commits for each week since August 2009 (1-2 commits for merges from
mainline, and 1 more for the bidi changes themselves I did during that
weekend).  This sounds like not too much, but it accumulates over the
months; do your math.  Having to sift through all that when the time
comes to merge with the trunk is not my idea of efficient use of my
scarce resources.  Especially since I don't see the boost in utility
that would justify such an investment.  The need to clean up the
ChangeLog entries is already a PITA, but that is at least marginally
bearable (because most intermediate entries are simply deleted).

Changes that do not require more than a single commit and take less
than a day to develop and test I already make in the trunk directly,
so "quickies" are out of this picture, and I'm talking only about
feature branches that require several non-trivial commits over
relatively prolonged periods of time (several days or weeks).

Maybe people who can hack Emacs all day long can cope with this
additional load.  I cannot, and I'm not convinced I'm the only one in
this league.

Switching to Bazaar was advertised as a boon for occasional
contributors.  That is supposed to cover people who don't have a lot
of time to invest in overhead activities.  Now it somehow turns out
that developing with Bazaar is more work than it was with CVS?  So
what did we switch for? to allow some advanced to exotic workflows for
those who have unlimited time to begin with?  That simply doesn't make
any sense to me.

But in any case, until Someone(TM) writes up a proposal for merging
feature branches that can be made part of the workflow, any
intelligent and useful discussion of this issue is hardly possible,
IMO.

Re: merge conlict?

[Stefan Monnier]

> Actually, no proposal that's even remotely close to being complete was
> ever laid on the table.  Without such a proposal, this thread has long
> ago degenerated into useless noise.

There is no proposal.  I was just trying to resolve a confusion in the
discussion (and clearly failed to do so).

>> My experience is indeed that Bzr helps me keep track of local changes
>> and work on long-time branches, but usually when it gets time to install
>> on the trunk, I really port the changes "by hand" rather than just ask
>> Bzr to merge some (set of) change(s), so that I can clean them up (and
>> often enough, update&improve them).  Many people use "rebase" for that
>> clean up.

> I agree with Óscar: this is a lot of potentially unnecessary work.

Who cares: it just describes my workflow, nothing more.  If/when I feel
like such a workflow should be turned into a convention that other
people should follow, rest assured that I'll do so in a separate thread.

> Put yourself in my shoes: in the bidi branch I have roughly 2-3
> commits for each week since August 2009 (1-2 commits for merges from
> mainline, and 1 more for the bidi changes themselves I did during that
> weekend).  This sounds like not too much, but it accumulates over the
> months; do your math.  Having to sift through all that when the time
> comes to merge with the trunk is not my idea of efficient use of my
> scarce resources.  Especially since I don't see the boost in utility
> that would justify such an investment.  The need to clean up the
> ChangeLog entries is already a PITA, but that is at least marginally
> bearable (because most intermediate entries are simply deleted).

If you go back in time, you'll see that I've generally been on the
"don't even bother to clean up the ChangeLog" side of the discussion.


        Stefan

Re: merge conlict?

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: ofv@wanadoo.es,  emacs-devel@gnu.org
> Date: Tue, 26 Jan 2010 10:11:34 -0500
> 
> > I agree with Óscar: this is a lot of potentially unnecessary work.
> 
> Who cares: it just describes my workflow, nothing more.  If/when I feel
> like such a workflow should be turned into a convention that other
> people should follow, rest assured that I'll do so in a separate thread.

Fine with me.  But since this issue comes up time and again here,
perhaps you should just say that, as a matter of policy, for now no
such effort is required or expected when features are merged and
committed to the trunk.

Re: merge conlict?

[Karl Fogel]

Eli Zaretskii <eliz@gnu.org> writes:
>> My experience is indeed that Bzr helps me keep track of local changes
>> and work on long-time branches, but usually when it gets time to install
>> on the trunk, I really port the changes "by hand" rather than just ask
>> Bzr to merge some (set of) change(s), so that I can clean them up (and
>> often enough, update&improve them).  Many people use "rebase" for that
>> clean up.
>
>I agree with Óscar: this is a lot of potentially unnecessary work.
>
>Put yourself in my shoes: in the bidi branch I have roughly 2-3
>commits for each week since August 2009 (1-2 commits for merges from
>mainline, and 1 more for the bidi changes themselves I did during that
>weekend).  This sounds like not too much, but it accumulates over the
>months; do your math.  Having to sift through all that when the time
>comes to merge with the trunk is not my idea of efficient use of my
>scarce resources.  Especially since I don't see the boost in utility
>that would justify such an investment.  The need to clean up the
>ChangeLog entries is already a PITA, but that is at least marginally
>bearable (because most intermediate entries are simply deleted).
>
>Changes that do not require more than a single commit and take less
>than a day to develop and test I already make in the trunk directly,
>so "quickies" are out of this picture, and I'm talking only about
>feature branches that require several non-trivial commits over
>relatively prolonged periods of time (several days or weeks).
>
>Maybe people who can hack Emacs all day long can cope with this
>additional load.  I cannot, and I'm not convinced I'm the only one in
>this league.
>
>Switching to Bazaar was advertised as a boon for occasional
>contributors.  That is supposed to cover people who don't have a lot
>of time to invest in overhead activities.  Now it somehow turns out
>that developing with Bazaar is more work than it was with CVS?  So
>what did we switch for? to allow some advanced to exotic workflows for
>those who have unlimited time to begin with?  That simply doesn't make
>any sense to me.
>
>But in any case, until Someone(TM) writes up a proposal for merging
>feature branches that can be made part of the workflow, any
>intelligent and useful discussion of this issue is hardly possible,
>IMO.

I haven't been able to follow this entire thread, but: why doesn't the
recommended workflow suffice?

Is the problem that some people are saying that all the internal commits
on your local branch should be clean & buildable & lint-free, in
addition to the final merge being similarly clean?

If so, I think that would be an unreasonable expectation, and not one
I've seen other projects enforce.

The final merge needs to be of publishable quality, of course -- it's
going on the mainline.  But the commits that led up to it?  That's
really up to the committer(s).  No one else ever has to build those
commits, after all.  Even if the local branch is published somewhere
independently, so others can participate in its development, the
developer(s) can determine what quality standards they want to uphold
pre-merge.  The Emacs project as a whole should just uphold quality on
its official branches, especially the mainline.

Or if that's not what the problem is here, then sorry for the noise.  I
want to help, if I can, but I simply can't keep up with threads this
large, so it's possible my response will be mis-aimed.

-Karl

Re: merge conlict?

[Stephen J. Turnbull]

Karl Fogel writes:

 > Is the problem that some people are saying that all the internal commits
 > on your local branch should be clean & buildable & lint-free, in
 > addition to the final merge being similarly clean?

Nobody is saying that.  What some people are saying is that all
*external* commits you push to a *global* repository should be clean
and/or buildable and/or lint-free.  AFAIK Linux demands that, and I'm
sure there are other projects that do, although I don't know of them
offhand.

 > The final merge needs to be of publishable quality, of course -- it's
 > going on the mainline.  But the commits that led up to it?  That's
 > really up to the committer(s).  No one else ever has to build those
 > commits, after all.

They don't *have* to, but they might *want* to.  Eg, bisect.

Re: merge conlict?

[Karl Fogel]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:
>Karl Fogel writes:
>
> > Is the problem that some people are saying that all the internal commits
> > on your local branch should be clean & buildable & lint-free, in
> > addition to the final merge being similarly clean?
>
>Nobody is saying that.  What some people are saying is that all
>*external* commits you push to a *global* repository should be clean
>and/or buildable and/or lint-free.  AFAIK Linux demands that, and I'm
>sure there are other projects that do, although I don't know of them
>offhand.

I might have mis-used terminology.  What I meant was:

No developer should leave the tip of the public mainline in a broken
state.

Do we demand something stricter than that?

Re: merge conlict?

[Eli Zaretskii]

> From: Karl Fogel <kfogel@red-bean.com>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  ofv@wanadoo.es,  emacs-devel@gnu.org
> Date: Tue, 26 Jan 2010 10:15:51 -0500
> 
> Is the problem that some people are saying that all the internal commits
> on your local branch should be clean & buildable & lint-free, in
> addition to the final merge being similarly clean?

No, they say the internal commits should be cleaned up as to not show
what they feel is ``noise'', whatever that means.

> If so, I think that would be an unreasonable expectation, and not one
> I've seen other projects enforce.

Well, they say some projects do.  But anyway, people talk; if we as a
project do not require such practices, I think the head maintainers
should say so loud and clear, to prevent such threads in the future.
This is the second time (on my failing memory, at least) that this
issue comes up in a long thread.

Re: merge conlict?

[David Reitter]

On Jan 25, 2010, at 4:24 PM, Óscar Fuentes wrote:
> It is very likely that if strict commit requirements are imposed on
> private branches, people will refrain from doing local commits at
> all. If you have to think hard and review and test before doing a  
> local
> commit, you will delay it as much as possible, or completely avoid
> it.

You're both right.  One of the contributors who is working with me on  
Aquamacs and I have been discussing this last night.  Even though  
we're using Git, it should still be relevant.

To avoid uninformative merge commits on the trunk (master), I  
suggested to use "git rebase" in lieu of "git merge" whenever a  
private (unpublished) branch is merged into the trunk.  Otherwise, the  
merge commit comment refers to branches that are not visible as named  
branches or tags to others, even though their content and history is  
(and I guess it'll be the same in bzr).  Rebasing in that case is  
easy, and cleaner.  (It's got nothing to do with rebase "surgery" on  
published branches, i.e., undoing history).  The non-linear commit  
history that you're discussing is another reason that I wasn't even  
thinking about.

http://wiki.bazaar.canonical.com/Rebase
Would this be useful?

If the commits on the private branch aren't clean, then rebasing  
clearly won't help.  Doing a merge with a reasonable commit message  
(listing all changes, but not any possible "back and forth",  
"trial&error" changes, sounds much better.

Does bzr generally make the merged history available?  Or would the  
branch need to be pushed?
(Git pushes all reachable revisions, I think, which is why I'm  
assuming bzr does the same, but maybe I'm wrong.)

Re: merge conlict?

[Óscar Fuentes]

David Reitter <david.reitter@gmail.com> writes:

> On Jan 25, 2010, at 4:24 PM, Óscar Fuentes wrote:
>> It is very likely that if strict commit requirements are imposed on
>> private branches, people will refrain from doing local commits at
>> all. If you have to think hard and review and test before doing a
>> local
>> commit, you will delay it as much as possible, or completely avoid
>> it.
>
> You're both right.  One of the contributors who is working with me on
> Aquamacs and I have been discussing this last night.  Even though
> we're using Git, it should still be relevant.
>
> To avoid uninformative merge commits on the trunk (master),

The discussion about uninformative commits merged into trunk finished
long time ago. This is about applying to private branches the quality
standards used for public branches like `trunk' (do not break the build,
remove debug code, etc)

> I suggested to use "git rebase" in lieu of "git merge" whenever a
> private (unpublished) branch is merged into the trunk.  Otherwise, the
> merge commit comment refers to branches that are not visible as named
> branches or tags to others, even though their content and history is
> (and I guess it'll be the same in bzr).  Rebasing in that case is
> easy, and cleaner.  (It's got nothing to do with rebase "surgery" on
> published branches, i.e., undoing history).  The non-linear commit
> history that you're discussing is another reason that I wasn't even
> thinking about.

I don't think that appending the local branch's commits to the public
branch is a good idea. You end with a linear history, but with lots of
details and warts that may be better hidden from the default log view.

Linus wrote somewhere about this, explaining that `rebase' is great for
small projects and private branches, but it is not a great idea to
create linear histories on public branches of large projects with
several developers.

> http://wiki.bazaar.canonical.com/Rebase
> Would this be useful?
>
> If the commits on the private branch aren't clean, then rebasing
> clearly won't help.  Doing a merge with a reasonable commit message
> (listing all changes, but not any possible "back and forth",
> "trial&error" changes, sounds much better.

Precisely, what I advocate is an style that allows unclean commits to
local branches. Not precisely garbage, but points that could do any kind
of breakage or go against coding standards.

> Does bzr generally make the merged history available?

Yes: bzr log -n0

[snip]

Re: merge conlict?

[Andreas Schwab]

Óscar Fuentes <ofv@wanadoo.es> writes:

> This is about applying to private branches the quality standards used
> for public branches like `trunk' (do not break the build,

In your private branch you can do what you want.  But before you publish
it you should put some polish on it.

> remove debug code, etc)

Nobody ever suggested that.

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: merge conlict?

[Stephen J. Turnbull]

David Reitter writes:

 > http://wiki.bazaar.canonical.com/Rebase
 > Would this be useful?

To some people.  Others just want to commit, merge, and forget.

 > If the commits on the private branch aren't clean,

For most people, they probably are.  Based on the workflows people
have described as desirable and historical, private branches are
likely to be generally short, and induced by lack of physical contact
with the upstream rather a desire to isolate the branch.  That is,
they had every intent of making a high-quality commit directly to
trunk, but the network failed or something.

Other people will be used to working with git or Mercurial, and likely
will have more significant private branches of uncertain quality.

 > Does bzr generally make the merged history available?  Or would the  
 > branch need to be pushed?

I'm not sure what you're asking.  When you push or pull from one
pbranch to another, bzr transfers all commits reachable from the merge
commit to the target branch.

 > (Git pushes all reachable revisions, I think, which is why I'm  
 > assuming bzr does the same, but maybe I'm wrong.)

Your phrasing is ambiguous.  The only git command that defaults to
transferring *all* reachable revisions is clone.  bzr has no analog to
that yet, but it is planned and a fair amount of work has been done
AIUI.

git push will push all revisions reachable from the refs named on the
command line, defaulting to those reachable from HEAD.  This is the
same as bzr.

git push can be configured to default to pushing a set of refs and all
commits reachable from them.  AFAIK bzr has no analog, nor is one planned.

Re: merge conlict?

[David Reitter]

On Jan 25, 2010, at 8:38 PM, Stephen J. Turnbull wrote:
> When you push or pull from one
> pbranch to another, bzr transfers all commits reachable from the merge
> commit to the target branch.

> git push will push all revisions reachable from the refs named on the
> command line, defaulting to those reachable from HEAD.  This is the
> same as bzr.

Thank you.

Re: merge conlict?

[Teemu Likonen]

On 2010-01-25 13:22 (+0100), Óscar Fuentes wrote:

> I was going to do that. Thanks for saving me the ASCII art. I abhor
> doing any kind of visual art :-)
>
> You can view the branch diagram with `bzr qlog'. You need the qbzr
> plugin, which is included on most bzr installers and distro
> repositories.

I made it with "git log --graph --oneline" and copy-pasted to my
message.

>> Well, technically nothing bad has happened.
>
> Unless you take the "technically" part as "no code was lost", I beg to
> differ. A simple `bzr log' will show that the commits of the last few
> days are gone from the listing. You need to add the `-n2' parameter to
> see them as merged history under Mark's commit. Ideally, you shouldn't
> need to look at the merged history except for "serious" branches. Do a
> `bzr log -n2' and see how much uninteresting stuff you get. So now
> part of the important stuff was moved to the same level as the
> uninteresting stuff.

Ok, yes. Bazaar's log gets really bad if one doesn't maintain strict
mainline mentality and practices. What looks like the mainline is not
always so. I don't think it was a good design decision to build user
interface too heavily around that.

Re: merge conlict?

[Thierry Volpiatto]

Teemu Likonen <tlikonen@iki.fi> writes:

> On 2010-01-25 13:22 (+0100), Óscar Fuentes wrote:
>
>> I was going to do that. Thanks for saving me the ASCII art. I abhor
>> doing any kind of visual art :-)
>>
>> You can view the branch diagram with `bzr qlog'. You need the qbzr
>> plugin, which is included on most bzr installers and distro
>> repositories.
>
> I made it with "git log --graph --oneline" and copy-pasted to my
> message.
>
>>> Well, technically nothing bad has happened.
>>
>> Unless you take the "technically" part as "no code was lost", I beg to
>> differ. A simple `bzr log' will show that the commits of the last few
>> days are gone from the listing. You need to add the `-n2' parameter to
>> see them as merged history under Mark's commit. Ideally, you shouldn't
>> need to look at the merged history except for "serious" branches. Do a
>> `bzr log -n2' and see how much uninteresting stuff you get. So now
>> part of the important stuff was moved to the same level as the
>> uninteresting stuff.
>
> Ok, yes. Bazaar's log gets really bad if one doesn't maintain strict
> mainline mentality and practices. What looks like the mainline is not
> always so. I don't think it was a good design decision to build user
> interface too heavily around that.

If it can help here is the graph log made on my hg repo:

thierry@/home/thierry/download/emacs-hg $ hg glog -l 12
@  changeset:   106987:e18a3ab3c2a8
|  tag:         tip
|  user:        Dan Nicolaescu <dann@ics.uci.edu>
|  date:        Mon Jan 25 01:04:59 2010 -0800
|  summary:     (vc-annotate-revision-at-line): Compare file
|
o    changeset:   106986:537d6b88b0c9
|\   parent:      106984:c7c26994ef04
| |  parent:      106985:75b813119b24
| |  user:        Jan D. <jan.h.d@swipnet.se>
| |  date:        Mon Jan 25 08:46:15 2010 +0100
| |  summary:     * xfns.c (Fx_create_frame): If frame height is too big, try
| |
| o  changeset:   106985:75b813119b24
|/|  parent:      106957:ba33512ab5de
| |  parent:      106984:c7c26994ef04
| |  user:        Jan D. <jan.h.d@swipnet.se>
| |  date:        Mon Jan 25 08:45:12 2010 +0100
| |  summary:     Merge from trunk
| |
o |  changeset:   106984:c7c26994ef04
| |  user:        Dan Nicolaescu <dann@ics.uci.edu>
| |  date:        Sun Jan 24 22:03:23 2010 -0800
| |  summary:     (vc-bzr-print-log): Use the more compact --line option
| |
o |    changeset:   106983:25c4b65d9f7d
|\ \   parent:      106982:6e531c0687e2
| | |  parent:      106980:f5df3c57ab2e
| | |  user:        Mark A. Hershberger <mhershberger@intrahealth.org>
| | |  date:        Mon Jan 25 00:03:35 2010 -0500
| | |  summary:     merge
| | |
| o |  changeset:   106982:6e531c0687e2
| | |  user:        Mark A. Hershberger <mhershberger@intrahealth.org>
| | |  date:        Mon Jan 25 00:02:10 2010 -0500
| | |  summary:     working version of vc-bzr-revision-table
| | |
| o |    changeset:   106981:dacda1d80bbd
| |\ \   parent:      106958:3fda37a060cc
| | | |  parent:      106979:8dfa52d01f3a
| | | |  user:        Mark A. Hershberger <mhershberger@intrahealth.org>
| | | |  date:        Sun Jan 24 23:52:26 2010 -0500
| | | |  summary:     merge conflict
| | | |
o---+ |  changeset:   106980:f5df3c57ab2e
  | | |  user:        Eric Hanchrow <eric.hanchrow@gmail.com>
 / / /   date:        Sun Jan 24 20:46:40 2010 -0800
| | |    summary:     (vc-git-dir-status-goto-stage): Pass --relative to the
| | |
| o |    changeset:   106979:8dfa52d01f3a
| |\ \   parent:      106978:df60abaf45d8
| | | |  parent:      106959:2217a5de9d38
| | | |  user:        Stefan Monnier <monnier@iro.umontreal.ca>
| | | |  date:        Sun Jan 24 21:52:03 2010 -0500
| | | |  summary:     Try and fix bug#788, hopefully for real this time.
| | | |
| | o |  changeset:   106978:df60abaf45d8
| | | |  user:        Chong Yidong <cyd@stupidchicken.com>
| | | |  date:        Sun Jan 24 18:03:13 2010 -0500
| | | |  summary:     Use png_sig_cmp to allow linking with libpng 1.4.0.
| | | |
| | o |  changeset:   106977:172a011a9563
| | | |  user:        Dan Nicolaescu <dann@ics.uci.edu>
| | | |  date:        Sun Jan 24 13:23:17 2010 -0800
| | | |  summary:     Remove support for adding --signoff on commit.
| | | |
| | o |  changeset:   106976:b61683448acc
| | | |  user:        Dan Nicolaescu <dann@ics.uci.edu>
| | | |  date:        Sun Jan 24 13:08:53 2010 -0800
| | | |  summary:     (xterm-maybe-set-dark-background-mode): Rename
| | | |


-- 
Thierry Volpiatto

Re: merge conlict?

[Óscar Fuentes]

[sorry if this is a duplicate. seems gmane is going on and off today]

Teemu Likonen <tlikonen@iki.fi> writes:

> On 2010-01-25 12:27 (+0100), Óscar Fuentes wrote:
>
>> OTOH, Mark looks like more
>>
>> somebranch $ bzr merge URL_TO_UPSTREAM_TRUNK
>> somebranch $ bzr commit
>> somebranch $ bzr push URL_TO_UPSTREAM_TRUNK
>>
>> which causes havoc.
>
> Let's visualize:

I was going to do that. Thanks for saving me the ASCII art. I abhor
doing any kind of visual art :-)

You can view the branch diagram with `bzr qlog'. You need the qbzr
plugin, which is included on most bzr installers and distro
repositories.

[snip]

> Well, technically nothing bad has happened.

Unless you take the "technically" part as "no code was lost", I beg to
differ. A simple `bzr log --lines' will show that the commits of the
last few days are gone from the listing. You need to add the `-n2'
parameter to see them as merged history under Mark's commit. Ideally,
you shouldn't need to look at the merged history except for "serious"
branches. Do a `bzr log -n2' and see how much uninteresting stuff you
get. So now part of the important stuff was moved to the same level as
the uninteresting stuff.

Oh, and apart from this problem and producing a huge diff, it breaks
bisection.

> It's a social question if it's important to always have the trunk the
> first parent.

As you said on a previous message, for bzr it is important to
differentiate the left-most part of the history. The writers of the
BzrForEmacsDevs wiki page were very careful about this point when they
wrote the workflow description.

Re: merge conlict?

[Richard Stallman]

    If my guess is right, Mark merged trunk into his private branch, and
    then pushed to upstream, which is very wrong.

If we think this is wrong practice, can we customize something so that
it isn't allowed?

Re: merge conlict?

[Stephen J. Turnbull]

Richard Stallman writes:
 >     If my guess is right, Mark merged trunk into his private branch, and
 >     then pushed to upstream, which is very wrong.
 > 
 > If we think this is wrong practice, can we customize something so that
 > it isn't allowed?

No.  Merging from trunk to branch is often very useful for any of
several reasons, and merging from branch to trunk is necessary (that's
how new code gets into trunk and becomes available to the community).
It would be a very bad idea to forbid either kind of merge.

Distinguishing between trunk->branch merges that are useful and those
that merely create unreadable history (as displayed by bzr) requires
fine judgment.  Any automated gatekeeper would simply frustrate people
working on branches (and maybe those working directly on the trunk,
too, at least until the bugs are worked out).

Re: merge conlict?

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Date: Tue, 26 Jan 2010 10:49:53 +0900
> Cc: Óscar Fuentes <ofv@wanadoo.es>, emacs-devel@gnu.org
> 
> Richard Stallman writes:
>  >     If my guess is right, Mark merged trunk into his private branch, and
>  >     then pushed to upstream, which is very wrong.
>  > 
>  > If we think this is wrong practice, can we customize something so that
>  > it isn't allowed?
> 
> No.  Merging from trunk to branch is often very useful for any of
> several reasons, and merging from branch to trunk is necessary (that's
> how new code gets into trunk and becomes available to the community).
> It would be a very bad idea to forbid either kind of merge.

I think Richard was asking about pushing from a private branch, not
about merging.  At least, AFAIU, this is the part that Óscar said was
very wrong.

Re: merge conlict?

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> I think Richard was asking about pushing from a private branch,

How do you define that?

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: merge conlict?

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: "Stephen J. Turnbull" <stephen@xemacs.org>,  ofv@wanadoo.es,  rms@gnu.org,  emacs-devel@gnu.org
> Date: Tue, 26 Jan 2010 10:16:25 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I think Richard was asking about pushing from a private branch,
> 
> How do you define that?

Trivially, as pushing from a private branch.

Re: merge conlict?

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> Trivially, as pushing from a private branch.

How do you define a private branch?

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: merge conlict?

[Óscar Fuentes]

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

> Richard Stallman writes:
>  >     If my guess is right, Mark merged trunk into his private branch, and
>  >     then pushed to upstream, which is very wrong.
>  > 
>  > If we think this is wrong practice, can we customize something so that
>  > it isn't allowed?
>
> No.  Merging [snip]

The problem is `merge && push', not `merge && commit'. Stefan already
asked about this on the bzr ml and it seems that there is a method for
disabling just that.

Re: merge conlict?

[Richard Stallman]

    Distinguishing between trunk->branch merges that are useful and those
    that merely create unreadable history (as displayed by bzr) requires
    fine judgment.

Should only the maintainers, Stefan and Yidong, be able to do
these merges?

Re: merge conlict?

[Richard Stallman]

    Distinguishing between trunk->branch merges that are useful and those
    that merely create unreadable history (as displayed by bzr) requires
    fine judgment.

Should only the maintainers, Stefan and Yidong, be able to do
trunk->branch merges?

Re: merge conlict?

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Tue, 26 Jan 2010 11:49:46 -0500
> Cc: ofv@wanadoo.es, emacs-devel@gnu.org
> 
>     Distinguishing between trunk->branch merges that are useful and those
>     that merely create unreadable history (as displayed by bzr) requires
>     fine judgment.
> 
> Should only the maintainers, Stefan and Yidong, be able to do
> trunk->branch merges?

No!  Every developer who works on a feature in a separate branch needs
to do that from time to time, to avoid diverging too much from
mainline.

The no-no (AFAIU) is to push directly from such a feature branch to
the savannah repository.

Re: merge conlict?

[Lennart Borgman]

On Tue, Jan 26, 2010 at 6:50 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Richard Stallman <rms@gnu.org>
>> Date: Tue, 26 Jan 2010 11:49:46 -0500
>> Cc: ofv@wanadoo.es, emacs-devel@gnu.org
>>
>>     Distinguishing between trunk->branch merges that are useful and those
>>     that merely create unreadable history (as displayed by bzr) requires
>>     fine judgment.
>>
>> Should only the maintainers, Stefan and Yidong, be able to do
>> trunk->branch merges?
>
> No!  Every developer who works on a feature in a separate branch needs
> to do that from time to time, to avoid diverging too much from
> mainline.
>
> The no-no (AFAIU) is to push directly from such a feature branch to
> the savannah repository.


This thread is over my head, I do not have time to capture the
details. Could the conclusions from the discussion (when it is
somewhat ready) please be put on the EmacsWiki page?

Re: merge conlict?

[Karl Fogel]

Lennart Borgman <lennart.borgman@gmail.com> writes:
>This thread is over my head, I do not have time to capture the
>details. Could the conclusions from the discussion (when it is
>somewhat ready) please be put on the EmacsWiki page?

It's too long for me too.

But since some people may be expecting me to maintain BzrForEmacsDevs,
this is an explicit request for someone who understands what the heck
has been concluded here to please update the page if necessary!

Thanks,
-Karl

Re: merge conlict?

[Eli Zaretskii]

> From: Karl Fogel <kfogel@red-bean.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  rms@gnu.org,  emacs-devel@gnu.org
> Date: Tue, 26 Jan 2010 13:42:51 -0500
> 
> Lennart Borgman <lennart.borgman@gmail.com> writes:
> >This thread is over my head, I do not have time to capture the
> >details. Could the conclusions from the discussion (when it is
> >somewhat ready) please be put on the EmacsWiki page?
> 
> It's too long for me too.
> 
> But since some people may be expecting me to maintain BzrForEmacsDevs,
> this is an explicit request for someone who understands what the heck
> has been concluded here to please update the page if necessary!

There's nothing to update.  Everything is already there.  The problem
which started this was because the guilty parties didn't follow the
workflow described on the wiki to the letter.

Re: merge conlict?

[Stephen J. Turnbull]

Karl Fogel writes:

 > But since some people may be expecting me to maintain BzrForEmacsDevs,
 > this is an explicit request for someone who understands what the heck
 > has been concluded here to please update the page if necessary!

I think the change that Stefan made (setting append_revisions_only
true in the branch configuration on Savannah) is exactly what is
needed to prevent repetitions.

In particular, *no* config changes are needed in personal branches,
and no changes are needed to developer workflows that *don't* cause
the problem.

We may expect queries about this from users (cf.
http://www.mail-archive.com/maria-developers@lists.launchpad.net/msg00237.html,
from another project), but until they happen we can't judge whether
BzrForEmacsDevs needs to be updated to address it.

Re: merge conlict?

[Richard Stallman]

    > Should only the maintainers, Stefan and Yidong, be able to do
    > trunk->branch merges?

    No!  Every developer who works on a feature in a separate branch needs
    to do that from time to time, to avoid diverging too much from
    mainline.

Sorry, it is the push from a branch that caused the confusion.  Should
only the maintainers, Stefan and Yidong, be able to do that?

Re: merge conlict?

[Stefan Monnier]

>> Should only the maintainers, Stefan and Yidong, be able to do
>> trunk-> branch merges?
>     No!  Every developer who works on a feature in a separate branch needs
>     to do that from time to time, to avoid diverging too much from
>     mainline.
> Sorry, it is the push from a branch that caused the confusion.

Yes.

> Should only the maintainers, Stefan and Yidong, be able to do that?

I'd say "not even".
Basically, instead of "push" to the trunk, the right way is to "merge"
from some other branch onto the trunk.
In any case, the .bzr/branch/branch.conf modification should ensure that
such errors don't happen any more.


        Stefan

Re: merge conlict?

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Tue, 26 Jan 2010 20:18:33 -0500
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> 
> >> Should only the maintainers, Stefan and Yidong, be able to do
> >> trunk-> branch merges?
> >     No!  Every developer who works on a feature in a separate branch needs
> >     to do that from time to time, to avoid diverging too much from
> >     mainline.
> > Sorry, it is the push from a branch that caused the confusion.
> 
> Yes.
> 
> > Should only the maintainers, Stefan and Yidong, be able to do that?
> 
> I'd say "not even".
> Basically, instead of "push" to the trunk, the right way is to "merge"
> from some other branch onto the trunk.
> In any case, the .bzr/branch/branch.conf modification should ensure that
> such errors don't happen any more.

Actually, not every "push" is harmful, and the option you set will not
prevent those that are not.

(If we want to develop a useful common understanding of the issues
related to Bazaar and the right workflow with it, I think we should
try to be as accurate as possible about the semantics and the effects
of the operations we discuss.)

Re: merge conlict?

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: mhershberger@intrahealth.org,  emacs-devel@gnu.org
> Date: Mon, 25 Jan 2010 11:19:03 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Not much different from
> >> eg. yamaoka@jpl.org-20100121085911-ix6bp10z930y7zn8.
> >
> > That merge is made of Katsumi Yamaoka's changes.
> 
> I don't understand that sentence.  Can you clarify?

Compare the names of committers and log messages in this:

  99377.1.10: Katsumi Yamaoka 2010-01-21 [merge] (Score File Format): Fix typo.
    99266.1.23: Katsumi Yamaoka 2010-01-21 (Score File Format): Fix typo.
    99266.1.22: Katsumi Yamaoka 2010-01-21 [merge] Merge from mainline.
    99266.1.21: Katsumi Yamaoka 2010-01-20 [merge] Merge from mainline.
    99266.1.20: Katsumi Yamaoka 2010-01-19 [merge] Merge from mainline.
    99266.1.19: Katsumi Yamaoka 2010-01-19 [merge] Merge from mainline.
    99266.1.18: Katsumi Yamaoka 2010-01-18 [merge] Merge from mainline.
    99266.1.17: Katsumi Yamaoka 2010-01-18 [merge] Merge from mainline.
    99266.1.16: Katsumi Yamaoka 2010-01-18 [merge] Merge from mainline.
    99266.1.15: Katsumi Yamaoka 2010-01-17 [merge] Merge from mainline.
    99266.1.14: Katsumi Yamaoka 2010-01-17 [merge] Merge from mainline.
    99266.1.13: Katsumi Yamaoka 2010-01-14 [merge] Merge from mainline.
    99266.1.12: Katsumi Yamaoka 2010-01-14 [merge] Merge from mainline.
    99266.1.11: Katsumi Yamaoka 2010-01-13 [merge] Merge from mainline.
    99266.1.10: Katsumi Yamaoka 2010-01-13 [merge] Merge from mainline.
    99266.1.9: Katsumi Yamaoka 2010-01-13 [merge] Merge from mainline.
    99266.1.8: Katsumi Yamaoka 2010-01-12 [merge] Merge from mainline.
    99266.1.7: Katsumi Yamaoka 2010-01-12 [merge] Merge from mainline.
    99266.1.6: Katsumi Yamaoka 2010-01-11 [merge] Merge from mainline.
    99266.1.5: Katsumi Yamaoka 2010-01-08 [merge] Merge from mainline.
    99266.1.4: Katsumi Yamaoka 2010-01-07 [merge] Merge from mainline.
    99266.1.3: Katsumi Yamaoka 2010-01-06 [merge] Merge from mainline.

with this:

  99379: Mark A. Hershberger 2010-01-24 [merge] merge conflict
    99377.1.37: Stefan Monnier 2010-01-24 [merge] Try and fix bug#788, hopeful..
      99377.3.1: Stefan Monnier 2010-01-24 * keymap.c (shadow_lookup): Add `re..
    99377.1.36: Chong Yidong 2010-01-24 Use png_sig_cmp to allow linking with ..
    99377.1.35: Dan Nicolaescu 2010-01-24 Remove support for adding --signoff ..
    99377.1.34: Dan Nicolaescu 2010-01-24 (xterm-maybe-set-dark-background-mod..
    99377.1.33: Glenn Morris 2010-01-24 Add the aliases bug-emacs and bug-gnum..
    99377.1.32: Glenn Morris 2010-01-23 (aelement): Fix typo in previous.
    99377.1.31: Glenn Morris 2010-01-23 Small fixes.
    99377.1.30: Glenn Morris 2010-01-23 Fix some details of previous change.
    99377.1.29: Glenn Morris 2010-01-23 Update X-Debbugs-CC details.
    99377.1.28: Chong Yidong 2010-01-23 * emacs-lisp/advice.el (ad-set-orig-de..
    99377.1.27: Chong Yidong 2010-01-23 * url-util.el: Require url-vars (Bug#5..
    99377.1.26: Chong Yidong 2010-01-23 * emacs-lisp/assoc.el (aelement): Doc ..
    99377.1.25: Chong Yidong 2010-01-23 * emacs-lisp/assoc.el (aput, adelete, ..
    99377.1.24: Chong Yidong 2010-01-23 Account for utmp.h availability.

> > Which is not true for Mark's merge.
> 
> Both commits merge trunk into a branch.  How are they different?

Mark's branch seems to include commits that I think belong to
mainline.

Re: merge conlict?

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andreas Schwab <schwab@linux-m68k.org>
>> Cc: mhershberger@intrahealth.org,  emacs-devel@gnu.org
>> Date: Mon, 25 Jan 2010 11:19:03 +0100
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> Not much different from
>> >> eg. yamaoka@jpl.org-20100121085911-ix6bp10z930y7zn8.
>> >
>> > That merge is made of Katsumi Yamaoka's changes.
>> 
>> I don't understand that sentence.  Can you clarify?
>
> Compare the names of committers and log messages in this:
>
>   99377.1.10: Katsumi Yamaoka 2010-01-21 [merge] (Score File Format): Fix typo.

That's not yamaoka@jpl.org-20100121085911-ix6bp10z930y7zn8.

>> > Which is not true for Mark's merge.
>> 
>> Both commits merge trunk into a branch.  How are they different?
>
> Mark's branch seems to include commits that I think belong to
> mainline.

Just like the other one.  That's the whole point of merging trunk.

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: merge conlict?

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: emacs-devel@gnu.org
> Date: Mon, 25 Jan 2010 11:51:19 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Andreas Schwab <schwab@linux-m68k.org>
> >> Cc: mhershberger@intrahealth.org,  emacs-devel@gnu.org
> >> Date: Mon, 25 Jan 2010 11:19:03 +0100
> >> 
> >> Eli Zaretskii <eliz@gnu.org> writes:
> >> 
> >> >> Not much different from
> >> >> eg. yamaoka@jpl.org-20100121085911-ix6bp10z930y7zn8.
> >> >
> >> > That merge is made of Katsumi Yamaoka's changes.
> >> 
> >> I don't understand that sentence.  Can you clarify?
> >
> > Compare the names of committers and log messages in this:
> >
> >   99377.1.10: Katsumi Yamaoka 2010-01-21 [merge] (Score File Format): Fix typo.
> 
> That's not yamaoka@jpl.org-20100121085911-ix6bp10z930y7zn8.

The one you mention was part of what I showed.  This one, to be
precise:

    99266.1.22: Katsumi Yamaoka 2010-01-21 [merge] Merge from mainline.

It has no deeper revisions, so I really don't see your point.  If you
want to be helpful, please elaborate.

Re: merge conlict?

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> The one you mention was part of what I showed.  This one, to be
> precise:
>
>     99266.1.22: Katsumi Yamaoka 2010-01-21 [merge] Merge from mainline.
>
> It has no deeper revisions, so I really don't see your point.

This revision is merging trunk into a branch, exactly the same what
mhershberger@intrahealth.org-20100125045226-kdr44qlmgp2sfofu did.

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: merge conlict?

[Óscar Fuentes]

Andreas Schwab <schwab@linux-m68k.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> The one you mention was part of what I showed.  This one, to be
>> precise:
>>
>>     99266.1.22: Katsumi Yamaoka 2010-01-21 [merge] Merge from mainline.
>>
>> It has no deeper revisions, so I really don't see your point.
>
> This revision is merging trunk into a branch, exactly the same what
> mhershberger@intrahealth.org-20100125045226-kdr44qlmgp2sfofu did.

That revision had no effect on the output of `bzr log'. No revisions
that previously were visible as trunk's mainline became magically hidden
as merged history.

Re: merge conlict?

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> >> revno: 99379 [merge]
>> >> committer: Mark A. Hershberger <mhershberger@intrahealth.org>
>> >> branch nick: trunk
>> >> timestamp: Sun 2010-01-24 23:52:26 -0500
>> >> message:
>> >>   merge conflict
>> >
>> > What does this "merge conflict" in the commit message mean?  Why do
>> > so many unrelated files (see below) seem to be modified in one go?
>> 
>> That's a normal merge of trunk into a branch.
>
> Yes, but the "merge conflict" commit message bears some meaning that I
> hope Mark will be able to explain.  Obviously, that meaning is not
> something Bazaar would know about, or care.

I guess that he merged upstream into some local branch and then *pushed*
back to upstream from there. That causes lots of trouble, as we are
realizing.

>> Not much different from
>> eg. yamaoka@jpl.org-20100121085911-ix6bp10z930y7zn8.
>
> That merge is made of Katsumi Yamaoka's changes.  Which is not true
> for Mark's merge.  Thus my questions above.

Right. Katsumi Yamaoka's merge is perfectly fine.

Re: merge conlict?

[Stefan Monnier]

>>>>> "Andreas" == Andreas Schwab <schwab@linux-m68k.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>>> Date: Sun, 24 Jan 2010 23:52:26 -0500
>>> From: "Mark A. Hershberger" <mhershberger@intrahealth.org>
>>> To: emacs-diffs@gnu.org
>>> Subject: [Emacs-diffs] /srv/bzr/emacs/trunk r99379: merge conflict
>>> Content-Type: text/plain; charset="us-ascii"
>>> 
>>> ------------------------------------------------------------
>>> revno: 99379 [merge]
>>> committer: Mark A. Hershberger <mhershberger@intrahealth.org>
>>> branch nick: trunk
>>> timestamp: Sun 2010-01-24 23:52:26 -0500
>>> message:
>>> merge conflict
>> 
>> What does this "merge conflict" in the commit message mean?  Why do
>> so many unrelated files (see below) seem to be modified in one go?

> That's a normal merge of trunk into a branch.  Not much different from
> eg. yamaoka@jpl.org-20100121085911-ix6bp10z930y7zn8.

I've just added

   append_revisions_only = True

to the .../trunk/.bzr/branch/branch.conf which should reject a "bzr
push" that does this kind of ancestor-shifting.


        Stefan

Re: merge conlict?

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>,  "Mark A. Hershberger" <mhershberger@intrahealth.org>,  emacs-devel@gnu.org
> Date: Mon, 25 Jan 2010 22:02:46 -0500
> 
> I've just added
> 
>    append_revisions_only = True
> 
> to the .../trunk/.bzr/branch/branch.conf which should reject a "bzr
> push" that does this kind of ancestor-shifting.

Are you sure we understand the consequences enough to make such a fast
decision without testing it first?  What was the rush?

Re: merge conlict?

[Andreas Schwab]

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

> I've just added
>
>    append_revisions_only = True
>
> to the .../trunk/.bzr/branch/branch.conf which should reject a "bzr
> push" that does this kind of ancestor-shifting.

That setting has no influence.

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: merge conlict?

[Óscar Fuentes]

Andreas Schwab <schwab@linux-m68k.org> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> I've just added
>>
>>    append_revisions_only = True
>>
>> to the .../trunk/.bzr/branch/branch.conf which should reject a "bzr
>> push" that does this kind of ancestor-shifting.
>
> That setting has no influence.

bzr developers says it has. Have you tried it?  Can you describe how it
failed?

Re: merge conlict?

[Andreas Schwab]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Have you tried it?

Of course.

> Can you describe how it failed?

It cannot prevent it, since no revisions were lost.

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: merge conlict?

[Andreas Schwab]

Óscar Fuentes <ofv@wanadoo.es> writes:

> bzr developers says it has. Have you tried it?  Can you describe how it
> failed?

My test was apparently faulty, I can no longer reproduce the failure.

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: merge conlict?

[Teemu Likonen]

On 2010-01-25 09:43 (+0200), Eli Zaretskii wrote:

> What does this "merge conflict" in the commit message mean? Why do so
> many unrelated files (see below) seem to be modified in one go?

Yes, the list of changed files is quite confusing. It's against a merge
parent which Bazaar chooses implicitly and from trunk's point of view
it's the "wrong" parent. From the point of view of truly distributed
development it doesn't matter because no branch is more important than
any other. But yes, Bazaar has this trunk mentality and treats the so
called left-most parent more important.

It would probably help if Bazaar supported combined diff format. With
Git we can trivially see the actual changes introduced by the merge
commit:


$ git show b8de0d6

commit b8de0d6b29e0b5138c9c3edfd4b0d72bd583f789
Merge: 941488a 49a939e
Author: Mark A. Hershberger <mhershberger@intrahealth.org>
Date:   2010-01-24 23:52:26 -0500

    merge conflict

diff --cc doc/emacs/ChangeLog
index e9ab5ed,7d7002a..39ffa2c
--- a/doc/emacs/ChangeLog
+++ b/doc/emacs/ChangeLog
@@@ -1,8 -1,7 +1,12 @@@
- 2010-01-19  Mark A. Hershberger  <mah@everybody.org>
++2010-01-24  Mark A. Hershberger  <mah@everybody.org>
 +
 +	* programs.texi (Other C Commands): Replace reference to obsolete
 +	c-subword-mode.
 +
+ 2010-01-21  Glenn Morris  <rgm@gnu.org>
+ 
+ 	* trouble.texi (Bugs): Fix PROBLEMS keybinding.
+ 
  2010-01-12  Glenn Morris  <rgm@gnu.org>
  
  	* trouble.texi (Checklist): Use bug-gnu-emacs rather than
diff --cc doc/misc/ChangeLog
index 50673dc,3d39b10..fe34433
--- a/doc/misc/ChangeLog
+++ b/doc/misc/ChangeLog
@@@ -1,7 -1,7 +1,11 @@@
- 2010-01-19  Mark A. Hershberger  <mah@everybody.org>
 -2010-01-21  Katsumi Yamaoka  <yamaoka@jpl.org>
++2010-01-24  Mark A. Hershberger  <mah@everybody.org>
+ 
+ 	* gnus.texi (Score File Format): Fix typo.
+ 
++2010-01-21  Katsumi Yamaoka  <yamaoka@jpl.org>
 +
 +	* cc-mode.texi: Replace references to obsolete c-subword-mode.
 +
  2010-01-18  Juanma Barranquero  <lekktu@gmail.com>
  
  	* ada-mode.texi (Project File Overview): Fix typo.
diff --cc lisp/ChangeLog
index 86680e2,50da1d9..ed9e8ae
--- a/lisp/ChangeLog
+++ b/lisp/ChangeLog
@@@ -1,7 -1,84 +1,88 @@@
- 2010-01-19  Mark A. Hershberger  <mah@everybody.org>
++2010-01-24  Mark A. Hershberger  <mah@everybody.org>
 +
 +	* progmodes/python.el: Replace reference to obsolete c-subward-mode.
 +
+ 2010-01-24  Dan Nicolaescu  <dann@ics.uci.edu>
+ 
+ 	Remove support for adding --signoff on commit.
+ 	Future support will use an incompatible generic mechanism.
+ 	* vc-git.el (vc-git-add-signoff): Remove variable.
+ 	(vc-git-toggle-signoff): Remove function.
+ 	(vc-git-extra-menu-map): Do not bind vc-git-toggle-signoff.
+ 
+ 	* term/xterm.el (xterm-maybe-set-dark-background-mode): Rename
+ 	from xterm-set-background-mode.  Return t if the background mode
+ 	was set.
+ 	(terminal-init-xterm): Move tty-set-up-initial-frame-faces
+ 	earlier, call it again in case the background mode has changed.
+ 
+ 2010-01-23  Dmitri Paduchikh  <dpaduch@k66.ru>  (tiny change)
+ 
+ 	* emacs-lisp/advice.el (ad-set-orig-definition): Fix typo
+ 	(Bug#3541).
+ 
+ 2010-01-23  Chong Yidong  <cyd@stupidchicken.com>
+ 
+ 	* emacs-lisp/assoc.el (aelement): Doc fix.
+ 	(aput, adelete, amake): Use lexical-let (Bug#5450).
+ 
+ 2010-01-23  Stephen Leake  <stephen_leake@member.fsf.org>
+ 
+         * progmodes/ada-mode.el (ada-in-paramlist-p): Pragma syntax
+ 	is the same as subprogram call, not declaration.  (Bug#5435).
+ 
+ 2010-01-23  Michael Albinus  <michael.albinus@gmx.de>
+ 
+ 	* net/tramp-smb.el (tramp-smb-conf): New defcustom.
+ 	(tramp-smb-maybe-open-connection): Use it.
+ 
+ 2010-01-22  Michael Albinus  <michael.albinus@gmx.de>
+ 
+ 	* net/tramp-imap.el (top): Autoload needed packages.  (Bug#5448)
+ 
+ 2010-01-22  Stefan Monnier  <monnier@iro.umontreal.ca>
+ 
+ 	* mail/rmailmm.el (rmail-mime-handle): Don't set the buffer to unibyte
+ 	just because we see "encoding: 8bit".
+ 	* mail/rmail.el (rmail-show-message-1): Decode the body's QP into bytes.
+ 
+ 2010-01-22  Chong Yidong  <cyd@stupidchicken.com>
+ 
+ 	* isearch.el (isearch-allow-scroll): Doc fix (Bug#5446).
+ 
+ 2010-01-22  Eli Zaretskii  <eliz@gnu.org>
+ 
+ 	* jka-compr.el (jka-compr-load): If load-file is not in
+ 	load-history, try its file-truename version.  (bug#5447)
+ 
+ 2010-01-21  Alan Mackenzie  <acm@muc.de>
+ 
+ 	Fix a situation where deletion of a cpp construct throws an error.
+ 	* progmodes/cc-engine.el (c-invalidate-state-cache): Before
+ 	invoking c-with-all-but-one-cpps-commented-out, check that the
+ 	special cpp construct is still in the buffer.
+ 	(c-parse-state): Record the special cpp with markers, not numbers.
+ 
+ 2010-01-21  Kenichi Handa  <handa@m17n.org>
+ 
+ 	* textmodes/sgml-mode.el (sgml-maybe-name-self): No need to
+ 	process last-command-event, as it is now decoded first (Bug#5380).
+ 
+ 2010-01-20  Chong Yidong  <cyd@stupidchicken.com>
+ 
+ 	* term.el (term-send-raw-meta): Revert 2009-12-04 change (Bug#5330).
+ 
+ 2010-01-20  Glenn Morris  <rgm@gnu.org>
+ 
+ 	* indent.el (tab-always-indent): Fix custom-type.
+ 
+ 2010-01-19  Alan Mackenzie  <acm@muc.de>
+ 
+ 	* progmodes/cc-defs.el: Fix bug#5395: typing '#' in an empty
+ 	buffer throws "args out of range".
+ 	(c-set-cpp-delimiters, c-clear-cpp-delimiters): Check for EOB
+ 	playing the role of delimiter.
+ 
  2010-01-18  Stephen Leake  <stephen_leake@member.fsf.org>
  
  	* lisp/progmodes/ada-mode.el: Fix bug#5400.

Re: merge conlict?

[Eli Zaretskii]

> From: Teemu Likonen <tlikonen@iki.fi>
> Cc: "Mark A. Hershberger" <mhershberger@intrahealth.org>,  emacs-devel@gnu.org
> Date: Mon, 25 Jan 2010 13:33:38 +0200
> 
> It would probably help if Bazaar supported combined diff format. With
> Git we can trivially see the actual changes introduced by the merge
> commit:
> 
> 
> $ git show b8de0d6

Please help me understand what you ``trivially'' see in this output.
I clearly see here changes not made by Mark, and having no Git
knowledge I cannot discern between the changes, because the format
shown is not exactly the Diff format.

Re: merge conlict?

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> I clearly see here changes not made by Mark,

Of course not, since it's just a merge of trunk.

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: merge conlict?

[Teemu Likonen]

On 2010-01-25 14:02 (+0200), Eli Zaretskii wrote:

>> $ git show b8de0d6
>
> Please help me understand what you ``trivially'' see in this output. I
> clearly see here changes not made by Mark, and having no Git knowledge
> I cannot discern between the changes, because the format shown is not
> exactly the Diff format.

Sorry. There has probably been misunderstanding on my side too. One
thing is the changes made by the merge commit itself. If there are no
conflict resolution the merge commit doesn't add any changes of its own.
Another thing is that what changes the merging as a whole brings from of
the branches' point of view; this depends on how we look at it. I
believe you are interested in the latter so let's look at the merge
commit in question:

$ bzr log --show-ids -r 99379

------------------------------------------------------------
revno: 99379 [merge]
revision-id: mhershberger@intrahealth.org-20100125045226-kdr44qlmgp2sfofu
parent: mhershberger@intrahealth.org-20100119193922-csbqj8x71fiui8ax
parent: monnier@iro.umontreal.ca-20100125025203-r430km4xq62rec7s
committer: Mark A. Hershberger <mhershberger@intrahealth.org>
branch nick: trunk
timestamp: Sun 2010-01-24 23:52:26 -0500
message:
  merge conflict
------------------------------------------------------------

There's are the revision IDs of this merge's parents. To see what
changes the merge brought from former-trunk to Mark's branch:

$ bzr diff -r \
    revid:mhershberger@intrahealth.org-20100119193922-csbqj8x71fiui8ax..99379

Mark pushed this branch to the official Emacs branch on
bzr.savannah.gnu.org so now it became the branch we call "trunk".

To see what changes Mark made in his private branch and thus brought to
the main development line:

$ bzr diff -r \
    revid:monnier@iro.umontreal.ca-20100125025203-r430km4xq62rec7s..99379

To see how Mark resolved the conflicting merge:

$ git show b8de0d6

How to interpret Git's combined diff format is documented here:

http://www.kernel.org/pub/software/scm/git/docs/git-diff.html

Re: merge conlict?

[Eli Zaretskii]

> From: Teemu Likonen <tlikonen@iki.fi>
> Cc: emacs-devel@gnu.org
> Date: Mon, 25 Jan 2010 15:17:12 +0200
> 
> revno: 99379 [merge]
> revision-id: mhershberger@intrahealth.org-20100125045226-kdr44qlmgp2sfofu
> parent: mhershberger@intrahealth.org-20100119193922-csbqj8x71fiui8ax
> parent: monnier@iro.umontreal.ca-20100125025203-r430km4xq62rec7s
> committer: Mark A. Hershberger <mhershberger@intrahealth.org>
> branch nick: trunk
> timestamp: Sun 2010-01-24 23:52:26 -0500
> message:
>   merge conflict
> ------------------------------------------------------------
> 
> There's are the revision IDs of this merge's parents. To see what
> changes the merge brought from former-trunk to Mark's branch:
> 
> $ bzr diff -r \
>     revid:mhershberger@intrahealth.org-20100119193922-csbqj8x71fiui8ax..99379
> 
> Mark pushed this branch to the official Emacs branch on
> bzr.savannah.gnu.org so now it became the branch we call "trunk".
> 
> To see what changes Mark made in his private branch and thus brought to
> the main development line:
> 
> $ bzr diff -r \
>     revid:monnier@iro.umontreal.ca-20100125025203-r430km4xq62rec7s..99379
> 
> To see how Mark resolved the conflicting merge:
> 
> $ git show b8de0d6
> 
> How to interpret Git's combined diff format is documented here:
> 
> http://www.kernel.org/pub/software/scm/git/docs/git-diff.html

Thanks.  So now I understand that the conflict was only in the
ChangeLog files (as expected).

Also, revno 99379 included several unrelated changes.  Am I confused
or did we agree to avoid that?

Interpreting git diff --cc [was: merge conlict?]

[Stephen J. Turnbull]

For those who don't get git diff --cc.

Note that in the quotes of the diff below, the first three characters
" > " are email quoting, and the rest of the line would normally
appear flush left in a diff.  Column references start from 1, and do
*not* include the email quoting columns.

Teemu Likonen writes:

 > $ git show b8de0d6

 > diff --cc doc/emacs/ChangeLog

diff --cc is a git-specific mode of diff (git diff, not GNU diff)
which handles multiple parent commits specially.

 > index e9ab5ed,7d7002a..39ffa2c

The index header shows abbreviated SHA1 IDs for the two parents (on
the left-hand side of the ..), and the merge commit (on the right-hand
side.


 > --- a/doc/emacs/ChangeLog
 > +++ b/doc/emacs/ChangeLog
 > @@@ -1,8 -1,7 +1,12 @@@

The tripled @@@ marks this as a git diff --cc.  patch will choke on
that, so git diff --cc diffs cannot be applied.

 > - 2010-01-19  Mark A. Hershberger  <mah@everybody.org>
 > ++2010-01-24  Mark A. Hershberger  <mah@everybody.org>

As you can see above, instead of a single unified diff marker, there
are two.  The left hand side are Mark's changes (7d7002a..39ffa2c),
the right hand side are those of the trunk which was merged into
Mark's branch (e9ab5ed..39ffa2c).  The two lines above show that (1)
Mark changed the date of this log message in his branch when resolving
conflicts etc in the merge, and (2) this had the effect of adding the
line relative to the trunk.

In detail, in the first line, the "-" in column 1 deletes this line
from the version in Mark's branch, and the space in column 2 makes no
change to the version in the trunk.  That is correct because this line
wasn't in the trunk version, so it can't be deleted.  In the second
line, the "+" in column 1 indicates this line was added in Mark's
branch (ie, when combined with the deletion above, it replaces the
original line dated "2010-01-19" with a new line dated "2010-01-24").
The "+" in column 2 indicates that this line was added by comparison
to the trunk version.

 >  +
 >  +	* programs.texi (Other C Commands): Replace reference to obsolete
 >  +	c-subword-mode.
 >  +

Relative to Mark's branch, they were already there and are left
unchanged, as indicated by the " " in column 1.  Relative to the
trunk, the above lines were *added*, as indicated by the "+" in column
2.

 > + 2010-01-21  Glenn Morris  <rgm@gnu.org>
 > + 
 > + 	* trouble.texi (Bugs): Fix PROBLEMS keybinding.
 > + 

Relative to Mark's branch, these were added, as indicated by the "+"
in column 1.  Relative to the trunk, the above lines were already
there, as indicated by the " " in column 2.

*All* of the changes above were made relative to the common ancestor
commit (ie, the last commit before Mark's branch diverged from the
trunk).  In the merge, Mark arranged that his log message appears at
the top of the ChangeLog, as is GNU Emacs policy for new logs IIUC.

 >   2010-01-12  Glenn Morris  <rgm@gnu.org>
 >   
 >   	* trouble.texi (Checklist): Use bug-gnu-emacs rather than

The above lines were present in the common ancestor, are unchanged in
both branches as indicated by " " in both columns 1 and 2, and are
presented here for context.

Thus, by looking for "+" in column 2, you can see lines which were not
in the trunk.  Ie, those are the lines added by Marks branch.

HTH

Re: merge conlict?

[Richard Stallman]

    It would probably help if Bazaar supported combined diff format. With
    Git we can trivially see the actual changes introduced by the merge
    commit:

Could you please report that request to the Bazaar developers?

Re: merge conlict?

[Richard Stallman]

    What does this "merge conflict" in the commit message mean?

Whatever it means, it is too general.  This message ought to
say SOMETHING about what part of the code is being changed and what
the change does.

A response said:

    Both commits merge trunk into a branch.

"Merged trunk into a branch" implies that the branch has changed and
the trunk has not.  If so, why do we get a notification about it?  The
notifications are supposed to be for changes in the trunk, not for
changes in branches, right?

Re: merge conlict?

[Stephen J. Turnbull]

Richard Stallman writes:
 >     What does this "merge conflict" in the commit message mean?
 > 
 > Whatever it means, it is too general.

Yes, the committer is now aware of that.  What he probably expected
was to create a history that would be displayed like this in "bzr log
-n0".  The right-hand column would not be displayed by default ("bzr
log").

3 Merge MAH's "Cook bar food"
                                3.3 [fix] merge conflict
                                3.2 merge Wonderful Changes from
                                    trunk and test for regressions
2 I have found many Wonderful
  Changes which this column is
  unfortunately too small to
  contain the description.
                                3.1 Cook bar food for Common Ancestor.
1 Common Ancestor slept here.

In many projects this is a recommended workflow, because most
regressions are caught on the branch, and do not trouble the community
at large.

Unfortunately, it is can be quite difficult to figure out exactly how
to implement any given workflow in bzr, because of the very large
number of ambiguously documented commands doing similar but somewhat
different things.  Once you figure it out, you often find that it's
quite efficient.

 > A response said:
 > 
 >     Both commits merge trunk into a branch.
 > 
 > "Merged trunk into a branch" implies that the branch has changed and
 > the trunk has not.  If so, why do we get a notification about it?

Because a third commit merged the branch into trunk.  When this
happens, you get a notification of this third merge commit, which is
the one labeled "merge conflict".

Re: merge conlict?

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> CC: mhershberger@intrahealth.org, emacs-devel@gnu.org
> Date: Mon, 25 Jan 2010 19:04:43 -0500
> 
>     Both commits merge trunk into a branch.
> 
> "Merged trunk into a branch" implies that the branch has changed and
> the trunk has not.  If so, why do we get a notification about it?  The
> notifications are supposed to be for changes in the trunk, not for
> changes in branches, right?

Because the history DAG of the repository changed.  In Bazaar, history
changes are also changes, not just text changes in the versioned
files.

Re: merge conlict?

[Richard Stallman]

    > "Merged trunk into a branch" implies that the branch has changed and
    > the trunk has not.  If so, why do we get a notification about it?  The
    > notifications are supposed to be for changes in the trunk, not for
    > changes in branches, right?

    Because the history DAG of the repository changed.  In Bazaar, history
    changes are also changes, not just text changes in the versioned
    files.

Do we want to get these notifications?
If not, we could change the program not to send them.

Do we want these notifications to contain different information?
If so, we could change the program to set them up differently.

Re: merge conlict?

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> CC: mhershberger@intrahealth.org, emacs-devel@gnu.org
> Date: Tue, 26 Jan 2010 11:50:18 -0500
> 
>     > "Merged trunk into a branch" implies that the branch has changed and
>     > the trunk has not.  If so, why do we get a notification about it?  The
>     > notifications are supposed to be for changes in the trunk, not for
>     > changes in branches, right?
> 
>     Because the history DAG of the repository changed.  In Bazaar, history
>     changes are also changes, not just text changes in the versioned
>     files.
> 
> Do we want to get these notifications?
> If not, we could change the program not to send them.

Well, at least in this case, it helped to catch wrong practices and
warn people not to do that in the future.

> Do we want these notifications to contain different information?

Maybe.  If the server can detect such commits, it could send only the
list of the modified files and the changes in revision numbers (as in
"99377 changed to 99222.1.3").  The actual diffs are not interesting
in this case, I think.

Re: merge conlict?

[Katsumi Yamaoka]

BTW, may I fix the last bogus commit in trunk/doc/misc/ChangeLog ?
Or is there a plan to fix those `merge conlict'?

http://article.gmane.org/gmane.emacs.diffs/104054
-------------------------------------------------
revno: 99378
committer: Mark A. Hershberger <mhershberger <at> intrahealth.org>
[...]
=== modified file 'doc/misc/ChangeLog'
--- a/doc/misc/ChangeLog        2010-01-18 03:54:24 +0000
+++ b/doc/misc/ChangeLog        2010-01-19 19:39:22 +0000
@@ -1,3 +1,7 @@
+2010-01-19  Mark A. Hershberger  <mah <at> everybody.org>
+
+       * cc-mode.texi: Replace references to obsolete c-subword-mode.
+
 2010-01-18  Juanma Barranquero  <lekktu <at> gmail.com>

        * ada-mode.texi (Project File Overview): Fix typo.
[...]

http://article.gmane.org/gmane.emacs.diffs/104057
-------------------------------------------------
revno: 99379 [merge]
committer: Mark A. Hershberger <mhershberger <at> intrahealth.org>
[...]
=== modified file 'doc/misc/ChangeLog'
--- a/doc/misc/ChangeLog        2010-01-19 19:39:22 +0000
+++ b/doc/misc/ChangeLog        2010-01-25 04:52:26 +0000
@@ -1,4 +1,8 @@
-2010-01-19  Mark A. Hershberger  <mah <at> everybody.org>
+2010-01-24  Mark A. Hershberger  <mah <at> everybody.org>
+
+       * gnus.texi (Score File Format): Fix typo.
+
+2010-01-21  Katsumi Yamaoka  <yamaoka <at> jpl.org>

        * cc-mode.texi: Replace references to obsolete c-subword-mode.
[...]

Re: merge conlict?

[Eli Zaretskii]

> Date: Thu, 28 Jan 2010 11:10:39 +0900
> From: Katsumi Yamaoka <yamaoka@jpl.org>
> 
> BTW, may I fix the last bogus commit in trunk/doc/misc/ChangeLog ?

Fix how?

Re: merge conlict?

[Katsumi Yamaoka]

>>>>> Eli Zaretskii wrote:
>> Date: Thu, 28 Jan 2010 11:10:39 +0900
>> From: Katsumi Yamaoka <yamaoka@jpl.org>
>>
>> BTW, may I fix the last bogus commit in trunk/doc/misc/ChangeLog ?

> Fix how?

Probably this is the correct one:

--- ChangeLog~	2010-01-25 21:56:40 +0000
+++ ChangeLog	2010-01-28 04:11:15 +0000
@@ -1,8 +1,8 @@
-2010-01-24  Mark A. Hershberger  <mah@everybody.org>
+2010-01-21  Katsumi Yamaoka  <yamaoka@jpl.org>
 
 	* gnus.texi (Score File Format): Fix typo.
 
-2010-01-21  Katsumi Yamaoka  <yamaoka@jpl.org>
+2010-01-19  Mark A. Hershberger  <mah@everybody.org>
 
 	* cc-mode.texi: Replace references to obsolete c-subword-mode.
 
I've never modified cc-mode.texi. ;-)

Re: merge conlict?

[Eli Zaretskii]

> Date: Thu, 28 Jan 2010 13:13:10 +0900
> From: Katsumi Yamaoka <yamaoka@jpl.org>
> Cc: emacs-devel@gnu.org
> 
> >>>>> Eli Zaretskii wrote:
> >> Date: Thu, 28 Jan 2010 11:10:39 +0900
> >> From: Katsumi Yamaoka <yamaoka@jpl.org>
> >>
> >> BTW, may I fix the last bogus commit in trunk/doc/misc/ChangeLog ?
> 
> > Fix how?
> 
> Probably this is the correct one:
> 
> --- ChangeLog~	2010-01-25 21:56:40 +0000
> +++ ChangeLog	2010-01-28 04:11:15 +0000
> @@ -1,8 +1,8 @@
> -2010-01-24  Mark A. Hershberger  <mah@everybody.org>
> +2010-01-21  Katsumi Yamaoka  <yamaoka@jpl.org>
>  
>  	* gnus.texi (Score File Format): Fix typo.
>  
> -2010-01-21  Katsumi Yamaoka  <yamaoka@jpl.org>
> +2010-01-19  Mark A. Hershberger  <mah@everybody.org>
>  
>  	* cc-mode.texi: Replace references to obsolete c-subword-mode.
>  
> I've never modified cc-mode.texi. ;-)

Sure, go ahead.