On Sun, Sep 8, 2013 at 12:26 PM, brian m. carlson <sandals@xxxxxxxxxxxxxxxxxxxx> wrote: > On Sat, Sep 07, 2013 at 11:37:13PM -0500, Felipe Contreras wrote: >> On Sat, Sep 7, 2013 at 11:18 PM, Jeff King <peff@xxxxxxxx> wrote: >> > $ hack hack hack >> > $ svn commit ;# oops, somebody else committed in the meantime >> > $ svn update >> > $ svn commit >> > >> > Those people would now have to learn enough to choose between merge and >> > rebase when running the "git pull". >> >> But that's only if they don't care about the shape of history. In my >> experience the people that cling more to centralized VCS do not like >> merges, so they rebase everything to make it a straight line. That is >> much more "svn-like". >> >> So chances are they are already doing 'git pull --rebase' (or >> similar), so their workflow wouldn't be affected. > > We end up squashing each project branch into one commit (usually using > git reset --soft), so we don't care about the shape of history. Over > the course of a project branch, in fact, there may be many merges from > the main release branches (including other projects), so history is > going to be very messy otherwise. Yeah, but the key question at hand in this discussion is; what happens when 'git pull' stops working for them, and they don't know what to do, will they choose 'git pull --rebase' by mistake? I say the answer is no, because: 1) As you say in your scenario, somebody is telling these guys what to do, so when 'git pull' fails, somebody will figure out that they were doing a merge, so 'git pull --merge' is what they want to type from now on. 2) Git itself would be warning them for months that a 'non fast-forward was found, and a merge will be done for them', so when the warning turns to an error, they'll know they want a merge, so they'll do 'git pull --merge', either because the warning told them that's git was doing all along, or because they figured that out by googling, or reading the man page, or whatever. Either way, it would not be a big deal for these people, their user-experience wouldn't be totally broken by this proposed change, and that is the important conclusion. -- Felipe Contreras -- 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