Allow setting --rebase=<arg> in magit-pull transient

[tsdh]

In my .gitconfig I have

[pull]
	rebase = merges

but sometimes (when I just did a merge with many conflicts), I don't want to pull-rebase (because that would mean I need to resolve the conflicts again).

Of course, I can fetch and merge explicitly but I'd rather prefer if I could set the git pull --rebase argument explicitly in the pull transient (I think that used to be possible in an older Magit version). Right now, the transient just allows to provide --rebase or not but not --rebase=false|true|merges|preserve|interactive.

[tarsius]

sometimes (when I just did a merge with many conflicts), I don't want to pull-rebase (because that would mean I need to resolve the conflicts again).

Why don't you just commit the merge after you have resolved the conflicts? How does aborting and then merging preserve the conflict resolution and how does aborting and then pull-rebasing fail to do the same? I am guessing that you have left out some crucial detail and/or I am misunderstanding completely.

Of course, I can fetch and merge explicitly but I'd rather prefer if I could set the git pull --rebase

IMO performing the merge/rebase in a step separate from the fetch step is always a good idea.

I'd rather prefer if I could set the git pull --rebase argument explicitly in the pull transient

If I understand correctly you would like to use --rebase=false, right?

---

Okay so I probably would not use --rebase=VALUE, but that alone doesn't mean that I won't add it.

Unfortunately (for you) there are a few other complications. Replacing the switch --rebase with an option --rebase=VALUE would inconvenient users who only want to use --rebase as a boolean.

Additionally this is a prime example of a setting that can be controlled using either an argument or a configuration variable (several such variables actually). As described in #2993 I intend to rething such settings but doing so is far from trivial. I fear that if I implemented something at this time that I would later have to change it in backward incompatible way that would inconvenient users of the intermediate implementation.

---

But here's an implemenation you can add to your init file:

(define-infix-argument magit-pull:--rebase ()
  :description "Whether to rebase and how"
  :class 'transient-option
  :argument "--rebase="
  :reader (lambda (prompt _initial-input _history)
            (magit-read-char-case "--rebase= " nil
              (?f "[f]alse" "false")
              (?t "[t]rue" "true")
              (?m "[m]erges" "merges")
              (?p "[p]reserve" "preserve")
              (?i "[i]nteractive" "interactive"))))

(transient-replace-suffix 'magit-pull "-r" '("-r" magit-pull:--rebase))

---

Once I get around to #2993 I will likely look at this argument again. Until then I have no plans to add something like the above, so I am closing this issue.

[npostavs]

(because that would mean I need to resolve the conflicts again).

Setting rerere.enabled may help with this. https://git-scm.com/book/en/v2/Git-Tools-Rerere

[tsdh]

@tarsius My use-case is, I did a merge with many conflicts (and it took me hours), committed the merge but then I cannot push because someone pushed in between. With my default setting pull.rebase = merges, a git pull will try to rebase my merge commit on top of the new in-between commits, and then the rebase will fail with the same conflicts again. So in this situation I'd want a git pull --rebase=false.

But I understand that this might be an edge case where it's not justified to make the interface less comfortable and I can easily live with f p followed by m m origin/branch RET.

@npostavs Yes, rerere might do the trick but I'm too frightened to enable it. How does it know that a resolution is correct? I mean, on branch A a different resolution might be correct than on branch B. If there was a knob to make it suggest resolutions instead of just applying them, I'd feel more comfortable.

[npostavs]

How does it know that a resolution is correct? I mean, on branch A a different resolution might be correct than on branch B.

It just goes by diff hunks. So if you happened to have identical hunks that should be resolved differently, then yes, it could make a mistake. But you know it's possible for the automatic merge of non-conflicting hunks and files to be mistaken too (e.g., one side changes the function name, another side still uses the old name elsewhere), right?

If there was a knob to make it suggest resolutions instead of just applying them, I'd feel more comfortable.

Quoting man git-rerere:

Next time, after seeing the same conflicted automerge, running git rerere will perform a three-way merge between the earlier conflicted automerge, the earlier manual resolution, and the current conflicted automerge. If this three-way merge resolves cleanly, the result is written out to your working tree file, so you do not have to manually resolve it. Note that git rerere leaves the index file alone, so you still need to do the final sanity checks with git diff (or git diff -c) and git add when you are satisfied.

I'm not sure what "make it suggest resolutions" means vs what it already does: apply and allow you to review before staging.

[tsdh]

@npostavs You are right, thanks for explaining. I think, I'll try it out. :-)