On Mon, Nov 23, 2020 at 2:20 PM Theodore Y. Ts'o <tytso@xxxxxxx> wrote: > > On Mon, Nov 23, 2020 at 01:40:38PM -0600, Felipe Contreras wrote: > > On Mon, Nov 23, 2020 at 1:17 PM Theodore Y. Ts'o <tytso@xxxxxxx> wrote: > > > > > If your repository is effectively a leaf repo, then rebasing may be > > > harmless, although there are still who don't like rebasing because it > > > invalidates your previous testing. My personal preference is to do a > > > git fetch, followed by a git merge --ff-only, and if that errors out, > > > then I know I need to take a bit more care before deciding what to do > > > next. > > > > Which is why I suggested to make fast-forward-only the default: > > > > https://lore.kernel.org/git/1398988808-29678-1-git-send-email-felipe.contreras@xxxxxxxxx/ > > > > In what case would that default not be what most people want? > > Well, it *was* the default, previously, IIRC. There has never been a "pull.mode=ff-only" option; that's what I tried to introduce. > The problem is that for > "simple" use cases, using rebases for git-pull is "simpler". Well, > it's simpler until it does something super-surprising when the project > becomes more complex, but if the goal is to have a more gentle > learning curve for newbies, especially for small projects --- which > are the vast majority of projectds, on, say github and sourceforge --- > the case can be made. The people that want rebases can configure git pull to do rebases. This issue is about the *unconfigured* default. > So intead of having a huge discussion which is going to be very hard > to come to converge (much like the "main" vs "master" question), > requiring people to set their own global default or per-repo default > is a pretty good compromise. This discussion already happened in 2014, and the conclusion was that doing fast-forward merge if possible, and fail otherwise was a good default. The problem is that the patches were never merged. Cheers. -- Felipe Contreras
