From: Junio C Hamano <hidden> Date: 2016-06-15 22:51:56
Junio C Hamano [off-list ref] writes:
Michael Haggerty [off-list ref] writes:
quoted
4. There is no place to store the "additional information" (the part
that comes in patch emails between the "---" and the diffstat) while
working on the patch series;...
I thought there was a RFC floating around to do this using notes and also
teach it to "commit -e" a few months ago? I vaguelly recall that Peff and
one of the J's were involved, so I am CC'ing them.
Also, when I prepare a commit to be sent with an additional piece of
information, I often write "---" and the additional message after my
S-o-b: line while preparing the commit log message. Unlike format-patch
that strips that off, commit keeps it, which is handy.
From: Jeff King <hidden> Date: 2016-06-15 22:51:56
On Sat, Aug 27, 2011 at 11:34:13PM -0700, Junio C Hamano wrote:
Junio C Hamano [off-list ref] writes:
quoted
Michael Haggerty [off-list ref] writes:
quoted
4. There is no place to store the "additional information" (the part
that comes in patch emails between the "---" and the diffstat) while
working on the patch series;...
I thought there was a RFC floating around to do this using notes and also
teach it to "commit -e" a few months ago? I vaguelly recall that Peff and
one of the J's were involved, so I am CC'ing them.
Also, when I prepare a commit to be sent with an additional piece of
information, I often write "---" and the additional message after my
S-o-b: line while preparing the commit log message. Unlike format-patch
that strips that off, commit keeps it, which is handy.
After playing around a bit with my earlier series, I made the
realization (perhaps obvious to others :) ), that if you are in a
pure-patch workflow, keeping the "---" in your commit message locally is
much simpler. It follows the commit around through rebases
automatically, it gets put into format-patch output automatically, and
so forth.
The only real downside is that you can never tell git "don't show me the
cover letter cruft". Which is probably OK for your own local patches.
But the point of the "---" is that information should never make it into
a repo, which means in any workflow that involves pulling actual git
commits, it won't work (after reading Michael's response in another
thread, though, I think he would be interested in a hybrid
pull-or-apply-via-mail system).
-Peff
From: Michael J Gruber <hidden> Date: 2016-06-15 22:51:57
Jeff King venit, vidit, dixit 29.08.2011 20:55:
On Sat, Aug 27, 2011 at 11:34:13PM -0700, Junio C Hamano wrote:
quoted
Junio C Hamano [off-list ref] writes:
quoted
Michael Haggerty [off-list ref] writes:
quoted
4. There is no place to store the "additional information" (the part
that comes in patch emails between the "---" and the diffstat) while
working on the patch series;...
I thought there was a RFC floating around to do this using notes and also
teach it to "commit -e" a few months ago? I vaguelly recall that Peff and
one of the J's were involved, so I am CC'ing them.
Also, when I prepare a commit to be sent with an additional piece of
information, I often write "---" and the additional message after my
S-o-b: line while preparing the commit log message. Unlike format-patch
that strips that off, commit keeps it, which is handy.
After playing around a bit with my earlier series, I made the
realization (perhaps obvious to others :) ), that if you are in a
pure-patch workflow, keeping the "---" in your commit message locally is
much simpler. It follows the commit around through rebases
automatically, it gets put into format-patch output automatically, and
so forth.
I'm confused: Does format-patch keep it or strip it as you say above?
Anyways, notes survive rebase etc., and at format-patch time you can
decide whether you want to include them or not (with my patch).
The only real downside is that you can never tell git "don't show me the
cover letter cruft". Which is probably OK for your own local patches.
You can with notes...
But the point of the "---" is that information should never make it into
a repo, which means in any workflow that involves pulling actual git
commits, it won't work (after reading Michael's response in another
thread, though, I think he would be interested in a hybrid
pull-or-apply-via-mail system).
The only difficulty would be sharing notes in a push-pull workflow (for
lack of tool support, though we do have merge support).
Cheers,
Michael
From: Jeff King <hidden> Date: 2016-06-15 22:51:57
On Tue, Aug 30, 2011 at 02:21:13PM +0200, Michael J Gruber wrote:
quoted
After playing around a bit with my earlier series, I made the
realization (perhaps obvious to others :) ), that if you are in a
pure-patch workflow, keeping the "---" in your commit message locally is
much simpler. It follows the commit around through rebases
automatically, it gets put into format-patch output automatically, and
so forth.
I'm confused: Does format-patch keep it or strip it as you say above?
Format-patch will include the whole commit message, including "---" and
what comes after. But an "am" recipient will strip it out of the commit
message. IOW, you locally treat your "---" notes as part of the commit
message, but in a pure-patch workflow, upstream treats it as something
to be stripped out.
So there is asymmetry in what is in your commit versus what is in
upstream's commit. But that's OK, because how you treat the commit
(something to be tweaked and rebased, and then mailed out) and how
upstream treats it (something to go into the long-term project history)
are different.
But that breaks down if you ever want to share actual commit objects
with upstream.
Anyways, notes survive rebase etc.
You still have to manually configure:
git config notes.rewriteRef refs/notes/commits
Perhaps that is something that should be changed.
and at format-patch time you can decide whether you want to include
them or not (with my patch).
Yeah. Don't get me wrong, I think putting "---" notes into git-notes is
way more flexible. It's just that it's also more complex, and
unnecessarily so for many use cases.
We have some patches to hide that complexity, but I was at one point
wondering if all of the complexity was worthwhile. But as I mentioned
above, if you want to build anything more complex than a pure-patch
workflow, the simple solution breaks down. So it probably is worth
pursuing.
-Peff
From: Michael J Gruber <hidden> Date: 2016-06-15 22:51:57
Jeff King venit, vidit, dixit 30.08.2011 17:22:
On Tue, Aug 30, 2011 at 02:21:13PM +0200, Michael J Gruber wrote:
...
quoted
Anyways, notes survive rebase etc.
You still have to manually configure:
git config notes.rewriteRef refs/notes/commits
Perhaps that is something that should be changed.
Right, I've done that quite a while ago and forgot.
quoted
and at format-patch time you can decide whether you want to include
them or not (with my patch).
Yeah. Don't get me wrong, I think putting "---" notes into git-notes is
way more flexible. It's just that it's also more complex, and
unnecessarily so for many use cases.
We have some patches to hide that complexity, but I was at one point
wondering if all of the complexity was worthwhile. But as I mentioned
above, if you want to build anything more complex than a pure-patch
workflow, the simple solution breaks down. So it probably is worth
pursuing.
Reminds me of the ref namespace restructuring which could help sharing
notes... Oh, lots to do before git 3.0!
Michael
From: Johan Herland <hidden> Date: 2016-06-15 22:51:57
On Tuesday 30. August 2011, Michael J Gruber wrote:
Reminds me of the ref namespace restructuring which could help
sharing notes... Oh, lots to do before git 3.0!
Indeed. I am very sorry to not have been able to properly follow up on
that proposal (or a couple of other patches for that matter), but I'm
currently in the middle of changing jobs and moving to a new apartment,
which unfortunately leaves little if any spare time for git work. I
don't believe I'll find the time to pick this up in the next month or
two, so if someone wants to run with it, you are very welcome to do so.
I will try to participate in discussions where I'm CCed, but the rest of
the mailing list is mostly a blur, these days.
...Johan
--
Johan Herland, [off-list ref]
www.herland.net
From: Michael Haggerty <hidden> Date: 2016-06-15 22:51:57
On 08/30/2011 07:39 PM, Johan Herland wrote:
On Tuesday 30. August 2011, Michael J Gruber wrote:
quoted
Reminds me of the ref namespace restructuring which could help
sharing notes... Oh, lots to do before git 3.0!
Indeed. I am very sorry to not have been able to properly follow up on
that proposal [...]
What "ref rename restructuring" are you talking about? Can you give a
mailing list link?
(I've been working on refs lately and want to know whether your proposal
is relevant to my work.)
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
From: Michael J Gruber <hidden> Date: 2016-06-15 22:51:57
Michael Haggerty venit, vidit, dixit 01.09.2011 06:32:
On 08/30/2011 07:39 PM, Johan Herland wrote:
quoted
On Tuesday 30. August 2011, Michael J Gruber wrote:
quoted
Reminds me of the ref namespace restructuring which could help
sharing notes... Oh, lots to do before git 3.0!
Indeed. I am very sorry to not have been able to properly follow up on
that proposal [...]
What "ref rename restructuring" are you talking about? Can you give a
mailing list link?
(I've been working on refs lately and want to know whether your proposal
is relevant to my work.)