On Wed, Dec 17, 2014 at 3:51 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Stefan Beller <sbeller@xxxxxxxxxx> writes: > >> On Tue, Dec 16, 2014 at 11:46 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> >>>> + ( >>>> + cd upstream && git config receive.denyCurrentBranch warn >>>> + ) && >>> >>> I was wondering how you would do this part after suggesting use of >>> test_create_repo, knowing very well that one of them was a bare one >>> ;-). >>> >>> We might want to extend test_create_repo to allow creating a bare >>> repository, but this is also OK. >> >> So I searching through all the tests, where it would make sense to do that. >> I searched for "denyCurrentBranch" and came up with this list where I think >> it makes sense to replace (git init | test_create_repo | or alike) by a >> test_create_repo_bare or add the --bare option to test_create_repo >> >> places where test_create_repo_bare is easily introducable: >> t5517-push-mirror.sh # setup an upstream repo >> t5543-atomic-push.sh # setup an upstream repo >> t5701-clone-local.sh # Test 'clone empty repository' >> >> not as easy: >> t5400-send-pack.sh # we commit to that repo while being inside >> t5405-send-pack-rewind.sh # we commit to that repo while being inside >> t5516-fetch-push.sh # we test the various denyCurrentBranch options >> >> unsure: >> t5522-pull-symlink.sh # just cloning the repo >> >> So I think we don't need the test_create_repo_bare yet. > > Thanks for digging. > > We already knew we do not *NEED* it. We have been surviving without > one. > > You need to remember that adding and using a new helper is *NOT* the > ultimate goal; categorizing those that do not want bare repositories > as "not as easy" is misguided. They truly do not want bare, so they > are not our target audience in the first place. For the same reason, > "easily introduceable" is not a good criteria to look for. > > The issue is if some existing tests will be helped, if we had such a > helper. That is, do we "git init --bare" by hand in some test? Are > these tests in such a hand-crafted repositories more susceptible to > future breakages because they do not use the template from the built > location or they do not disable hooks? If we had such tests, then > they would benefit by having a "bare" mode of test_create_repo. > > You're right, I was looking at the wrong criteria. There are rougly 125 " --bare" outside outside of the t0001-init.sh and t5601-clone.sh which are not relying on the template nor the $GIT_EXEC_PATH/git-init The occurrences outside these two tests are mostly init and clone with --bare although we also have a few "git --bare foo" commands to operate on the bare repos. Looking at it the other way round it seems to be more work to fix it. :/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html