GNU bug report logs - #12869
24.3.50; 'semantic-change-function' and incremental parsing broken by 'define-obsolete-variable-alias' problems

Previous Next

Full log

View this message in rfc822 format

From: Nix <nix <at> esperi.org.uk>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 12869 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: bug#12869: 24.3.50; 'semantic-change-function' and incremental parsing broken by	'define-obsolete-variable-alias' problems
Date: Mon, 12 Nov 2012 19:01:59 +0000

On 12 Nov 2012, Eli Zaretskii said:

>> From: Nix <nix <at> esperi.org.uk>
>> Emacs: because one operating system isn't enough.
>> Date: Mon, 12 Nov 2012 17:35:39 +0000
>> Cc: 12869 <at> debbugs.gnu.org
>> 
>> > I've changed the code (in emacs-24) to use the new name instead of the
>> > old one, which I believe should fix this problem.
>> 
>> That means I need to learn enough about bzr to figure out how to get at
>> that change, doesn't it. I was hoping to avoid that, bzr makes my head
>> spin in a most unpleasant way.
>
> Like this:
>
>   bzr log --line -l N  # shows the last N commits one per line
>   bzr diff -c REVNO    # produces diffs for revision REVNO
>
> where REVNO is the number of the revision you find by looking at the
> output of the first command.

Sure, that'll give me a log of the branch I'm on. But I'm on the trunk,
not the emacs-24 branch -- can I really not get a log of the branch
without waiting for hours as bzr pulls the whole thing down from
upstream again? I mean, this branch is 99% the same as trunk: isn't
there a way to reuse the revisions or something?

-- 
NULL && (void)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.