On Fri, Aug 05, 2016 at 08:39:58AM -0700, Junio C Hamano wrote:
> "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).
A flag that marks a commit "beginning of series" then?
> 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.
This seems to assume topic branches. I know you use them,
but not overyone does, I don't.
> * 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.
Combining patchsets might need conflict resolution,
redoing this each time might be a lot of work.
> 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