Ralf Thielow <ralf.thie...@gmail.com> writes:

> - handle --mirror option (test added)

Handle how?  I personally think erroring out is the right way to
handle it, but if we care about people who have been misusing the
combination of single and mirror, the second best way would be to
imply "mirror" and "single" combination as "bare" and "single"
without "mirror".

> - install correct refspec if the value of --branch is a tag (test added)

What is the definition of "correct"?  I see the documentation says
"--branch can also take tags and treat them like detached HEAD", and
even though I _think_ allowing tags was a huge mistake, if we claim
we treat it like detached HEAD, we should do the same when coming up
with the refspec used for the follow-up "fetch".

Whatever we decide to do, the semantics we decided to use at least
need to be described in the commit log message, not just in the
"changes from the previous iteration".  Updating the
"Documentation/git-clone.txt" would also be necessary.

> +test_expect_success 'refspec contains all branches by default' '
> +     echo "+refs/heads/*:refs/remotes/origin/*" > expect &&
> +     git --git-dir=dir_all/.git config --get remote.origin.fetch > actual &&
> +     test_cmp expect actual
> +'

I still think these checks that know the current implementation
details (i.e. what exact configuration variables get what exact
values) are wrong thing to have in the longer term.  If the desired
behaviour (i.e. "later fetch do not screw up") can be tested
directly like the later parts of the test in this patch does, how
that desired behaviour is implemented should not have to be cast in
stone with these tests.
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