"Michael S. Tsirkin" <mst@xxxxxxxxxx> writes:
> On Thu, Sep 10, 2015 at 11:39:49AM -0700, Junio C Hamano wrote:
>> The problem with "empty commit trick" is that it is a commit whose
>> sole purpose is to describe the series, and its presence makes it
>> clear where the series ends, but the topology does not tell where
>> the series begins, so it is an unsatisifactory half-measure.
>
> Actually, when using topic branches the series always ends at head, so
> it's better to keep the empty commit where series begins.
But that would mean that you would need to destroy and recreate more
commits than you would need to. If you have a five-commit series
(with the bottom "description" one, you would have six commits) and
you are already happy with the bottom two but want to update the
third one, you wuld have to "rebase -i" all six of them, reword the
bottom "description" to adjust it to describe the new version of the
third one _before_ you even do the actual update of the third one.
That somehow feels backwards, and that backward-ness comes from the
fact that you abused a single-parent commit for the purpose it is
not meant to be used (i.e. they are to describe individual changes),
because you did not find a better existing mechanism (and I suspect
there isn't any, in which case the solution is to invent one, not
abusing an existing mechanism that is not suited for it).
If this were part of a workflow like this, I would understand it:
* Build a N-commit series on a topic.
* You keep a "local integration testing" branch ("lit"), forked
from a mainline and updated _every time_ you do something to your
topics. You may or may not publish this branch. This is the
aggregation of what you locally have done, a convenient place to
test individual topics together before they get published.
* A new topic, when you merge it to the "lit" branch, you describe
the cover as the merge commit message.
* When you updated an existing topic, you tell a tool like "rebase
-i -p" to recreate "lit" branch on top of the mainline. This
would give you an opportunity to update the cover.
Now the tool support for the last one is the missing piece. In
addition to what "rebase -i -p" would, it at least need to
automatically figure out which topics have been updated, so that
their merge commit log messages need to be given in the editor to
update, while carrying over the merge log message for other topics
intact (by default).
With that, you should also be able to teach "format-patch --cover"
to take these merge messages on "lit" into account when it creates
the cover letter.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html