Re: [lmi] [PATCH] Add script allowing to install any wxWidgets version from Git

[Vadim Zeitlin]

On Mon, 9 Apr 2018 22:50:54 +0000 Greg Chicares <address@hidden> wrote:

GC> I think I already had a valid high-level conceptual map, and just needed
GC> to figure out the physical realization. It helped to put some temporary
GC> printf statements into the script, revealing:
GC> 
GC>   wx_git_url =                    https://github.com/wxWidgets/wxWidgets.git
GC> subpath 3rdparty/catch --> suburl https://github.com/wxWidgets/Catch.git
GC> subpath src/expat      --> suburl https://github.com/wxWidgets/libexpat.git
GC> subpath src/png        --> suburl https://github.com/wxWidgets/libpng.git
GC> subpath src/zlib       --> suburl https://github.com/wxWidgets/zlib.git
GC> 
GC> So github hosts bare repositories of all the submodules as siblings of wx,
GC> and wx's .gitmodules maps them to subdirectories. All I have to do is make
GC> my own directory that looks like 'https://github.com/wxWidgets/*.git'.

 Yes, exactly.

GC> Initial setup:
GC> 
GC> cd /srv/cache_for_lmi
GC> mkdir vcs
GC> cd vcs
GC> git clone --mirror https://github.com/wxWidgets/wxWidgets.git
GC> git clone --mirror https://github.com/wxWidgets/Catch.git
GC> git clone --mirror https://github.com/wxWidgets/libexpat.git
GC> git clone --mirror https://github.com/wxWidgets/libpng.git
GC> git clone --mirror https://github.com/wxWidgets/zlib.git

 I don't think you need to use --mirror here, just --bare would be fine, as
you don't intend to track all the branches in wxWidgets repository, and, as
seen below, it actually results in some problems.

GC> Subsequently, to keep everything updated, I'll do something like:
GC>   for z in *.git; do pushd $z; git fetch; popd ; done

 Yes.

GC> Because I used '--mirror', the 'fetch' refs are already set:
GC> 
GC> /srv/cache_for_lmi/vcs/wxWidgets.git[0]$grep fetch config
GC>         fetch = +refs/*:refs/*

 So it fetches everything under refs, which is too much.

GC> I'm not sure what git-fetch options to use, if any. I tried '--all':
GC> 
GC>   /srv/cache_for_lmi/vcs/wxWidgets.git[0]$git fetch --all
GC>   Fetching origin
GC>   remote: Counting objects: 26, done.
GC>   remote: Compressing objects: 100% (18/18), done.
GC>   remote: Total 26 (delta 20), reused 12 (delta 8), pack-reused 0
GC>   Unpacking objects: 100% (26/26), done.
GC>   From https://github.com/wxWidgets/wxWidgets
GC>    + 807c963bd9...69fec9c26c refs/pull/280/merge -> refs/pull/280/merge  
(forced update)
GC> 
GC> "forced update"? Was '--all' too much?

 No, --all is not to blame, it just means to fetch from all the remotes,
but you have just a single remote (the GitHub one you cloned from, called
"origin" by default), so you could just as well omit it.

 Instead, the remote ref pull/280/merge was really changed, i.e. updated
and not fast-forwarded. I have no idea about why did this happen to be
honest, as 280 is a very old PR closed since almost 2 years. But I don't
see anything really surprising about _some_ PR changing, while all the
public branches (master, WX_3_0_BRANCH etc) are never supposed to be
force-pushed to (and if it ever happens, it would be a bad mistake -- but
luckily it hasn't happened so far), it's perfectly fine to update a PR in
progress by force-pushing to it. So fetching all the refs will result in
such "forced update" messages regularly.

 Now, it's not really a problem on its own. It's true that it will create
dangling commits (because the previous tip of the branch won't be
referenced by anything else after the branch was forcibly reset to point to
another commit which is not an ancestor of the old one), but these commits
will be cleaned up by "git fsck" sooner or later. However it's arguably
still better to avoid fetching all these changes that you don't care about.

GC> Should I simply ignore any "dangling commit"? Should I run git-gc?

 You can ignore dangling commits and you can run git-gc, but it will also
be run automatically when needed, so it's not necessary unless you really
want to optimize the disk space. But to avoid all this, you can just redo
the clone without using --mirror (actually you can edit your existing
.git/config without re-cloning, but I suspect it will be simpler to redo
the clone than make these changes) and then you wouldn't have to deal with
all these changes to the refs you don't care about at all.

 Regards,
VZ