Confusing "bzr log" as result of merges

Confusing "bzr log" as result of merges

[Eli Zaretskii]

Sometimes, you want to know when was a certain file last modified.
This is when "bzr log" is useful, if invoked with the name of that
file.  However, it looks like the way we merge other branches, and in
particular emacs-23, makes this harder than it needs to be.

An example of this difficulty is below:

With the current trunk, type this command:

  bzr log -l1 --line --include-merges src/xdisp.c

You will see this as output:

  104201: Glenn Morris 2011-05-12 [merge] Merge from emacs-23; up to r100577.

However, neither "bzr status" nor "bzr diff" will show any changes for
xdisp.c in that revision.  The reason, it seems, is this:

  bzr log -l2 --line --include-merges src/xdisp.c

   => 104201: Glenn Morris 2011-05-12 [merge] Merge from emacs-23; up to r100577.
        99634.2.937: Eli Zaretskii 2011-05-09 Backport revisions 103939.1.41..103939.1.44 (inclusive) from trunk (bug#8623)

and revision 99634.2.937 indeed made a few changes to xdisp.c.  But
that version was merged to the trunk much earlier, in revision 104021,
and "bzr annotate" still shows that the changes attributed to revision
99634.2.937 were made in 103939.1.41, not in 104201 nor in 99634.2.937:

  103939.1.42  eggert@cs.ucla.edu            20110425 |       it->dpend = v->contents + v->header.size;

I think this happens because bzr is smart enough to know that the
revision which changed this line is already on the trunk, and so it
doesn't record any changes for xdisp.c in the merge-commit or 104201.
Bazaar is doing TRT, but the net result for the user is confusion and
extra time spent when trying to figure out who made this specific
change and why.

What can we do to avoid this confusion as result of merges?  And why
was 99634.2.937 merged to the trunk, even though the log message
clearly says it's a backport?  If we avoid merging such backported
revisions, will this problem go away?

Re: Confusing "bzr log" as result of merges

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> And why was 99634.2.937 merged to the trunk, even though the log
> message clearly says it's a backport?  If we avoid merging such
> backported revisions, will this problem go away?

A merge always includes all parent revisions.  There is no way to "avoid
merging a backported 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: Confusing "bzr log" as result of merges

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: emacs-devel@gnu.org
> Date: Sat, 21 May 2011 10:36:57 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > And why was 99634.2.937 merged to the trunk, even though the log
> > message clearly says it's a backport?  If we avoid merging such
> > backported revisions, will this problem go away?
> 
> A merge always includes all parent revisions.  There is no way to "avoid
> merging a backported revision".

Maybe with git.  With bzr, "merge" accepts a switch that can specify
revisions to merge.

IOW, revision 100577 on the emacs-23 branch could have been omitted
from the merge, because its log message says it's a backport.

Re: Confusing "bzr log" as result of merges

[Eli Zaretskii]

> Date: Sat, 21 May 2011 11:44:46 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> IOW, revision 100577 on the emacs-23 branch could have been omitted
> from the merge^^^^^^

Sorry, I meant 100571.

Re: Confusing "bzr log" as result of merges

[Sven Joachim]

On 2011-05-21 10:44 +0200, Eli Zaretskii wrote:

>> From: Andreas Schwab <schwab@linux-m68k.org>
>> Cc: emacs-devel@gnu.org
>> Date: Sat, 21 May 2011 10:36:57 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > And why was 99634.2.937 merged to the trunk, even though the log
>> > message clearly says it's a backport?  If we avoid merging such
>> > backported revisions, will this problem go away?
>> 
>> A merge always includes all parent revisions.  There is no way to "avoid
>> merging a backported revision".
>
> Maybe with git.  With bzr, "merge" accepts a switch that can specify
> revisions to merge.

The downside of that is that bzr then does not track what revisions have
already been merged.  At least, that's what
http://wiki.bazaar.canonical.com/MergeTracking says about that topic.

Cheers,
       Sven

Re: Confusing "bzr log" as result of merges

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > And why was 99634.2.937 merged to the trunk, even though the log
>> > message clearly says it's a backport?  If we avoid merging such
>> > backported revisions, will this problem go away?
>> 
>> A merge always includes all parent revisions.  There is no way to "avoid
>> merging a backported revision".
>
> Maybe with git.  With bzr, "merge" accepts a switch that can specify
> revisions to merge.

When you pass a list of revisions, you aren't doing a merge, but a
cherry pick.  The resulting commit does not record the list of revisions
in any way.

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: Confusing "bzr log" as result of merges

[Eli Zaretskii]

> From: Sven Joachim <svenjoac@gmx.de>
> Cc: Andreas Schwab <schwab@linux-m68k.org>,  emacs-devel@gnu.org
> Date: Sat, 21 May 2011 11:01:13 +0200
> 
> > With bzr, "merge" accepts a switch that can specify revisions to merge.
> 
> The downside of that is that bzr then does not track what revisions have
> already been merged.

And that is downside because...?

Re: Confusing "bzr log" as result of merges

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: emacs-devel@gnu.org
> Date: Sat, 21 May 2011 11:02:23 +0200
> 
> The resulting commit does not record the list of revisions in any
> way.

I know that.  The question is how to get the best of both worlds.  If
you have constructive ideas, I'm all ears.  Reiterating what's in the
manual doesn't help.

Re: Confusing "bzr log" as result of merges

[Sven Joachim]

On 2011-05-21 11:16 +0200, Eli Zaretskii wrote:

>> From: Sven Joachim <svenjoac@gmx.de>
>> Cc: Andreas Schwab <schwab@linux-m68k.org>,  emacs-devel@gnu.org
>> Date: Sat, 21 May 2011 11:01:13 +0200
>> 
>> > With bzr, "merge" accepts a switch that can specify revisions to merge.
>> 
>> The downside of that is that bzr then does not track what revisions have
>> already been merged.
>
> And that is downside because...?

Because humans have to do the tracking then, without any help from the
VCS.

Sven

Re: Confusing "bzr log" as result of merges

[Eli Zaretskii]

> From: Sven Joachim <svenjoac@gmx.de>
> Cc: schwab@linux-m68k.org,  emacs-devel@gnu.org
> Date: Sat, 21 May 2011 11:27:17 +0200
> 
> >> The downside of that is that bzr then does not track what revisions have
> >> already been merged.
> >
> > And that is downside because...?
> 
> Because humans have to do the tracking then, without any help from the
> VCS.

This revision was already on the trunk, so its other instance doesn't
need to be tracked.

Re: Confusing "bzr log" as result of merges

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> I know that.  The question is how to get the best of both worlds.  If
> you have constructive ideas, I'm all ears.

Report it to the bzr people.  Git has no problem with this.

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: Confusing "bzr log" as result of merges

[Sven Joachim]

On 2011-05-21 11:30 +0200, Eli Zaretskii wrote:

>> From: Sven Joachim <svenjoac@gmx.de>
>> Cc: schwab@linux-m68k.org,  emacs-devel@gnu.org
>> Date: Sat, 21 May 2011 11:27:17 +0200
>> 
>> >> The downside of that is that bzr then does not track what revisions have
>> >> already been merged.
>> >
>> > And that is downside because...?
>> 
>> Because humans have to do the tracking then, without any help from the
>> VCS.
>
> This revision was already on the trunk, so its other instance doesn't
> need to be tracked.

The VCS has to track them if you want to do proper merges (as opposed to
cherry-picks aka merging only certain revisions).  That it presents
spurious logs for files that were not changed by the merge is a problem
specific to bzr, as Andreas had pointed out.

Cheers,
       Sven

Re: Confusing "bzr log" as result of merges

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: emacs-devel@gnu.org
> Date: Sat, 21 May 2011 11:38:22 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I know that.  The question is how to get the best of both worlds.  If
> > you have constructive ideas, I'm all ears.
> 
> Report it to the bzr people.  Git has no problem with this.

Useless advice, as usual.

There's nothing to report.  Bzr has no problem with this, either.  If
there is any problem, it's how we do merges.

Re: Confusing "bzr log" as result of merges

[Eli Zaretskii]

> Date: Sat, 21 May 2011 10:33:09 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> What can we do to avoid this confusion as result of merges?  And why
> was 99634.2.937 merged to the trunk, even though the log message
> clearly says it's a backport?  If we avoid merging such backported
> revisions, will this problem go away?

On second thought, maybe it's my fault, in that I merged from trunk to
emacs-23, instead of just copying the code?  Should we refrain from
merging from trunk to emacs-23, to avoid such confusion?

Re: Confusing "bzr log" as result of merges

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> There's nothing to report.  Bzr has no problem with this, either.  If
> there is any problem, it's how we do merges.

No, you are mistaken.  The merges are correct.

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: Confusing "bzr log" as result of merges

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> On second thought, maybe it's my fault, in that I merged from trunk to
> emacs-23, instead of just copying the code?

The latter is exactly what you did.  That's the essence of a
cherry-pick.

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: Confusing "bzr log" as result of merges

[Sven Joachim]

On 2011-05-21 12:38 +0200, Eli Zaretskii wrote:

>> Date: Sat, 21 May 2011 10:33:09 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> 
>> What can we do to avoid this confusion as result of merges?  And why
>> was 99634.2.937 merged to the trunk, even though the log message
>> clearly says it's a backport?  If we avoid merging such backported
>> revisions, will this problem go away?
>
> On second thought, maybe it's my fault, in that I merged from trunk to
> emacs-23, instead of just copying the code?

No, you only merged a few revisions which is a cherry-pick and not
recorded as a merge.

> Should we refrain from
> merging from trunk to emacs-23, to avoid such confusion?

Merging individual revisions is fine.

Cheers,
       Sven

Re: Confusing "bzr log" as result of merges

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: emacs-devel@gnu.org
> Date: Sat, 21 May 2011 12:56:33 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > On second thought, maybe it's my fault, in that I merged from trunk to
> > emacs-23, instead of just copying the code?
> 
> The latter is exactly what you did.  That's the essence of a
> cherry-pick.

Then how come bzr remembers those revisions I merged?  Cherry-picks
are not tracked, right?

Re: Confusing "bzr log" as result of merges

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> Then how come bzr remembers those revisions I merged?

It didn't.

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: Confusing "bzr log" as result of merges

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Date: Sat, 21 May 2011 14:23:36 +0200
> Cc: emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Then how come bzr remembers those revisions I merged?
> 
> It didn't.

Sigh.

Re: Confusing "bzr log" as result of merges

[Eli Zaretskii]

> Date: Sat, 21 May 2011 13:38:50 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > Date: Sat, 21 May 2011 10:33:09 +0300
> > From: Eli Zaretskii <eliz@gnu.org>
> > 
> > What can we do to avoid this confusion as result of merges?  And why
> > was 99634.2.937 merged to the trunk, even though the log message
> > clearly says it's a backport?  If we avoid merging such backported
> > revisions, will this problem go away?
> 
> On second thought, maybe it's my fault, in that I merged from trunk to
> emacs-23, instead of just copying the code?  Should we refrain from
> merging from trunk to emacs-23, to avoid such confusion?

On third thought, this seems to be an artifact of how we merge from
emacs-23.  I already complained about this in the past, see

  https://lists.gnu.org/archive/html/emacs-devel/2010-12/msg00504.html

In that discussion, we agreed to mention in the commit message the
versions that were reverse cherry-picked.  But it looks like that
agreement was never acted upon.

Re: Confusing "bzr log" as result of merges

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> In that discussion, we agreed to mention in the commit message the
> versions that were reverse cherry-picked.  But it looks like that
> agreement was never acted upon.

Apart from the fact that nothing was "reverse cherry-picked", how would
that change anything?

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: Confusing "bzr log" as result of merges

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: emacs-devel@gnu.org
> Date: Sat, 21 May 2011 15:37:41 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > In that discussion, we agreed to mention in the commit message the
> > versions that were reverse cherry-picked.  But it looks like that
> > agreement was never acted upon.
> 
> Apart from the fact that nothing was "reverse cherry-picked", how would
> that change anything?

See admin/bzrmerge.el.

Re: Confusing "bzr log" as result of merges

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> See admin/bzrmerge.el.

See what?

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: Confusing "bzr log" as result of merges

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Date: Sat, 21 May 2011 17:18:09 +0200
> Cc: emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > See admin/bzrmerge.el.
> 
> See what?

The answer to your question.

Re: Confusing "bzr log" as result of merges

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

[snip]

> What can we do to avoid this confusion as result of merges?
[snip]

Avoid cherry-picking. Always do merges.

Create a branch emacs-common and commit there all the changes intended
for emacs-23 and trunk. From time to time *merge* (not cherry-pick!)
emacs-common into emacs-23 and trunk.

Long time ago I advised against mixing cherry-picks and merges and
suggested this strategy, but was discarded because it is too
complex. I'm sure that as time passes and you get bitten again and again
by the current practice it will finally look extremely simple.

Re: Confusing "bzr log" as result of merges

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> The answer to your question.

Where?

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: Confusing "bzr log" as result of merges

[Andreas Schwab]

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

> Avoid cherry-picking. Always do merges.

Cherry-picks are a fact of life.  You cannot avoid them completely.

> Create a branch emacs-common and commit there all the changes intended
> for emacs-23 and trunk.

And how do you know with 100% reliability?

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: Confusing "bzr log" as result of merges

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Sat, 21 May 2011 18:21:57 +0200
> 
> Create a branch emacs-common and commit there all the changes intended
> for emacs-23 and trunk.

Given that the trunk and the branch diverge quite quickly, I don't
think what you suggest is practical.  The divergence is in the basic
infrastructure, such as access to global variables and members of
buffer and keyboard objects.  That makes such a common branch
problematic, as it is not clear which one of the diverging branches it
should follow, and how to be sure that all 3 branches "work".

> From time to time *merge* (not cherry-pick!)  emacs-common into
> emacs-23 and trunk.

We merge already, but then reverse cherry-pick those revisions that
are not intended for the trunk, before committing.  At least this is
my understanding of how merges from the branch work.

> Long time ago I advised against mixing cherry-picks and merges and
> suggested this strategy, but was discarded because it is too
> complex. I'm sure that as time passes and you get bitten again and again
> by the current practice it will finally look extremely simple.

Since no one is even bothered by these issues, I very much doubt that
anything will be done any time soon.

Re: Confusing "bzr log" as result of merges

[Óscar Fuentes]

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

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> Avoid cherry-picking. Always do merges.
>
> Cherry-picks are a fact of life.  You cannot avoid them completely.

Never cherry-pick from emacs-common. Why would you cherry pick from
emacs-common into emacs-23 or trunk, instead of just merging?

>> Create a branch emacs-common and commit there all the changes
>> intended for emacs-23 and trunk.
>
> And how do you know with 100% reliability?

You don't know with 100% reliability. If a change committed into
emacs-common does not belong there, do the same you do with the rest of
wrong commits: revert it.

I'm not saying that the proposed schema is perfect, it simply is better
than what we do now.

Re: Confusing "bzr log" as result of merges

[Andreas Schwab]

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

> You don't know with 100% reliability. If a change committed into
> emacs-common does not belong there, do the same you do with the rest of
> wrong commits: revert it.

I'm talking about the commits in the trunk that also belong in the
emacs-23 branch.  You either have to cherry-pick them into the
emacs-common branch, or into the emacs-23 branch.  Still the same
duplication as we have now.

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: Confusing "bzr log" as result of merges

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> Create a branch emacs-common and commit there all the changes intended
>> for emacs-23 and trunk.
>
> Given that the trunk and the branch diverge quite quickly, I don't
> think what you suggest is practical.  The divergence is in the basic
> infrastructure, such as access to global variables and members of
> buffer and keyboard objects.  That makes such a common branch
> problematic, as it is not clear which one of the diverging branches it
> should follow, and how to be sure that all 3 branches "work".

emacs-common does not need to "work" (nor even compile!) It is just a
temporary storage for submitted revisions, with the net result of
producing a cleaner history, reducing housekeeping and diminishing the
frequency of errors ("bzr merge" is less error-prone than an humane
figuring out which revisions need to be cherry-picked.)

>> From time to time *merge* (not cherry-pick!)  emacs-common into
>> emacs-23 and trunk.
>
> We merge already, but then reverse cherry-pick those revisions that
> are not intended for the trunk, before committing.  At least this is
> my understanding of how merges from the branch work.

I thought that you do both: cherry-picking from emacs-23 into trunk and
merging emacs-23 into trunk. But even if that's is not so, reverting
(reversing, as you say) the commits that does not belong into trunk
creates a messy history. This is undesirable.

>> Long time ago I advised against mixing cherry-picks and merges and
>> suggested this strategy, but was discarded because it is too
>> complex. I'm sure that as time passes and you get bitten again and again
>> by the current practice it will finally look extremely simple.
>
> Since no one is even bothered by these issues, I very much doubt that
> anything will be done any time soon.

I thought that the existence of this thread demonstrates that someone is
bothered by these issues.

Re: Confusing "bzr log" as result of merges

[Óscar Fuentes]

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

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> You don't know with 100% reliability. If a change committed into
>> emacs-common does not belong there, do the same you do with the rest of
>> wrong commits: revert it.
>
> I'm talking about the commits in the trunk that also belong in the
> emacs-23 branch.  You either have to cherry-pick them into the
> emacs-common branch, or into the emacs-23 branch.  Still the same
> duplication as we have now.

If a commit goes straight to trunk when it should go to emacs-common,
either cherry-pick it into emacs-23, as you say, which has the effect of
"polluting" the VC history of emacs-23, or revert it in trunk and commit
into emacs-common, which has the effect of "polluting" the VC history of
trunk. IMO the former is preferable.

One thing fundamentally wrong with the current practice is that emacs-23
ends with a mostly clean VC history while trunk accumulates all the mess
created by cherry-picks. emacs-23 will eventually die, but trunk is
supposed to live forever.

Re: Confusing "bzr log" as result of merges

[Glenn Morris]

Eli Zaretskii wrote:

>         99634.2.937: Eli Zaretskii 2011-05-09 Backport revisions 103939.1.41..103939.1.44 (inclusive) from trunk (bug#8623)
>
> and revision 99634.2.937 indeed made a few changes to xdisp.c.  But
> that version was merged to the trunk much earlier, in revision 104021,
> and "bzr annotate" still shows that the changes attributed to revision
> 99634.2.937 were made in 103939.1.41, not in 104201 nor in 99634.2.937:

Haven't we been over this before?

http://lists.gnu.org/archive/html/emacs-devel/2011-01/msg00609.html

> I think this happens because bzr is smart enough to know that the
> revision which changed this line is already on the trunk, and so it
> doesn't record any changes for xdisp.c in the merge-commit or 104201.

Re: Confusing "bzr log" as result of merges

[Andreas Schwab]

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

> One thing fundamentally wrong with the current practice is that emacs-23
> ends with a mostly clean VC history while trunk accumulates all the mess
> created by cherry-picks.

Those few cherry-picks are nothing compared to the massive merge mess.

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: Confusing "bzr log" as result of merges

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Sat, 21 May 2011 19:09:35 +0200
> 
> > Since no one is even bothered by these issues, I very much doubt that
> > anything will be done any time soon.
> 
> I thought that the existence of this thread demonstrates that someone is
> bothered by these issues.

"Someone" is not enough.

Re: Confusing "bzr log" as result of merges

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Sat, 21 May 2011 13:27:07 -0400
> 
> Eli Zaretskii wrote:
> 
> >         99634.2.937: Eli Zaretskii 2011-05-09 Backport revisions 103939.1.41..103939.1.44 (inclusive) from trunk (bug#8623)
> >
> > and revision 99634.2.937 indeed made a few changes to xdisp.c.  But
> > that version was merged to the trunk much earlier, in revision 104021,
> > and "bzr annotate" still shows that the changes attributed to revision
> > 99634.2.937 were made in 103939.1.41, not in 104201 nor in 99634.2.937:
> 
> Haven't we been over this before?
> 
> http://lists.gnu.org/archive/html/emacs-devel/2011-01/msg00609.html

Yes.  My memory is limited to the last 5 months.  Besides, _you_ have
been over this back then, not me.

Anyway, the side effects of this never cease to surprise me.

Re: Confusing "bzr log" as result of merges

[Glenn Morris]

Eli Zaretskii wrote:

> Yes.  My memory is limited to the last 5 months.  Besides, _you_ have
> been over this back then, not me.

I also can't remember all these VCS discussions; I just have the
impression that most things that can be said about bzr, have been, and a
search usually turns it up. Eg, turns out I was just repeating you:

http://lists.gnu.org/archive/html/emacs-devel/2010-12/msg00504.html

Re: Confusing "bzr log" as result of merges

[Juanma Barranquero]

> One thing fundamentally wrong with the current practice is that emacs-23
> ends with a mostly clean VC history while trunk accumulates all the mess
> created by cherry-picks. emacs-23 will eventually die, but trunk is
> supposed to live forever.

I couldn't agree more. We should commit to the trunk and then decide
what gets backported to emacs-23.

    Juanma

Re: Confusing "bzr log" as result of merges

[Stefan Monnier]

> With the current trunk, type this command:
>   bzr log -l1 --line --include-merges src/xdisp.c
> You will see this as output:
>   104201: Glenn Morris 2011-05-12 [merge] Merge from emacs-23; up to r100577.
> However, neither "bzr status" nor "bzr diff" will show any changes for
> xdisp.c in that revision.  The reason, it seems, is this:
[...]
> What can we do to avoid this confusion as result of merges?

Easy: if it hurts, don't do it.
The log command you used does not tell you "the latest revision that
changed src/xdisp.c", so if you're looking for this latest revision, use
something else, like bzr annotate.

You can complain about the way we do current emacs-23 merges, but these
aren't really special (even though we use a few hacks in bzrmerge.el,
these are just to help resolve some of the conflicts that would arise
from a plain "bzr merge").

The same kind of problems will show up with many other merges.
The problem is not in the way those branches were handled or how the
merge was done: the problem is that the request you use will not tell
you quite what you're looking for (although it may occasionally do).


        Stefan

Re: Confusing "bzr log" as result of merges

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org
> Date: Sun, 22 May 2011 11:14:40 -0300
> 
> > With the current trunk, type this command:
> >   bzr log -l1 --line --include-merges src/xdisp.c
> > You will see this as output:
> >   104201: Glenn Morris 2011-05-12 [merge] Merge from emacs-23; up to r100577.
> > However, neither "bzr status" nor "bzr diff" will show any changes for
> > xdisp.c in that revision.  The reason, it seems, is this:
> [...]
> > What can we do to avoid this confusion as result of merges?
> 
> Easy: if it hurts, don't do it.

??? You mean, don't use one of the most useful and efficient commands
in bzr?

> The log command you used does not tell you "the latest revision that
> changed src/xdisp.c"

It does, in all other circumstances.  It just goes by the metadata,
not by source lines.

> so if you're looking for this latest revision, use something else,
> like bzr annotate.

"bzr annotate" is dog slow, especially on a long and veteran file such
as xdisp.c, even if you limit the range of revisions you ask it to
display.  "bzr log", by contrast, is very fast (unless you go fancy
about how you select revisions, e.g. with "-r annotate:").  Guess what
I prefer first and foremost.

You consistently dismiss complaints in this area for reasons I cannot
understand.  Just because you don't need these tools does not yet mean
they aren't important for others.  I need them a lot while hacking the
display engine, because there's no one here who can help me understand
why a particular piece of code was written; by digging into the
history and finding out who committed it and when, I can most of the
time find the answers and DTRT.  But these complications are a huge
time drain for me.  Some of them are probably water under the bridge,
because of the way the CVS repository was converted to Bazaar (I guess
the limited testing done back then was not thorough enough), but
others can be avoided.

> The same kind of problems will show up with many other merges.
> The problem is not in the way those branches were handled or how the
> merge was done: the problem is that the request you use will not tell
> you quite what you're looking for (although it may occasionally do).

I don't agree.  In general, all the possible ways of asking something
should give you the same answer, otherwise you cannot really trust the
tool.  The discrepancy here happens because bzrmerge.el plays unholy
games with the metadata as opposed to the sources.  If we need to do
this, let's do it on the branch, as others suggested, not on the
trunk.  Alternatively, we could apply to the trunk changes from the
branch as simple diffs, with Patch.  I don't see how any of these two
alternatives are worse or harder than what we currently have.

Re: Confusing "bzr log" as result of merges

[Stefan Monnier]

> tool.  The discrepancy here happens because bzrmerge.el plays unholy
> games with the metadata as opposed to the sources.  If we need to do

You are confused: the metadata resulting from bzrmerge.el is 100%
identical to the metadata resulting from "bzr merge".


        Stefan

Re: Confusing "bzr log" as result of merges

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org
> Date: Sun, 22 May 2011 16:15:45 -0300
> 
> > tool.  The discrepancy here happens because bzrmerge.el plays unholy
> > games with the metadata as opposed to the sources.  If we need to do
> 
> You are confused: the metadata resulting from bzrmerge.el is 100%
> identical to the metadata resulting from "bzr merge".

I don't think I'm confused that much: I said "metadata as opposed to
the sources".

Re: Confusing "bzr log" as result of merges

[Stefan Monnier]

>> > tool.  The discrepancy here happens because bzrmerge.el plays unholy
>> > games with the metadata as opposed to the sources.  If we need to do
>> You are confused: the metadata resulting from bzrmerge.el is 100%
>> identical to the metadata resulting from "bzr merge".
> I don't think I'm confused that much: I said "metadata as opposed to
> the sources".

Merging with bzrmerge.el instead of with "bzr merge" should result in
an absolutely identical result, except for the fact that the guy doing
the merge will have to do a bit less work.


        Stefan

Re: Confusing "bzr log" as result of merges

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org
> Date: Mon, 23 May 2011 09:02:37 -0300
> 
> >> > tool.  The discrepancy here happens because bzrmerge.el plays unholy
> >> > games with the metadata as opposed to the sources.  If we need to do
> >> You are confused: the metadata resulting from bzrmerge.el is 100%
> >> identical to the metadata resulting from "bzr merge".
> > I don't think I'm confused that much: I said "metadata as opposed to
> > the sources".
> 
> Merging with bzrmerge.el instead of with "bzr merge" should result in
> an absolutely identical result, except for the fact that the guy doing
> the merge will have to do a bit less work.

The problem is not that we are merging, but that we merge revisions we
don't need.  We then revert the effect of the merge in the sources,
but the metadata "remembers" that the reverted revision is in the
trunk.

Doing the same manually will obviously produce the same result, but my
point was why do it at all.

IOW, I'm not saying that bzrmerge.el is the culprit.  I'm saying that
the method we use to merge from emacs-23 (which is implemented by
bzrmerge.el) is the culprit.