Re: [lmi] Incidental differences on first commit and push of 2019

[Vadim Zeitlin]

On Wed, 9 Jan 2019 16:02:52 +0000 Greg Chicares <address@hidden> wrote:

GC> I didn't expect the line about a new ECDSA host key:
GC> 
GC> /opt/lmi/src/lmi[0]$git push
GC> Warning: Permanently added the ECDSA host key for IP address 
'209.51.188.201' to the list of known hosts.
GC> Enter passphrase for key [REDACTED]
GC> ...
GC> Writing objects: 100% (647/647), 188.07 KiB | 8.18 MiB/s, done.
GC> Total 647 (delta 611), reused 162 (delta 138)
GC>    f81b0c002..9c80545eb  master -> master
GC> 
GC> but apparently the explanation is that gnu.org's IP address changed
GC> on 2018-12-20:
GC>   https://savannah.gnu.org/forum/forum.php?forum_id=9330
GC> and this was my first push since then. The new IP really does seem
GC> to be for Hurricane Electric as the savannah announcement says:
GC> 
GC> $traceroute 209.51.188.201
GC> ... 100ge3-2.core1.bos1.he.net (184.105.64.54)  39.675 ms  41.614 ms 
kvmhost0.fsf.org (209.51.188.180)  42.182 ms
GC> 
GC> so everything seems fine.

 Hello (and happy new year!),

 This IP indeed seems to be fine and at the very least I can confirm that
I've retrieved your commits, with the same commit hashes, from it.

GC> It is probably even less noteworthy that I got this message:
GC>   Auto packing the repository in background for optimum performance
GC> from git when I committed a copyright update for every source file.
GC> There, the trigger might have been the large scope of that commit,
GC> which perhaps caused the number of loose objects to exceed 'gc.auto'.

 Indeed.

GC> Because it's a new year and I hadn't expected that "auto packing"
GC> message, I thought perhaps I should run git-fsck:
GC> 
GC> /opt/lmi/src/lmi[0]$git fsck
GC> Checking object directories: 100% (256/256), done.
GC> Checking objects: 100% (69407/69407), done.
GC> dangling commit 5ccfa062091e3f18b4848300d49c15e2cca60766

 It's a bit surprising to see this in your case as you don't use Git
branches often and the most common explanation of having dangling commits
is that they belong to a branch which has been deleted but not
garbage-collected yet. It's far from worrisome however.

 And, just for comparison, I ran git-fsck in my local mirror and had ~100
of dangling blobs and commits, which made me realize that I didn't run
git-gc in it since a long time (or maybe even ever) and I did it to gain
some disk space:

        [lmi(master)]% du -sh .git
        125M    .git
        [lmi(master)]% g gc --prune=now
        Enumerating objects: 65581, done.
        Counting objects: 100% (65581/65581), done.
        Delta compression using up to 8 threads
        Compressing objects: 100% (25866/25866), done.
        Writing objects: 100% (65581/65581), done.
        Total 65581 (delta 45405), reused 58752 (delta 39622)
        [lmi(master)]% du -sh .git
        23M     .git

You could do the same thing if you'd like, this should be totally safe (if
you look on the web, people also usually recommend to force expiry of all
reflogs before running git-gc, but this might be not a good idea, so you
should only do this if you're really sure you won't need to recover any
relatively recent changes).

GC> /opt/lmi/src/lmi[0]$git show 5ccfa062091e3f18b4848300d49c15e2cca60766
GC> commit 5ccfa062091e3f18b4848300d49c15e2cca60766
GC> Author: Vadim Zeitlin <address@hidden>
GC> Date:   2018-08-27T19:41:07+00:00
GC> 
GC>     Install wxPdfDocument using Git instead of snapshot download
GC> 
GC> I don't know why that commit would be dangling, but apparently
GC> it has been applied in some way, perhaps here:
GC> 
GC> /opt/lmi/src/lmi[0]$git log --grep 'Install wxPdfDocument'
GC> commit 05a4a41aeb0273aaed7dc1bf8c872764d5ea50b7
GC> Author: Gregory W. Chicares <address@hidden>
GC> Date:   2015-08-07T00:25:15+00:00
GC> 
GC>     Install wxPdfDocument library as part of lmi installation

 FWIW the original 5ccfa062091e3f18b4848300d49c15e2cca60766 commit was part
of github/install-wxpdfdoc branch. The new commit is not exactly the same,
but I do think that the old one was subsumed by it.

GC> ...so I suppose I should just ignore it and wait for git to
GC> clean it up automatically someday.

 Yes, or you can trigger it explicitly if you'd like to.

 Best regards,
VZ