Hi Elijah

On Sat, 27 Jul 2019 13:40:13 -0700 Elijah Newren [off-list ref] wrote:

Let me attempt to answer on Junio's behalf...

:)

[...]
There are four, including Junio's commit he had to add in order to
make the series merge with pu (a rename of your t3431 to the
unoccupied t3433 slot).  He labelled that commit "SQUASH???" and it's
still quoted above.  However, in general, when you submit the next
round of your series, you should certainly include his fixups from his
squash (or alternative fixes) inside your commits in order to get rid
of the need for the squash commit.

Understood!

quoted

quoted

 - rebase -i: support --committer-date-is-author-date
 - sequencer: add NULL checks under read_author_script
 - rebase -i: add --ignore-whitespace flag

The correct order should be:
   - rebase -i: add --ignore-whitespace flag
   - sequencer: add NULL checks under read_author_script
   - rebase -i: support --committer-date-is-author-date

Are you thinking in order of application, or order that would be shown
by `git log --oneline`?  Junio includes the latter in his report.

If applied in this order, I think, there is no need of fixups.
But renaming t3431 to t3433 is still required.

quoted

I'll soon send another revision and while on it, let's merge
these topics into one. Should I also rebase them on the tip
of git/git's master?

What do you mean by merge these topics into one?  Do you mean merge
all the commits into a single commit (which would be bad), or that
your two original topics should be one, much like Junio already did?

I am thinking of mergin the original topics, yes, just like Junio did.

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?

Thanks
Rohit