On Tue, Jan 07, 2014 at 02:06:12PM -0800, Junio C Hamano wrote:
> Jeff King <peff@xxxxxxxx> writes:
>
> > I think that is sensible, and only heightens my sense of the "upstream"
> > push.default as useless. :)
>
> Yes, it only is good for centralized world (it was designed back in
> the centralized days after all, wasn't it?).
I do not think there is any "centralized days". From day one, Linus
advocated a triangular workflow, and that is how git and kernel develop
has always been done. And that is why the default of "matching" was
there.
There were people who came later, and who still exist today, who use git
in an SVN-like centralized way. So if there were centralized days, we
are in them now. :)
I just do not see any real advantage even in a centralized world for
"upstream" versus "current". Before remote.pushdefault, I can
potentially see some use (if you want to abuse @{upstream}), but now I
do not see any point.
And even in a centralized workflow, I see "upstream" creating problems.
E.g., you fork a feature branch in the centralized repo; it should not
get pushed straight back to "master"! And that is why we invented
"simple", to prevent such things.
I dunno. I have not gone back and read all of the arguments around
push.default from last year. It is entirely possible everything I just
said was refuted back then, and I am needlessly rehashing old arguments.
I remember that Matthieu was one of the main advocates of "upstream". I
am cc-ing him here to bring his attention (not just to this message, but
to the whole thread).
-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