On Thu, May 23, 2013 at 6:26 PM, Junio C Hamano <gits...@pobox.com> wrote: > Felipe Contreras <felipe.contre...@gmail.com> writes: > >>>>> Unless your primary user base is those who use Git as a deployment >>>>> tool to always follow along the tip of some external repository >>>>> without doing anything on your own on the branch you run your "git >>>>> pull" on, defaulting it to --ff-only does not make much sense to me. >>>> >>>> A lot of people do stuff, but the rebase it. >>> >>> If I am parsing the above properly, I think that is only saying that >>> "pull --rebase" makes sense for people who do real work, which I am >>> not disagreeing. >> >> You claimed that 'git pull' (--ff-only) only makes sense if the >> primary user-base doesn't do any work on it, but that's not true; they >> can do a 'git rebase' after such pull (or a merge). > > Either you misread what I wrote or I was unclear. I really meant > "anything on your own *ON* THE BRANCH YOU RUN your "git pull" on". > With > > git checkout frotz ; git pull --ff-only > > you do not do anything "on frotz" other than following along. You > can of course commit, rebase and all others on other branches like > xyzzy and push them out directly. But you cannot even do this once > > git checkout frotz; git merge xyzzy > > if you expect the next "git checkout frotz; git pull --ff-only" will > keep working usefuly.
Unless you rebase. We could of course have a 'branch.<name>.allow_merge' configuration that gets automatically turned on the first time a 'git merge' is executed, but I feel that creates more inconsistency. >> We don't have to assume our primary user-base wants to do full fledged >> merges, in fact, such assumption would be wrong. > > I think we are in agreement on that point already. > > An assumption that people who do merges are somehow more well versed > in Git and are more capable than others to configure their > repository or they will not be annoyed if you asked them a single > configuration change is also wrong, though. s/people who do merges/people who should do merges/ And no, it's not wrong. People who do merges should know what they are doing. The alternatives are these: a) you annoy the vast majority of the user-base by making 'git pull' a dangerous operation that should be avoided, and replaced with 'git fetch'+'git rebase'. b) you annoy a minority of the user-base by making 'git pull' not do the merge the expected, so they have to do +'git merge' (which is already less of a change than a)), or configure the default (which they most likely are able to do, if they did intent to do a merge). b) is clearly superior. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
