From: Philip Oakley Date: Sun, 08 Sep 2013 22:46:18 GMT Subject: Re: [PATCH 0/3] Reject non-ff pulls by default Message-ID: <62FDB1B489D749349DDEE076E689C32E@PhilipOakley> In-Reply-To: From: "Junio C Hamano" Sent: Sunday, September 08, 2013 7:10 PM > Richard Hansen writes: > >> On 2013-09-07 22:41, Felipe Contreras wrote: >>> On Wed, Sep 4, 2013 at 5:59 PM, Junio C Hamano >>> wrote: >>> >>>> Which can be solved by adding the above "fail" option, and then >>>> renaming them to "pull.integrate" and "branch..integrate" to >>>> clarify what these variables are about (it is no longer "do you >>>> rebase or not---if you choose not to rebase, by definition you are >>>> going to merge", as there is a third choice to "fail"), while >>>> retaining "pull.rebase" and "branch..rebase" as a deprecated >>>> synonym. >>> >>> All these names are completely unintuitive. First of all, why >>> "integrate"? Integrate what to what? And then, why "fail"? Fail on >>> what circumstances? Always? >>> >>> My proposal that does: >>> >>> pull.mode = merge/rebase/merge-ff-only >>> >>> Is way more intuitive. >> >> +1 >> >> What about something like: >> >> pull.mergeoptions (defaults to --ff-only) >> pull.rebaseoptions (defaults to empty? --preserve-merges?) >> branch..pull.mergeoptions (defaults to pull.mergeoptions) >> branch..pull.rebaseoptions (defaults to pull.rebaseoptions) > > As "pull" has two distinct phases "fetch" and "merge/rebase", your > mergeoptions/rebaseoptions is much better than "mode", which does > not tell which phase of "pull" the mode refers to. It is clear that > they apply to the process to integrate the history obtained from > the other side and your own history into one history. > > But it does not help Philip's case, if I understand correctly, where > running "git pull" on some branches is always a mistake Not quite always, it's when it won't fast forward > and the user > wants it to stop at "fetch the history and objects needed to > complete the history from the other side" phase without proceeding > to the "then integrate the history from the other side and the > history of your branch into one" step, Yes, it/Git should stop and wait for instructions... > which may be done with either > merge or rebase. Here I would typically rebase onto an adjusted destination, e.g. onto pu, or maybe next, rather than master (or vice versa depending on expectations). That is its a feature branch that needs to decide what it's on top of (well, I need to decide ;-) > Even if we ignore that "always fail, do not do > anything" use case, your two seemingly independent "mergeoptions" > and "rebaseoptions" do not tell us which one is preferred between > merge and rebase. A single > > pull. = rebase | merge [| always-fail] > > makes that choice in a clear way, I think. or 'fail on non-ff' (which may or may not be the users, or Git's default, as per the series title ;-) > > Regarding the verb "integrate". > > We used to explain "pull" is a "fetch" followed by a "merge". With > more people using "git pull --rebase", the word "merge" used in that > explanation of "pull" stopped being generic enough. Simplarily the > "upstream branch" of local branch X is "what you fetch and merge to > update the branch X" but that 'merge' can be 'rebase'. We needed a > verb to call the process of integrate the two histories into one. > > "git pull --help" since 153d7265 (pull: change the description to > "integrate" changes, 2013-07-07) uses that verb [*1*]. > > And that is where the name of the single configuration to pick how > to integrate the history obtained by the first phase of "pull" came > from. > > > [Footnote] > > *1* I suspect that there may still be places in the documentation > that have not been updated since the days back when the only valid > way to integrate two lines of histories was to merge, and updating > them may be a low-hanging fruit. Hint, hint. > > -- Philip