On 10/23/2013 08:36 PM, Junio C Hamano wrote:
> Michael Haggerty <mhag...@alum.mit.edu> writes:
>> "git fetch" was being used with contrived refspecs to create tags and
>> remote-tracking branches in test repositories in preparation for the
>> actual tests. This is obscure and also makes one wonder whether this
>> is indeed just preparation or whether some side-effect of "git fetch"
>> is being tested.
>> So use the more straightforward commands "git tag" / "git update-ref"
>> when preparing branches in test repositories.
>> Signed-off-by: Michael Haggerty <mhag...@alum.mit.edu>
>> t/t5510-fetch.sh | 8 ++++----
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>> diff --git a/t/t5510-fetch.sh b/t/t5510-fetch.sh
>> index c5e5dfc..08d8dbb 100755
>> --- a/t/t5510-fetch.sh
>> +++ b/t/t5510-fetch.sh
>> @@ -88,7 +88,7 @@ test_expect_success 'fetch --prune on its own works as
>> expected' '
>> cd "$D" &&
>> git clone . prune &&
>> cd prune &&
>> - git fetch origin refs/heads/master:refs/remotes/origin/extrabranch &&
>> + git update-ref refs/remotes/origin/extrabranch master &&
> As long as you have checked that our local 'master' should be at the
> same commit as the origin's 'master' at this point, I think this
> change is OK.
It doesn't matter what the reference points at; the only point of these
tests is to check whether branches that look like stale remote-tracking
branches are pruned or not by the later command.
> I wouldn't call the use of "very explicit, without any room for
> mistake" refspecs "contrived", though.
According to Wiktionary, contrived means "unnatural, forced".
When the goal is just to create a local reference whose contents are
irrelevant, "fetch" is not the first command that comes to my mind. It
brings a lot of unnecessary machinery to bear on such a trivial task.
Plus it is not very common in daily life to invoke "fetch" with a
complicated, asymmetic refspec like this. Because of that it cost me a
little extra time to convince myself that the "fetch" command wasn't
trying to do something more. In that sense it seems "contrived" to me.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html