-
Notifications
You must be signed in to change notification settings - Fork 280
Open
Labels
Description
I'm using pre-commit hooks in my git project that validate code style and syntax (for puppet manifests). I noticed that this can break a git subrepo clone if the cloned repo itself contains i.e. unlinted stuff (and makes cloneing incredible slow, this example took 30s until failing).
--- git/leap_platform ‹subrepo› » time git subrepo clone -v git@gitlab.com:shared-puppet-modules-group/mod_security puppet/modules/mod_security
* Determine the upstream head branch.
* Fetch the upstream: git@gitlab.com:shared-puppet-modules-group/mod_security (master).
* Fetch 'git@gitlab.com:shared-puppet-modules-group/mod_security' (master).
* Get the upstream subrepo HEAD commit.
* Create subrepo remote 'subrepo/puppet/modules/mod_security' -> 'git@gitlab.com:shared-puppet-modules-group/mod_security'.
* Create ref 'refs/subrepo/puppet/modules/mod_security/fetch'.
* Make the directory 'puppet/modules/mod_security/' for the clone.
* Commit the new 'puppet/modules/mod_security/' content.
* Check that '222d510075b3869e2b78ea70b23780602267317b' exists.
* Make sure '222d510075b3869e2b78ea70b23780602267317b' contains the upstream HEAD.
* Put remote subrepo content into 'puppet/modules/mod_security/'.
* Put info into 'puppet/modules/mod_security/.gitrepo' file.
* Commit to the 'subrepo' branch.
git-subrepo: Command failed: 'git commit -m git subrepo clone git@gitlab.com:shared-puppet-modules-group/mod_security puppet/modules/mod_security
subrepo:
subdir: "puppet/modules/mod_security"
merged: "222d510"
upstream:
origin: "git@gitlab.com:shared-puppet-modules-group/mod_security"
branch: "master"
commit: "222d510"
git-subrepo:
version: "0.3.0"
origin: "https://github.com/ingydotnet/git-subrepo.git"
commit: "cb2995b"'.
git subrepo clone -v git@gitlab.com:shared-puppet-modules-group/mod_security 6.26s user 0.54s system 22% cpu 30.466 total
issueing git commit -m "git subrepo clone git@gitlab.com:shared-puppet-modules-group/mod_security puppet/modules/mod_security" showed me that it ran the pre-commit hook on every file and failed because of unlinted stuff.
Using git commit --no-verify worked for me with this patch:
--- git/git-subrepo ‹master* M› » git diff
diff --git a/lib/git-subrepo b/lib/git-subrepo
index 3c6f575..a121320 100755
--- a/lib/git-subrepo
+++ b/lib/git-subrepo
@@ -778,7 +778,7 @@ subrepo:commit() {
o "Commit to the '$original_head_branch' branch."
if [[ $original_head_commit != none ]]; then
- RUN git commit -m "$(get-commit-message)"
+ RUN git commit --no-verify -m "$(get-commit-message)"
else
# We had cloned into an empty repo, side effect of prior git reset --mixed
# command is that subrepo's history is now part of the index. Commit
So I'm wondering what to do here, I see three options:
- always use
git commit --no-verify - an optional parameter to
git subrepo clonelike--no-verify - or an even more generic parameter like
--git-commit-optionsthat is passed directly togit commit
JacopKane, poppolopoppo and tennox