[GNC-dev] Significance of 18:59:00 in GnuCash 2.6.21 and altering of existing data

Kevin Buckley kevin.m.buckley at gmail.com
Mon May 4 06:30:28 EDT 2020

Wonder if I could ask a couple of related questions about 2.6.21,
before letting you get back to working on the current version.

Because of your suggestion that there might be some back-portable
changes, I checked out a local copy of the Gnucash Git repo's
default branch "maint" and then reverted to the state at the
2621a tag, or

commit 868489b1c4f9b1f64fe61130e6ae28b4bad16f22
Author: John Ralls <jralls at ceridwen.us>
Date:   Tue Apr 10 09:52:02 2018 -0700

    Fix typo.

so as to start from what appeared to be the last identifiable
commit for the 2.6 series.

In coming to use that commit though, I found a couple of inconsistencies.

I did the following

./configure --various-options
make dist-bzip2

and that generated a gnucash-2.6.21.tar.bz2 file. So far, so good.

In looking to compare the contents of my tarball, with the
official gnucash-2.6.21.tar.bz2 file, however, I've noticed
a few differences.

Some I can explain away as products of my autotools versions
being different but others, such as this one,

$ diff GIT/gnucash-2.6.21/src/core-utils/gnc-vcs-info.h \
< #define GNUCASH_SCM_REV "868489b+"
> #define GNUCASH_SCM_REV "868489b1c+"

where the Git hash is the same, but differs in length, are
harder to account for.

That hash, as I'm sure you will know, comes from running

  util/gnc-vcs-info -r .

inside a Git working directory which, in turn is doing a
pretty (no pun intended) bog standard

   git log -1 --pretty=format:"%h" HEAD

and then adding the plus (+) if any files in the repo are
seen to have been altered.

Clearly, files get altered as part of making a dist-zip2
target because my source dir was prstine.

Do different Git-s have different short hash lengths ?

The second case is wierder still, in that I notice, for

$ diff GIT/gnucash-2.6.21/src/gnc-module/swig-gnc-module.c \

... stuff above ...
<         found=1;
<         break;
>         /* Our module is already in the list, so there's nothing more to do. */
>         return;
<     /* if the is found in the list, then all is done and we may leave */
<     if (found) return;
<     /* otherwise we must add out module into the list */
>     /* otherwise we must add our module into the list */

Initially, given the swig in the file name, I had almost allowed for the
differences as resulting from different swig versions but, on closer
inspection, noted the different text, including the fixing up of the
".. add out module ..." text, to the correct "... add our module ..."

Howver, I can't find that change in the repo, as in, I did a git log
against the


file, having checked out the most recent commit on the maint branch,
and the file alwasy has the uncorrected "out" not "our" in it.

Does that mean that the official 2.6.21 tarball wasn't built against
the commit with the hash that is visible in the autogenerated file


or that it was, but there are some uncommited changes that I can't
now access within Git, applied before the build?

If the latter, they seen pretty substanstial, so, were they ever
commited into the Git repo anywhere ouside of the maint branch?


More information about the gnucash-devel mailing list