`git up` should probably obey `pull.ff-only = true` and maybe even `branch.BR.mergeOptions` too

[robohack]

The handling of the currently checked out branch by git up is beginning to trouble me even more than it used to.

When working on a centrally shared project with shared branches, and where one normally has one of these shared branches checked out at all times, e.g. master, the best option usually is to rebase local changes onto the tip of the branch being merged.

However when working on a clone of a 3rd-party repository where one normally never ever makes commits to the local branches tracking upstream's branches (e.g. master), but where one might commonly have the upstream branch checked out, the best option is to never rebase when pulling (no matter what's checked out!). This is especially true on large repositories (e.g. NetBSD's or FreeBSD's repos) where rebasing might take tens of hours, or even tens of days longer than fast-forwarding will take.

When I use git pull directly I set pull.ff-only = true, and for safety also set branch.BR.mergeOptions = --ff-only and branch.BR.rebase = false for each local branch BR which is "owned" by, i.e. only ever pulled onto from (never pushed to), and is a tracking branch from, the 3rd party upstream repository.

I've now run into problems when trying to use git up in such 3rd party clones as it will try to rebase even when I've done my utmost to prevent this from happening.

Having had a quick look at the code I see the choice to force git rebase on the currently checked out branch is very simplistic and it is also hard-coded (i.e. cannot be influenced in any way other than by checking out another branch, e.g. a local-only branch). That makes it almost pointless to use git up for these repositories.

This has made me wonder why is it necessary for git up to make this choice directly in the first place? This is especially confounding given that git pull already has a plethora of rules and options for controlling whether it does a git merge or a git rebase, and what options it must use with the chosen operation.

So, perhaps the simplest solution to my problem is to simply drop all the logic that tries to replace git pull and just use git pull directly and always in the first place (while keeping of course the logic to stash uncommitted changes, and of course to iterate over all local branches tracking upstream branches in any and all remotes). If I manage to implement this and get it working for my scenarios then hopefully I can submit a pull request mentioning this issue.

A less simple/universal solution would be for git up itself to honour any pull.ff-only = true and branch.BR.rebase config flags (i.e. for the currently checked out branch). But I don't prefer this -- git pull already does this itself and so I think it should just be trusted to Do The Right Thing.

One clue that a particular remote is a "pull only" for a 3rd party repository that has been "forked" on some Git forge is that it is named origin and there's a second remote to the same server (but perhaps with a different protocol), with some other name, perhaps especially if the other remote's name matches the first component of that remote's path spec. Perhaps in this case git up could offer advice to the user about setting appropriate branch.BR.rebase flags, etc.