On Sat, Jul 27, 2019 at 2:00 PM Rohit Ashiwal <rohit.ashiwal265@xxxxxxxxx> wrote: > > In general, once submitted, avoid rebasing unless needed to integrate > > with someone else's work and clean up conflicts. > > I have not checked but git/git:master is like 569 commits ahead of > r1walz/git:master, there _might_ be conflicts. Should I rebase if > need be? First get your topic ready using the same base as you did for your earlier submission(s) of your series. Then when your changes are ready: * Try to merge with origin/master. If there are no conflicts, undo the merge. * Try to merge with origin/next. If there are no conflicts, undo the merge. * Try to merge with origin/pu. If there are no conflicts, undo the merge. If there are no conflicts in any of these steps, submit the next round of your series. If there are conflicts in any step, there's more work to do. If it conflicts with master, then yeah, just rebase on master. If it conflicts with next or pu, there are a few different steps you could take: (1) rebase on the topic that yours conflicts with (assuming it's just one), (2) rebase on next (if next conflicts, though this means your topic can't advance until everything else in next does first so is strongly discouraged), (3) if the conflicts are small/trivial you could just submit anyway and prominently call it out in your cover letter. If there were any conflicts or you rebased at all, make sure to call it out in your cover letter, especially if your series depends on anything not in master. And if you did anything other than rebasing on master, then expect a discussion to start around who should rebase on whom and what order we want to apply topics in, and maybe other steps to take. Elijah
