Jeff King wrote: > As far as merging it to 'next', I had not really intended it to go that > far. :) It was more for Ram to use as a base. Sorry about not having posted a follow-up yet; I'm adjusting to a new timezone and environment. > I find some of the > refactoring questionable, including: > > 1. The meaning of branch->pushremote is subtly different from that of > branch->remote. Ram's followup refactoring did a better job of > that (but he is missing the patches on top to finish out the > feature). > > 2. We are duplicating the "where to push" logic here. That should > probably be factored out so that "git push" and "@{publish}" use > the same logic. > > And of course there are no tests or documentation. It might work, > though. Actually, task (2) is somewhat involved: I still haven't figured out how to share code with 'git push'. > I don't mind if you want to merge it and do more work in-tree, but I do > not think it should graduate as-is. And you may want check from Ram that > he is not in the middle of his own version based on the patches he sent > earlier, as reworking them on top of mine would probably just be > needless extra work. On that note, can you hold off graduating jk/branch-at-publish-rebased, Junio? Hopefully, I'll come up with a replacement over the weekend. Thanks. -- 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