Re: [PATCH] Make git-clone --use-separate-remote the default

Salikh Zakirov [off-list ref] writes:

I think that remote matching semantics is confusing, and the following change
would make understanding easier.

Hmm.  I think this is somewhat wrong.

Have you tested the patch with repositories with existing refs?

You do not seem to check if that fabricated matched_dst exists
on the other side, so matched_dst lacks "where was this ref
initially" information (aka old_sha1), if I am reading your
patch correctly.  Wouldn't that mean that you would confuse the
fast-forward check logic?

One setup I have that would be broken with this change is that
the remote end has refs/heads/up/obsd and no refs/heads/obsd,
and local end has refs/heads/obsd.  This is to work on
portability fix for OpenBSD.  With the current git-push, I think

	git push $remote_openbsd_box obsd

would correctly update the remote refs/heads/up/obsd with the
local tip of the obsd branch, so that then I can ssh into the
remote and say "git merge up/obsd" to continue on that OpenBSD
machine from where I left off on the local, non-OpenBSD machine.

I am not sure if people would mind breaking existing setups like
this.

By the way, there are other glitches with the current git-push
(rather, git-send-pack) that we need to tighten.  For example:

	git push $remote HEAD~6

does not error out as it should.  'HEAD~6' is expanded to
'HEAD~6:HEAD~6'; its left hand side is valid (6 revs before the
tip is used to update the remote side) but its right hand side
is not checked for validity ("HEAD~6" is not a valid refname)
and creates .git/HEAD~6 at the remote end which is completely
bogus.