Thread (19 messages) 19 messages, 10 authors, 2019-08-09

Re: What's cooking in git.git (Jul 2019, #06; Thu, 25)

From: Elijah Newren <hidden>
Date: 2019-07-27 21:42:35

On Sat, Jul 27, 2019 at 2:00 PM Rohit Ashiwal
[off-list ref] wrote:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help