Re: [RFC PATCH 06/19] Factor ref updating out of fetch_with_import

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 29 Oct 2009, Sverre Rabbelier wrote:

> Also allow the new update_refs to actually update the refs set, this
> way the remote helper can set the value of previously unknown refs.
> 
> Signed-off-by: Sverre Rabbelier <srabbelier@xxxxxxxxx>
> ---
> 
> 	Daniel, if we can get wanted_peer_refs to keep HEAD as a
> 	wanted ref somehow this patch could be a lot simpler.

Actually, I think the problem is that builtin-clone will always default to 
setting up a refspec of "refs/heads/*:refs/remotes/origin/*", but that 
doesn't actually make any sense if the source repository isn't presented 
as having refs names like "refs/heads/*". The immediate problem that you 
don't get HEAD because it's a symref to something outside the pattern is 
somewhat secondary to the general problem that you don't get anything at 
all, because everything's outside the pattern.

I don't really think that presenting the real refs in refs/<vcs>/*, and 
having the list give symrefs to them from refs/heads/* and refs/tags/* 
really makes sense; I think it would be better to rework fetch_with_import 
and the list provided by a foreign vcs helper such that it can present 
refs with normal names (refs/heads/*, refs/tags/*, etc) if the foreign vcs 
has standards that correspond to branches and tags. Then "clone" would 
work normally.

Or, perhaps, there should be some other way of allowing git users to take 
advantage of foreign vcs standards; I don't have a good perspective on 
this, since I only presently use git and a foreign vcs without any useful
standards. But I think it should be such that the transport user sees as 
close as possible to a native git layout, and clone continues to rely on 
the layout being normal, instead of presenting a weird layout mapped into 
a normal layout or something like that and working around transport users 
not expecting this.

	-Daniel
*This .sig left intentionally blank*
--
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]