On Thu, Dec 3, 2020 at 3:08 PM Felipe Contreras <felipe.contreras@xxxxxxxxx> wrote: > > On Thu, Dec 3, 2020 at 1:30 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > > > Junio C Hamano <gitster@xxxxxxxxx> writes: > > > > >> That would require changing the semantics of --ff-only, so that "git > > >> pull --no-rebase --ff-only" doesn't make sense (as --ff-only is > > >> overridden by --no-rebase). > > > > > > I do not think such a conclusion follows from "we do not want to use > > > the 'by default force the --ff-only' when the user chooses between > > > merge and rebase". Specifically, I do not agree with "as --ff-only > > > is overridden" in your statement. > > > > Ah, sorry, I mis-read your three lines above. > > > > There are currently two ways "git pull" consolidates your work with > > the other history. By default, you are "pulling" work from your > > contributors (and that is what "pull request" means---contributors > > ask you to pull, and you take their work at your discretion) and the > > only way that makes sense is to merge their history into yours. > > And this is the reason why I warn about using one's worldview too > much. The *vast* majority of users do not use "git pull" this way; > there are more contributors than maintainers. > > What they want is to "merge your history into theirs", not the other > way around. So the only way they can do that correctly is by doing > "git fetch" + "git merge". Which is why so many people say to avoid > "git pull" altogether. > > So, a newcomer that doesn't know much about git and does a "git pull", > is pretty much guaranteed to do something unintended. If he/she is a > user, the merge will have the parents the other way around, but even > as a maintainer, the project might not like merges, and he/she will > introduce an unwanted merge, or worse; an evil merge. > As someone who spends a significant amount of energy at work educating newcomers to git, this is a significant problem. > > The other is you are updating your branch by rebasing your work on > > top of what happend in their history. > > Again, what the user might want is the opposite. If the user is a > maintainer, these two: > > git pull --merge github john > git pull --rebase github john > > Should be about their history to yours (or on top of yours). > > > And if we introduce a third-way, i.e. "we do not handle the case > > where you have your own development at all, this is only to maintain > > pristine copy from your upstream", and repurpose "--ff-only" for > > that purpose, yes, what you said above does make sense. At that > > point, there is no reason to disagree with "as --ff-only is > > overridden" part of your statement---in your new world, "--ff-only" > > is redesigned to act that way. > > That's right. Otherwise "git pull --no-rebase" will fail; you will > have to specify --ff (or --no-ff) for it to work. And that doesn't > make sense to me. > > Specifying --no-rebase should override the default --ff-only mode (or > pull.mode=ff-only). > > > In retrospect, "git pull --rebase" was a UI mistake. What the other > > side means is totally different in the operation from what the other > > side is in "git pull". The former is for you to catch up with your > > upstream and the latter is for you, who _is_ the upstream to others, > > to take others work in as their upstream. If we instead introduced > > a separate command, say "git update", that is "fetch followed by > > rebase" (just like "git pull" is "fetch followed by merge"), to > > rebase your work on top of updated upstream, there wouldn't be a > > need for us to be having this discussion. > > > > It probably is water under the bridge at this point. Perhaps if > > somebody builds a time-machine for me, I'll go back 13 years and > > give my younger self this wisdom ;-) > > You don't have to go back 13 years ago, you can go back 6 years ago > when I wrote all the patches for git update [1], explained the summary > of the problem [2], and others urged git developers to pay more > attention to the patch [3]. > > But as you say; water under the bridge. > > Today there are 3 things to do: > > 1. Improve the annoying warning > 2. Consider changing the semantics of --ff-only, or implement pull.mode=ff-only > 3. Consider a new "git update" command > > Since my new (2020) patches for pull.mode (solve 1 and 2) have not > been reviewed, I'm thinking there's too much inertia and perhaps it's > time to cash in the chips and concentrate only on 1. > I think that solving (1) is relatively simple and worth doing. I think solving (2) is trickier but worth doing in the medium time frame. Doing (3) may have value.. We did it for git checkout already recently, by adding git switch and git restore-files.. But it's a bigger undertaking. I personally like changing the default of pull to be "I will only fast forward, and you need to tell me what to do if history isn't fast forward". This does cause some strain as it forces users to now have to understand and pick which thing they want, (rebase or merge) when combining history.. But I think that's better than users not being asked to pick and just having merge be the default unless they go out of their way to set the rebase by default option. > Cheers. > > [1] https://github.com/felipec/git/commit/d38f1641fc33535aa3c92cf6d3a30334324d3488 > [2] https://lore.kernel.org/git/5366db742d494_18f9e4b308aa@nysa.notmuch/ > [3] https://lore.kernel.org/git/CAGK7Mr4uucBN=17ph5pBjrz7yP60By1sERU9oBL+c2-gsMDmrw@xxxxxxxxxxxxxx/ > > -- > Felipe Contreras
