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 --rebase
until the first merge operation which conflicts with local history. - Then
git pull --no-rebase
to 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? :)