Thread (1 message) 1 message, 1 author, 2016-06-15
DORMANTno replies

[PATCH 1/3] t4150-am: refactor and clean common setup

From: Remi LESPINET <hidden>
Date: 2016-06-15 23:05:03

Eric Sunshine [off-list ref] writes:
Paul Tan [off-list ref] writes:
quoted
quoted
Remi LESPINET [off-list ref] writes:
+       tmp_name=${2-"temporary"}
I don't think the quotes are required. Also, I don't feel good about
swapping the order of the arguments to git-checkout. (or making $2 an
optional argument). As the patch stands, if I see

setup_temporary_branch lorem

I will think: so we are creating a temporary branch "lorem". But nope,
we are creating a temporary branch "temporary" that branches from
"lorem". I don't think writing setup_temporary_branch "temporary"
"lorem" explicitly is that bad.
In fact, the second argument is never used in any of the three
patches, so it seems to be wasted functionality (at this time). If so,
then an even more appropriate name might be new_temp_branch_from().
Clearly, then:

    new_temp_branch_from lorem
Considering your two comments about the name of the function I think
removing the possibility of using the second argument and renaming the
function new_temp_branch_from gets everyone to agree since it has not
the possible confusion with git-checkout problem.
This is confusing. The commit message seems to advertise this patch as
primarily a refactoring change (pulling boilerplate out of tests and
into a new function), but the operation of that new function is
surprisingly different from the boilerplate it's replacing: The old
code did not create a branch, the new function does.

If your intention really is to create new branches in tests which
previously did not need throwaway branches, then the commit message
should state that as its primary purpose and explain why doing so is
desirable, since it is not clear from this patch what you gain from
doing so.

Moreover, typically, you should only either refactor or change
behavior in a single patch, not both. For instance, patch 1 would add
the new function and update tests to call it in place of the
boilerplate; and patch 2 would change behavior (such as creating a
temporary branch).

On the other hand, if these tests really don't benefit from having a
throw-away branch, then this change seems suspect and obscures the
intent of the test rather than clarifying or simplifying.
The purpose of this patch was originally to eliminate some test
dependancies introduced by the checkouts relative to HEAD (which
caused "cascade failure") and avoid creating branches, whose name
can't be reused, but you're right, that may not benefit as much as I
expected...  Perhaps I should have make tags from branches used as
start points, which would have done the same effect as these temporary
branches.
quoted
        sed -n -e "3,\$p" msg >file &&
        head -n 9 msg >>file &&
        git add file &&
@@ -303,10 +297,8 @@ test_expect_success 'am -3 -p0 can read --no-prefix patch' '
 '

 test_expect_success 'am can rename a file' '
+       setup_temporary_branch lorem &&
        grep "^rename from" rename.patch &&
-       rm -fr .git/rebase-apply &&
-       git reset --hard &&
-       git checkout lorem^0 &&
In other cases, you insert the setup_temporary_branch() invocation
where the old code resided. Why the difference in this test (and
others following)?
This doesn't affect the result of the test (assuming
setup_temporary_branch doesn't fail). I preferred to add the setup
before anything else in the test.  It affects efficiency in case the
rename patch has not the correct syntax. So it may be better to put the
grep as the first instruction to avoid evaluating all the test in case
the syntax of the patch is not correct.

Thanks a lot for your comments, I'll correct the patch asap !
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help