_verifyRefPresent was also broken for tag-based checkouts. Since this
already uses determinePreferredCheckoutSource, which already used
refs/tags/ for tags, this code also doubled-up on tag names.
This whole code path would be a great candidate for that test suite
under t/ if I can ever get it polished up one day :(
To avoid commit spam, I've tested this on my own Qt module directories
by deleting them and forcing them to be checked-out with tags.
Turns out the original code was doubly-broken, since
determinePreferredCheckoutSource was already adding refs/tags/ to
returned git tags.
Rather than possibly breaking other users of that function by removing
it there, instead strip off refs/tags/ during clone if present.
git-clone doesn't like this value as an option to --branch/-b. Instead
just leave it as a plain tag name and hope it doesn't conflict with any
branch names.
Perl seems to have settled on the 'parent' module instead of manually defining
variables that tell the interpreter which packages to fall back to. Some
classes now use parent, some still use the old way.
Migrate everything over to be consistent.
Maintains a user-friendly improvement from a few years back to make it
easier to use module-sets to grab a wide set of modules without having
to disable individual modules that weren't present at that time.
This should be unnecessary for new clones (git does have an option to
not pull tags however). More importantly it's actually broken (we need
to cd into the newly cloned directory if we want to do it anyways).
This option can be used to setup the user.name and user.email git-config
options within each new git repository cloned or installed from
snapshot, including kde-projects repositories. This can be useful for
KDE developers with multiple Git identities that they use for
development.
Module settings override global settings so you could e.g. have a global
git-user option for KDE modules and then override specific modules or
module-sets with a different git-user setting.
This setting is only applied during the initial git-clone process
though... if there's interest in having kdesrc-build re-apply settings
later that's possible too.
BUG:352478
FIXED-IN:15.09
When the initrepo script fails the extracted snapshot directory (the
srcdir) is deleted, but it's also the current working directory, which
breaks git when doing the fallback clone. Fix by switching to an
existing directory.
CCMAIL:faure@kde.org
Perl core includes a "HTTP::Tiny" module that does what little we need,
and has had it since 5.14 or so, so prefer that instead and remove the
requirement to install libwww-perl.
This also required removing the one minor instance of the URI module,
which is not technically in Perl core but was installed due to LWP.
Instead we just use a regexp 'blessed' by the URI module author.
There seems to be nothing better than checking for the existence of
files or directories under .git at this point (though it's possible to
decode git-status --porcelain output without too much trouble in the
case of in-progress merges).
This should hopefully help avoid kdesrc-build trying to update a module
that is being worked on.
BUG:334324
FIXED-IN:1.16
Bug 341159 complains about kdesrc-build-setup not setting up the kde:
git prefix, but kdesrc-build-setup itself never even calls git, it just
creates a .kdesrc-buildrc and exits.
However the currently recommended way to start out kdesrc-build is to
run "kdesrc-build --metadata-only" for the first build to setup
directories and download required data, while still letting a subsequent
"kdesrc-build --pretend" do something useful. kdesrc-build didn't setup
the kde: prefix in time to support --metadata-only, and I'm willing to
bet that's what the user was encountering here.
So, setup the git configuration before the first time we can use git.
BUG:341159
FIXED-IN:1.16
Fixes bug 342806, where a kdesrc-build user notes that "Cloning"
messages are indented while "Updating" messages are not, which can be
confusing.
BUG:342806
FIXED-IN:1.16
We use a mix of error codes and raw exceptions in the git updater.
Fix this to use the exception objects used elsewhere (and which give
better error messages).
This also simplifies the code by removing error code returns from some
internal functions whose return value is then just converted into an
exception anyways. Easier just to throw the exception directly and
simplify the higher-level functions.
The one nuance here is that installing a git snapshot can fail yet that
should not cause an exception, we'd just fallback to doing a normal
git-clone.
Before this we would try to apply branch-group to a module, it would
fail (since plain git modules don't *have* any kde-projects metadata),
and we would invariably select master instead of choosing based on the
plain git module's branch option.
Note that this still doesn't solve the problem of modules that are from
kde-projects but *don't* have branch-group metadata; if both module
branch-group and global branch are active for such a module, the
module-specific branch-group will be tried and resolve to 'master'
independent of the global branch setting.
Whether this is a feature or not is not yet certain. :)
Now the priority order for all of the various "I want to checkout this
commit" options are centralized in one spot, and both cloning and
updating obey the same options now (they didn't before).
We need a better name for this feature.
But basically, this allows for creating kde-project repository-wide
"branch groups". For instance, you could list the git branch to use for
the "stable Qt/KDE 4" release/maintenance branch, the "new development
Qt/KDE 4" development branch (typically master, but that has been
changing), and the "upcoming next major release" branch (for us, this
means 'frameworks' sometimes, means 'master' sometimes, other modules
may have different ideas).
By using the 'branch-group' option (which remains to be further
documented) you can say that you want to defer to the metadata about the
repository branches stored in
kde-build-metadata/logical-module-structure. kdesrc-build should even
track branches for you as they are updated by the Release Team, if you
simply want to hang out on stable but compile your own stuff.
Note that this support requires Perl's JSON module (which should come
with Perl 5.14 if I understand it right, but you probably want to
install JSON::XS from CPAN). JSON support is only required for this
feature, it is not a new overall dependency.
See also: http://community.kde.org/Infrastructure/Project_Metadata
Though this only works for Git modules, it should at least fix the
annoying "OMG YOUR REPO MOVED" warnings that never get fixed when in
async mode (which is the default).
Previously you simply never saw the warning due to the now-fixed output
squelching, now we need to fix this for good as well.
This should fix the big ugly error messages for this particular
scenario. The code in question is trying to determine a good branch name
that it can use, which means it need to verify that the requested branch
name *doesn't* exist. This would correspond to an exit code of 1 for the
given git command.
In pretend mode all safe_system() calls give an exit code of 0, so it
appears that there are no safe unused branch names.
Since even in pretend mode the source directory should exist in this
code path I switched to use a system() call (with the correct full
branch name to boot).
I'm not sure the other part of the bug is fixed (i.e. checking out a
local branch immediately after cloning or whatever dfaure was seeing) so
I'll leave open for now until I can do further testing.
CCBUG:311758
This can be used as a run-time check later to ensure that kdesrc-build
finds compatible versions of its component modules (though that isn't
done yet).
This is probably the most dangerous change up to this point just because
a lot of modules descend from GitUpdate. I've run 'ack' on the source
tree just to make sure I didn't miss any renames from other modules at
this point. I've also built a kde-project module (which uses the new
ksb::Updater::Git indirectly) and it looks like everything still works
fine.
Michael Pyne