On Fri, Jan 30, 2009 at 04:58:25PM +0100, Johannes Schindelin wrote:
> > So either we don't care about http-push being consistent with send-pack,
> > and it is OK to have this feature in one but not the other. Or we do,
> > and we really need to clean up the current divergence.
>
> I do not see how your patch to send-pack makes that divergence any
> better, or for that matter, keeps it as bad as it is.
No, it makes it worse. My point was that I am not sure people actually
_care_ that much about the divergence.
> In other words, if you want to give the other protocols at least a
> _chance_ to catch up, you definitely need the support for push --track in
> builtin-push.c or at least in transport.c.
But neither of those places has the information to do it _right_. I
think the right thing to do is:
1. factor out "generic" routines from send-pack, including status
output formatting and tracking ref updating
2. refactor http-push to use those routines, bringing it in line with
send-pack
3. add --track support in the same generic way, and hook it from both
transports
I can try to work on this, but I'm not excited about major surgery to
http-push, which I don't have a working test setup for. I can't bring
myself to care about refactoring rsync, given the recent deprecation
discussion.
If it is going to be added to push or transport, then the transport API
needs refactoring to actually pass out information on what happened
(specifically, how we expanded the refspecs into matching ref pairs).
And maybe that is a more sensible long-term solution, but it is going
involve a lot of changes, too.
-Peff
--
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
