Petr Baudis <[EMAIL PROTECTED]> writes:

> Exactly. I want much more freedom in pushing, the only requirement being
> that "the to-be-replaced remote head is ancestor of the to-be-pushed
> local head". I think (am I wrong?) git-send-pack localhead:remotehead
> would work just fine for me, the only thing I need is the support for
> different local and remote head names.

Now I see where you are coming from; I tend to agree why you
might want to have different names on the remote end.  I however
still suspect that you might be spreading chaos under the name
of more flexibility.  The fact that you can push into it by
definition means you have some control over the other end, and
obviously you are in total control on your end.  I do not see
why you cannot rename branches where needed so that whatever you
are pushing match.  That would also be one less thing to keep
track of for yourself [*1*].

Yes, I am aware that you brought up the example of pushing to
two separate places, but does it happen in practice that you can
push to two places, and at the same time neither of them
cooperates with you to make it easier for you to work on these
three machines by having the same head names?

Having said that, I do not particulary think allowing push to
write into different ref is an unreasonable thing.  As you
pointed out long time ago when send-pack was first done, the
protocol is not so easily extensible, so this may require either
backward incompatible protocol change, or introduction of a new
program pair send-pack-2 / receive-pack-2.  I'll take a look
sometime this weekend.  Bedtime.


[Footnote]

*1* In a hypothetical situation ``I use branch "b00" in this
repository to do XYZ work but I use branch "b24" in the other
repository for the same XYZ work'', Porcelain can keep track of
mapping between b00:b24 for you, but you still need to keep
track of b00:XYZ and b24:XYZ mapping in your head.

-
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