you really do not want to know the git crimes i was up to today
merging 3.5.3+glitch onto 3.5.2+glitch sure is a time if
- you have already cherry-picked a couple things from 3.5.3;
- you want a linear commit history;
- you want to preserve every individual commit; and
- for whatever goddamn reason rebasing onto trunk after git merge is reapplying something like 50 commits before trunk??? with all the merge conflicts that implies????? WHY
@aescling oh you probably need to use rebase --onto trunk commit-you-rebased-from-last-time
@aescling rebase starts from the last common commit which will be basically the fork point in our case
rebase --onto b a only rebases the changes since a onto the branch b
@aescling this is something i recently had to research because at work we have this same problem
