From: Junio C Hamano <hidden> Date: 2016-08-05 15:40:12
"Michael S. Tsirkin" [off-list ref] writes:
On Thu, Sep 10, 2015 at 11:39:49AM -0700, Junio C Hamano wrote:
quoted
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.
From: Martin Fick <hidden> Date: 2016-08-05 21:20:15
On Friday, August 05, 2016 08:39:58 AM you wrote:
* 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.
This is a neat idea. How would this work if there is no
merge commit (mainline hasn't moved)?
-Martin
--
The Qualcomm Innovation Center, Inc. is a member of Code
Aurora Forum, hosted by The Linux Foundation
From: Junio C Hamano <hidden> Date: 2016-08-05 21:24:33
On Fri, Aug 5, 2016 at 2:20 PM, Martin Fick [off-list ref] wrote:
On Friday, August 05, 2016 08:39:58 AM you wrote:
quoted
* 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.
This is a neat idea. How would this work if there is no
merge commit (mainline hasn't moved)?
Sorry, I do not understand your question. You always
merge into your own "lit", which is based on (some)
version of the mainline. If a topic builds on top of the
mainline, you "merge --no-ff" it into "lit". Because no
merges on "lit" will be part of the future mainline anyway,
even the project frowns upon a "no-ff" merge, that will
not be a problem.
From: "Michael S. Tsirkin" <mst@redhat.com> Date: 2016-08-07 05:12:59
On Fri, Aug 05, 2016 at 08:39:58AM -0700, Junio C Hamano wrote:
"Michael S. Tsirkin" [off-list ref] writes:
quoted
On Thu, Sep 10, 2015 at 11:39:49AM -0700, Junio C Hamano wrote:
quoted
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.
From: John Keeping <hidden> Date: 2016-08-07 09:52:41
On Sun, Aug 07, 2016 at 08:12:23AM +0300, Michael S. Tsirkin wrote:
On Fri, Aug 05, 2016 at 08:39:58AM -0700, Junio C Hamano wrote:
quoted
* 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.
git-rerere can generally handle that pretty well. I wrote a tool [1] to
manage integration branches which I use pretty heavily and I find it
very rare to hit a serious conflict. In fact, git-integration has an
"autocontinue" mode which accepts git-rerere's resolution if it has one,
which works reliably in my experience.
I hadn't thought about writing the cover letter in the integration
branch instruction sheet (I normally just put in some notes for myself
about the state of the branch), but I suspect it would be quite easy to
write a script that mails a series using the instruction sheet comments
as the cover letter.
[1] http://johnkeeping.github.io/git-integration/
On Sun, Aug 7, 2016 at 7:12 AM, Michael S. Tsirkin [off-list ref] wrote:
On Fri, Aug 05, 2016 at 08:39:58AM -0700, Junio C Hamano wrote:
quoted
"Michael S. Tsirkin" [off-list ref] writes:
quoted
On Thu, Sep 10, 2015 at 11:39:49AM -0700, Junio C Hamano wrote:
quoted
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?
git-notes was mentioned in this thread back in 2015, but I think it's
discarded because of the argument that's part of the cover letter was
not meant to be kept permanently. But I think we can still use it as a
local/temporary place for cover letter instead of the empty commit at
the topic's tip. It is a mark of the beginning of commit, it does not
require rewriting history when you update the cover letter, and
git-merge can be taught to pick it up when you're ready to set it in
stone.
--
Duy