GNU bug report logs - #8675
lisp_string_width and strings wider than INT_MAX

Previous Next

Full log

Message #17 received at 8675 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 8675 <at> debbugs.gnu.org
Subject: Re: bug#8675: lisp_string_width and strings wider than INT_MAX
Date: Mon, 16 May 2011 09:37:07 -0700

On 05/16/11 00:57, Eli Zaretskii wrote:
> When you merge, could you please make the texinfo.tex update a
> separate commit on the trunk, then?  No one will ever expect to find
> that file in a commit logged as "sync from gnulib", which will make
> forensics more difficult than it needs to (since your commits are
> always merge-commits).

Currently what I do is "make sync-from-gnulib" followed by
"bzr commit".  This is requesting that I go to more work, by
breaking up the merge from gnulib into smaller functional pieces,
one for each functional change in gnulib, and installing them
individually.

I'd rather not.  Not only would this be more work, it would
run contrary to other advice I've gotten, which is to batch
changes instead of installing lots of little changes one at a time.
Besides, I doubt whether including texinfo.tex confuses forensics much,
so it's not at all clear that the extra work would be an overall win.

Gnulib changes are like autogen changes.  They're mostly ignorable,
but if a problem comes up, one can do forensics by going to the
repository we're importing from and looking at its history.
When autotools change, we don't commit the resulting changes to
"configure" individually, and that's a similar situation.

Previous Next

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