[v3,05/30] subtree: t7900: comment subtree_test_create_repo

Commit Message

Luke Shumaker April 27, 2021, 9:17 p.m. UTC

From: Luke Shumaker <[e-mail]>

It's unclear what the purpose of t7900-subtree.sh's
`subtree_test_create_repo` helper function is.  It wraps test-lib.sh's,
`test_create_repo` but follows that up by setting log.date=relative.  Why
does it set log.date=relative?

My first guess was that at one point the tests required that, but no
longer do, and that the function is now vestigial.  I even wrote a patch
to get rid of it and was moments away from `git send-email`ing it.

However, by chance when looking for something else in the history, I
discovered the true reason, from e7aac44ed2 (contrib/subtree: ignore
log.date configuration, 2015-07-21).  It's testing that setting
log.date=relative doesn't break `git subtree`, as at one point in the past
that did break `git subtree`.

So, add a comment about this, to avoid future such confusion.

And while at it, go ahead and (1) touch up the function to avoid a
pointless subshell and (2) update the one test that didn't use it.

Signed-off-by: Luke Shumaker <[e-mail]>
---
v2:
 - Also switch the few uses of vanilla test_create_repo over to
   subtree_test_create_repo.  In v1 this was erroneously included
   in a different commit.

 contrib/subtree/t/t7900-subtree.sh | 14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

Comments

Ævar Arnfjörð Bjarmason April 30, 2021, 9:48 a.m. UTC | #1

On Tue, Apr 27 2021, Luke Shumaker wrote:

> It's unclear what the purpose of t7900-subtree.sh's
> `subtree_test_create_repo` helper function is.  It wraps test-lib.sh's,
> `test_create_repo` but follows that up by setting log.date=relative.  Why
> does it set log.date=relative?
>
> My first guess was that at one point the tests required that, but no
> longer do, and that the function is now vestigial.  I even wrote a patch
> to get rid of it and was moments away from `git send-email`ing it.
>
> However, by chance when looking for something else in the history, I
> discovered the true reason, from e7aac44ed2 (contrib/subtree: ignore
> log.date configuration, 2015-07-21).  It's testing that setting
> log.date=relative doesn't break `git subtree`, as at one point in the past
> that did break `git subtree`.

This commit message is too much about describing the journey IMO. We
could just get straight to the point, e.g. something like:

    Add a comment about why the git-subtree.sh tests set
    log.relative. It's to test that we don't have a regression of the
    bug fixed in e7aac44ed2 [...].

FWIW I think just having an isolated test for this would be better, but
since you're just refactoring existing code I think this is fine.

I.e. we'd use "git init" in the rest, and just have a test that stresses
this specifically. Or is the entry into git-subtree.sh so varied that we
need to "fuzz" all the tests like this to fully test it? I haven't
checked.

Luke Shumaker April 30, 2021, 4:13 p.m. UTC | #2

On Fri, 30 Apr 2021 03:48:36 -0600,
Ævar Arnfjörð Bjarmason wrote:
> On Tue, Apr 27 2021, Luke Shumaker wrote:
> > It's unclear what the purpose of t7900-subtree.sh's
> > `subtree_test_create_repo` helper function is.  It wraps test-lib.sh's,
> > `test_create_repo` but follows that up by setting log.date=relative.  Why
> > does it set log.date=relative?
> >
> > My first guess was that at one point the tests required that, but no
> > longer do, and that the function is now vestigial.  I even wrote a patch
> > to get rid of it and was moments away from `git send-email`ing it.
> >
> > However, by chance when looking for something else in the history, I
> > discovered the true reason, from e7aac44ed2 (contrib/subtree: ignore
> > log.date configuration, 2015-07-21).  It's testing that setting
> > log.date=relative doesn't break `git subtree`, as at one point in the past
> > that did break `git subtree`.
> 
> This commit message is too much about describing the journey IMO. We
> could just get straight to the point, e.g. something like:
> 
>     Add a comment about why the git-subtree.sh tests set
>     log.relative. It's to test that we don't have a regression of the
>     bug fixed in e7aac44ed2 [...].

OK, I'll reword it if I re-roll.

> FWIW I think just having an isolated test for this would be better, but
> since you're just refactoring existing code I think this is fine.
> 
> I.e. we'd use "git init" in the rest, and just have a test that stresses
> this specifically. Or is the entry into git-subtree.sh so varied that we
> need to "fuzz" all the tests like this to fully test it? I haven't
> checked.

I'd have to examine it a bit more to be sure, but I think that you're
right.  That as long as the test does a 'split' that creates new
commits, then just one test should be fine.

Patch

diff --git a/contrib/subtree/t/t7900-subtree.sh b/contrib/subtree/t/t7900-subtree.sh
index 2319c3fd1c..12b8cb03c7 100755
--- a/contrib/subtree/t/t7900-subtree.sh
+++ b/contrib/subtree/t/t7900-subtree.sh
@@ -13,12 +13,14 @@  TEST_DIRECTORY=$(pwd)/../../../t
 export TEST_DIRECTORY
 . "$TEST_DIRECTORY"/test-lib.sh
 
+# Use our own wrapper around test-lib.sh's test_create_repo, in order
+# to set log.date=relative.  `git subtree` parses the output of `git
+# log`, and so it must be careful to not be affected by settings that
+# change the `git log` output.  We test this by setting
+# log.date=relative for every repo in the tests.
 subtree_test_create_repo () {
 	test_create_repo "$1" &&
-	(
-		cd "$1" &&
-		git config log.date relative
-	)
+	git -C "$1" config log.date relative
 }
 
 create () {
@@ -242,8 +244,8 @@  test_expect_success 'merge the added subproj again, should do nothing' '
 '
 
 test_expect_success 'merge new subproj history into subdir/ with a slash appended to the argument of --prefix' '
-	test_create_repo "$test_count" &&
-	test_create_repo "$test_count/subproj" &&
+	subtree_test_create_repo "$test_count" &&
+	subtree_test_create_repo "$test_count/subproj" &&
 	test_create_commit "$test_count" main1 &&
 	test_create_commit "$test_count/subproj" sub1 &&
 	(