Re: [PATCH v10 3/5] history: add squash subcommand to fold a range

Harald Nordgren <[email protected]> writes:

>> These patches can be fetched with
>>
>>   git fetch https://github.com/phillipwood/git wip/hn/history-squash/v10-early-part
>>
>> note that they do not support editing the commit message of the
>> squashed commit.
>
> Thanks, what should I do with it?
>
> Is it a replacement for my branch, or should it apply them as fixups
> (if so how do we handle the lack of re-edit support)?

I am not Phillip, but in light of what I said elsewhere, I would
expect you to review them as if they were patch submissions to your
tree.  You may agree with some parts while disagreeing with others.

Respond to them.

Respond even to the ones you agree with, just as you would when
giving a positive review.  Demonstrate that you read them,
understood how they work, and then state that you agree.  If you
disagree, explain why you think it is better without such
changes.  

Just do not send a new iteration without a thorough explanation of
how you addressed each of the review comments, including those
review messages disguised as patches.  Be inviting to even those who
have not been involved in this topic so far to join the discussion,
which requires you to be transparent.  Engage in dialogue.  Explain
what you are doing.  Do not let patches alone explain themselves.

First and foremost, this development community is built on humans
collaborating with other humans.  An author posts a patch, a
reviewer responds with suggestions or critiques, and the author
replies to that e-mail.  In their own words, the author might:

 - build on the suggestion, rephrasing it and proposing further
   improvements;

 - disagree and offer a counter-proposal;

 - concede the patch's shortcomings and outline how they plan to fix
   them; or

 - defend their original design to give the reviewer a chance to
   reconsider.

Doing this in your own words helps reviewers see how close we are to
an agreement.  This kind of discussion often needs a few rounds of
back-and-forth.  It should also welcome folks watching from the
sidelines, which means letting the globe spin at least once so
developers in other timezones can chime in before we declare a rough
consensus.

Firing off a new iteration before there is a rough consensus on what
the final shape of the patches should look like makes it appear as
though the only thing you care about is producing the next
iteration, and that you care much less about collaborating with
others.

Thanks, Phillip, for these patches-as-reviews.