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.


Michael Haggerty
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

Reply via email to