3

I would like to configure git in a way to get the best of these both options, which are unfortunately mutually exclusive:

[pull]
    ff = only
    rebase = true

Basically, I want to automatically rebase when pulling, but if there are conflicts, the rebase should be aborted.
This way, if I update in the background, my repository always stays in a valid state.

xeruf
  • 2,602
  • 1
  • 25
  • 48

1 Answers1

1

After some fiddling, I concluded with the following shell alias:

[alias]
    l = !git pull --rebase --autostash || (>&2 echo "Error - aborting rebase!" && git rebase --abort)

It pulls and rebases, putting all local changes on top of the remote branch. If there is an error, the rebase is aborted and everything is back to the previous state. There are rare cases where the command fails not because of a rebase conflict, but this merely causes the abort to error as well and doesn't create any invalid state.

This is now my preferred way of updating from remotes, and if something goes wrong, I can still use the default pull command.
If anyone has a more native suggestion, I am still all ears!

xeruf
  • 2,602
  • 1
  • 25
  • 48
  • 1
    This will run `git rebase --abort` even if the rebase never started due to some other error. I think the only option is to check the rebase status (`git status` does it somehow) after an error. – Timmmm Apr 24 '21 at 14:40
  • yes, I mentioned that myself in my answer. If you have an alternative that doesn't add unnecessary complexity I am all ears :) – xeruf Apr 26 '21 at 08:52
  • Ah good point - missed that. I looked up [the logic `git status` uses to detect rebases](https://stackoverflow.com/a/67245016/265521). I'll probably use that. Up to you if you think it is unnecessary but it is just checking for the existence of a few files so you can at least implement it in Bash easily. – Timmmm Apr 26 '21 at 10:54