On Sun, 7 Oct 2007, martin f krafft wrote: > > So am I right if I say that all the logic should really be happening > in send-pack and that push is really just an interface when it comes > to selecting the refs to push, so it should basically feed through > the options and refs, meaning that send-pack should get --tags and > --shared as well? I really don't have any strong personal opinions. I don't think anybody is ever supposed to use send-pack directly, so I don't think it really much matters whether send-pack is taught to do all the helper options too, or whether it should just get the list of refs.. But yes, I suspect it would be cleanest to just remove the "expand --tags" logic from builtin-push, and make the actual sending side do that. > Or should push enumerate all refs needed and pass them directly to > send-pack, effectively making send-pack's --all option obsolete? I don't think this works very well - builtin-push doesn't even know what the remote branches _are_, so it cannot list "these branches are shared". So we'd always have to have that shared behaviour embedded in send-pack anyway, so I think the most logical thing is to also do the logic for --all and --tags there. IOW, builtin-push would just be a wrapper around send-pack, doing the "for each remote" thing, but just passing down all/tags/shared. Linus - 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
