Re: [PATCH] git-ssh-pull: commit-id consistency

From: Daniel Barkalow <barkalow@iabervon.org>
Date: 2005-06-27 06:11:50
On Sun, 26 Jun 2005, Sven Verdoolaege wrote:

> I thought about keeping the check for a leading dot or slash,
> but then I figured that you'd get an error from the other
> side pretty quickly.
> 
> skimo
> --
> In contrast to other plumbing tools, git-ssh-pu{sh,ll} only
> allow a very restrictive form of commit-id filenames.
> This patch removes this restriction.

There are a few problems with this: not all pull methods can handle
vagueness; HTTP, for instance, needs to know exactly what URL to request,
and it can't deal with having the user request just anything. Also, it's
not particularly useful to support just anything as the hash to start
from, when you have to specify exactly the file to write the ref to (the
-w argument), which would be a lot more difficult and flaky, because we
can't just look for the only thing that works.

More generally, I think we should require explicit instructions, even when
we might be able to figure things out, when we're moving data between
repositories, similar to how we are strict about the data stored in
repositories (although, of course, we need to support a few more cases).

In addition, I think that stuff outside of objects/ and refs/ (and, when
we have something in it, info/) should be considered private, and not
transmitted from place to place.

One thing that might be a good idea, however, is to allow using symlinks
from .git/ to refs/<x>/<y> on the local side of git-ssh-push by converting
them to <x>/<y>. That way, when you push "HEAD", it will actually push
refs/heads/my-current-branch instead. Of course, the -w issue remains,
because you may have different names on the other side (i.e., on the local
side, it might be refs/heads/new-diff-algo, but the remote side might be
refs/heads/my-latest).

Really, the right solution is to keep this sort of info somewhere and have 
scripts do the right thing with exact specifications.

	-Daniel
*This .sig left intentionally blank*

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Received on Mon Jun 27 06:13:57 2005

This archive was generated by hypermail 2.1.8 : 2005-06-27 06:14:00 EST