Salikh Zakirov <salikh@xxxxxxxxx> 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.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html