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

Salikh Zakirov <salikh@gmail.com> writes:

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.