Re: [PATCH] (preview) Renaming push.

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.

So:

  - 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.

		Linus