git safe rebase or “try rebase, fallback to merge”
I’m thinking of transforming my merge only workflow to using rebase more often. In this particular case, I’m the only developer, but I work on multiple platforms, often editing same files for platform-specific parts, usually with non-conflicting changes. But I’m a bit unsure about this, because of the debate about git merge vs git rebase, and their safety (for example see this vs. this, the two top answers of a question).
Question: how to do something like following, with goal of “safe” but still as clean as possible pull/rebase/merge:
- If there are un-pushed commits, then
git pull --rebaseuntil the first merge operation which conflicts with local history.
git pull --no-rebaseto merge the rest and do conflict resolution.
- Possibly switch back to rebasing for last non-conflicting changes, to keep the parallel part of history as short as possible.
So if there are no conflicts, end result would be pull with rebase and nice linear history. If there are conflicts, then merges will be visible, but parallel history will be as short as possible.
Is this possible with a simple plain git command or two, with right switches (which I could write into a pull script or alias)? If not, is it possible with some existing tool?
Another way to look at this question: I want to automate the decision of choosing rebase or merge, so I don’t need to think about that detail when doing pull.
Also, does this even make any sense? 🙂
One Solution collect form web for “git safe rebase or “try rebase, fallback to merge””
I follow what you are suggesting. First I attempt a rebase, and if there is no conflicts then it just works, and your history is a lot cleaner. If there is a conflict I do a merge.
The only difference is I wouldn’t attempt to split up the merge and rebase between commits of one pull as you are suggesting in your third bullet point. In fact, I’m not sure that even makes sense. It seems the same as working through conflicts and doing
rebase continue when you resolve the conflicts. The result would be the same as a rebase with conflicts.
If you have changes that need to be pushed. Either do a rebase or, if there is conflicts, do a merge.