Sergey Poznyakoff <gray <at> gnu.org.ua> writes: > > Also, it would be nice if you considered using git submodules, to make it > > easier to definitively track which commit of gnulib.git and paxutils.git you > > used when building tar releases. > > It's not critical to "enforce" it. The README-hacking says clearly that > we "do not make any efforts to accommodate older versions of > these packages", so that anybody wanting to fiddle with the git version > knowns he should always have latest versions around.
That's true when developing on top of the latest commit on upstream tar.git. But it is not the case when trying to recreate the state of an older label. For example, with coreutils, it is possible to 'git checkout v7.4; ./bootstrap' and have the gnulib submodule automatically reverted back to the proper commit that was in use at the time coreutils 7.4 was cut, even though gnulib has since changed; this is particularly handy when you realize that some of the changes in current gnulib.git (such as those to maint.mk) are incompatible with the contents of coreutils.git back in the 7.4 days. In other words, submodules are a nice way of documenting what has been tested to work, rather than making the developer manually guess which commit to use in paxutils.git and gnulib.git when playing with an older version of tar.git. It also means that 'git bisect' can be more powerful at automating a regression hunt. -- Eric Blake
