From: J. Bruce Fields <hidden> Date: 2016-06-15 22:42:12
On Sun, Nov 20, 2005 at 06:17:15PM +0100, Blaisorblade wrote:
I've given a look at commit fcc1ad70be5ff89996358b6d770cd229fec2a3ba, and
while it may or may not be the right thing to do, there's a misunderstanding
at the base.
What misunderstanding? Could you quote it?
quoted hunk
For instance, in the stg tree, before that patch, I can do:
$ echo ciao >> README
$ stg diff -r HEAD:
$ stg diff -r HEAD
@@ -12,3 +12,4 @@ StGIT commands. For the latest version see http://www.procode.org/stgit/ For a tutorial see http://wiki.procode.org/cgi-bin/wiki.cgi/StGIT_Tutorial+ciao
That's a diff *to* the working directory. My complaint was that there
wasn't a convenient way to get a diff *from* the working directory.
It's nice to have a convenient shorthand for the current working
directory, and since there's already a shorthand for the HEAD ("HEAD")
it seemed more sensible to make "" the current working directory.
It's a minor point, but it seems convenient.
--b.
That's a diff *to* the working directory. My complaint was that there
wasn't a convenient way to get a diff *from* the working directory.
Something like
git diff -R -M -p
should do it, no?
("git diff" has the strange property that if you give it any diff flags at
all, it forgets all the default ones. So it defaults to "-M -p", but if
you just say "-R", it will drop its own defaults, and use _just_ "-R").
[ Which is almost certainly not what most users want, but it's practical
when you want to get the internal git format. Whether that is important
enough to confuse users or not, I dunno ]
Linus
From: Chuck Lever <hidden> Date: 2016-06-15 22:42:13
J. Bruce Fields wrote:
On Sun, Nov 20, 2005 at 10:13:32AM -0800, Linus Torvalds wrote:
quoted
On Sun, 20 Nov 2005, J. Bruce Fields wrote:
quoted
That's a diff *to* the working directory. My complaint was that there
wasn't a convenient way to get a diff *from* the working directory.
Something like
git diff -R -M -p
should do it, no?
A "-R" option to "stg diff" would be convenient, sure.--b.
that might be an even more intuitive way to dig out what is wanted.
btw, catalin, this was bruce's patch. i'm not sure why i was listed as
the author (probably a mistake of mine when i imported his patch into my
repository). ah well.
A "-R" option to "stg diff" would be convenient, sure.--b.
that might be an even more intuitive way to dig out what is wanted.
I also like the idea of having a -R option (--reverse the long
version). This would mean reversing the commit that changed the diff
-r option.
btw, catalin, this was bruce's patch. i'm not sure why i was listed as
the author (probably a mistake of mine when i imported his patch into my
repository). ah well.
My import command sets the author to the e-mail sender, which was you.
Maybe this should be changed but I don't know which option is better.
In the meantime, you can change the default e-mail template to set the
From: line with to the author of the patch and maybe add a Reply-to:
with your address.
--
Catalin
From: Chuck Lever <hidden> Date: 2016-06-15 22:42:13
Catalin Marinas wrote:
quoted
btw, catalin, this was bruce's patch. i'm not sure why i was listed as
the author (probably a mistake of mine when i imported his patch into my
repository). ah well.
My import command sets the author to the e-mail sender, which was you.
Maybe this should be changed but I don't know which option is better.
In the meantime, you can change the default e-mail template to set the
From: line with to the author of the patch and maybe add a Reply-to:
with your address.
for some reason i was under the impression that it would parse the
Signed-off-by: fields in the patch description, and take the first one
as the patch author.
for some reason i was under the impression that it would parse the
Signed-off-by: fields in the patch description, and take the first one as the
patch author.
The first sign-off really isn't necessarily the author.
It might be a company sign-off (many companies don't want any random
engineer to send out patches), but much more commonly it's a trivial patch
that somebody else signs off on, even if the original patcher didn't (see
case (b) in the sign-off-rules: you can sign of on somebody elses work if
you know it's under the GPL).
So the fact that there was a sign-off procedure doesn't automatically mean
that the author will be the first sign-off person, although in _practice_
that obviously would likely always be the most common case by far.
(Another reason is that some people actually add the sign-offs above
previous ones. It happens, although if I notice, I try to point it out).
So authorship really is totally separate from sign-off, and all _my_ tools
take the authorship from the first "From:" line at the top of the message
body or from the email itself.
Linus
My import command sets the author to the e-mail sender, which was you.
for some reason i was under the impression that it would parse the
Signed-off-by: fields in the patch description, and take the first one
as the patch author.
If you import a patch file and don't specify an author (and the patch
is not an e-mail), the first Signed-off-by: line is used. As Linus
mentioned, we could get rid of this assumption entirely and just
report an error if no author information is given.
--
Catalin
From: Chuck Lever <hidden> Date: 2016-06-15 22:42:13
Linus Torvalds wrote:
On Tue, 22 Nov 2005, Chuck Lever wrote:
quoted
for some reason i was under the impression that it would parse the
Signed-off-by: fields in the patch description, and take the first one as the
patch author.
The first sign-off really isn't necessarily the author.
It might be a company sign-off (many companies don't want any random
engineer to send out patches), but much more commonly it's a trivial patch
that somebody else signs off on, even if the original patcher didn't (see
case (b) in the sign-off-rules: you can sign of on somebody elses work if
you know it's under the GPL).
heh. in fact that is what my company (NetApp) requires.
So the fact that there was a sign-off procedure doesn't automatically mean
that the author will be the first sign-off person, although in _practice_
that obviously would likely always be the most common case by far.
(Another reason is that some people actually add the sign-offs above
previous ones. It happens, although if I notice, I try to point it out).
So authorship really is totally separate from sign-off, and all _my_ tools
take the authorship from the first "From:" line at the top of the message
body or from the email itself.
then perhaps the problem is that the "stg mail" tool should place the
author in the From: field automatically? (ie change the tool, or
permanently modify the default template that comes with StGIT to do
this, as Catalin suggested earlier).
that seems a little twisty to me; you're overloading the SMTP header
field instead of explicitly specifying patch authorship. seems like a
layering violation.
then perhaps the problem is that the "stg mail" tool should place the author
in the From: field automatically? (ie change the tool, or permanently modify
the default template that comes with StGIT to do this, as Catalin suggested
earlier).
that seems a little twisty to me; you're overloading the SMTP header field
instead of explicitly specifying patch authorship. seems like a layering
violation.
No, I only use the actual SMTP header field if the _body_ of the email
doesn't contain the "From:".
So there's really two different "From:" lines: there's the SMTP header
one, which is just a default fallback one, and there's the first non-empty
line of the email body itself, which is the preferred one. No layering
violation, just two different layers that have the same format for the
line.
See "The Perfect Patch" by Andrew, and bullet (4): Attribution:
http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt
To quote:
'If someone else wrote the patch, they should be credited (and blamed)
for it. To communicate this, add a line:
From: John Doe [off-list ref]
as the very first line of the email. Downstream tools will pick this
up and jdoe will get the git "Author" line.'
and I'd be even more anal about it: I would seriously suggest to people
that they just _always_ add the "From:" line at the head of the email,
even if it just is exactly the same as what will be in the SMTP header.
Why? Simple. It makes is less likely that somebody who just forwards the
patch will forget to add that line for you. So you are really helping
people out - and making sure the attribution stays correct - by adding
that extra "From:" line at the top of your email body, even if it is
"unnecessary" in the sense that it's also in your SMTP header.
Linus