On Wed, 3 Aug 2005, Junio C Hamano wrote:
> This allows git-send-pack to push local refs to a destination
> repository under different names.

Looks good, except I was almost hoping for one modification:

> Here is the name mapping rules for refs.
> * If there is no ref mapping on the command line:
>  - if '--all' is specified, it is equivalent to specifying
>    <local> ":" <local> for all the existing local refs on the
>    command line
>  - otherwise, it is equivalent to specifying <ref> ":" <ref> for
>    all the refs that exist on both sides.
> * <name> is just a shorthand for <name> ":" <name>
> * <src> ":" <dst>
>   push ref that matches <src> to ref that matches <dst>.

In this format, "src" makes sense as a generic sha1_name, and _not_ 
necessarily limited to a ref-name.

IOW, there's really no reason to not allow

        git-send-pack .. dest .. <sha1>:dst-ref

where "<sha1>" may be something else than a ref (but a ref obviously ends 
up being one such thing).

For example, let's say that I've got stuff at the HEAD of my tree that I'm
not quite ready to push out yet, but I _do_ want to push out the parent of
the current head. I'd love to be able to just do

        git-send-pack parent $(git-rev-parse HEAD^):master

and there's no real reason why that syntax shouldn't just work: it's 
entirely logical to say "I want to push out the parent of my HEAD as 
'master' on the other end", and that's _exactly_ what the above says.


>   - It is an error if <src> does not match exactly one of local
>     refs.

I think "src" should just be seen as any random SHA1 name, and we should 
use "get_sha()" to convert it to a SHA1.

In contrast, "dst" is obviously a real ref name, and as such:

>   - It is an error if <dst> matches more than one remote refs.

makes sense.

That makes your next rule a bit iffy, though:

>   - If <dst> does not match any remote refs, either
>     - it has to start with "refs/"; <dst> is used as the
>       destination literally in this case.
>     - <src> == <dst> and the ref that matched the <src> must not
>       exist in the set of remote refs; the ref matched <src>
>       locally is used as the name of the destination.

since "src" from a local standpoint isn't really a ref-name at all.

But hey, your current patch looks fine already. It doesn't _quite_ do what 
I had in mind, but it gets very very close.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to