threads / patch / 43177

patchRe: [PATCH] Trim hint printed when gecos is empty.

Subject: Re: [PATCH] Trim hint printed when gecos is empty.

## tl;dr

11 messages between Nov 28, 2006 and Nov 29, 2006. Diffs are folded; open one to read it.

replies: 10people: 6as markdown or json

Han-Wen Nienhuys· Nov 28, 2006, 10:27 UTC · lore

[PATCH] Trim hint printed when gecos is empty.

Trim hint printed when gecos is empty.
Remove asterisks for readability
Suggest use of git-config for easy cut & pasting.
---
 ident.c |   15 ++++++++++-----
 1 files changed, 10 insertions(+), 5 deletions(-)
Show changes to ident.c +10 −5
diff --git a/ident.c b/ident.c
index efec97f..e415fd3 100644
--- a/ident.c
+++ b/ident.c
@@ -158,12 +158,17 @@ static int copy(char *buf, int size, int
 static const char au_env[] = "GIT_AUTHOR_NAME";
 static const char co_env[] = "GIT_COMMITTER_NAME";
 static const char *env_hint =
-"\n*** Environment problem:\n"
+"\n"
 "*** Your name cannot be determined from your system services (gecos).\n"
-"*** You would need to set %s and %s\n"
-"*** environment variables; otherwise you won't be able to perform\n"
-"*** certain operations because of \"empty ident\" errors.\n"
-"*** Alternatively, you can use user.name configuration variable.\n\n";
+"\n"
+"Run\n"
+"\n"
+"  git repo-config user.email \"you@email.com\"\n"
+"  git repo-config user.name \"Your Name\"\n"
+"\n"
+"To set the identity in this repository.\n"
+"Add --global to set your account\'s default\n"
+"\n";
 
 static const char *get_ident(const char *name, const char *email,
 			     const char *date_str, int error_on_no_name)

-- 
1.4.2.4


-- 
 Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
Han-Wen Nienhuys· Nov 28, 2006, 10:52 UTC · re: Han-Wen Nienhuys · lore
Han-Wen Nienhuys escreveu:
> Trim hint printed when gecos is empty.
> Remove asterisks for readability
> Suggest use of git-config for easy cut & pasting.
> ---
and 
Signed-off-by: Han-Wen Nienhuys <hanwen@xs4all.nl>
is there a reason why git-format-patch doesn't add a sign-off by default?
-- 
 Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
Jakub Narebski· Nov 28, 2006, 11:15 UTC · re: Han-Wen Nienhuys · lore
Han-Wen Nienhuys wrote:
Show 11 quoted lines
> Han-Wen Nienhuys escreveu:
>> Trim hint printed when gecos is empty.
>> Remove asterisks for readability
>> Suggest use of git-config for easy cut & pasting.
>> ---
> 
> and 
> 
> Signed-off-by: Han-Wen Nienhuys <hanwen@xs4all.nl>
> 
> is there a reason why git-format-patch doesn't add a sign-off by default?

Yes. You are supposed to add Signed-off-by on commit (I hope that git-format-patch doesn't dulicate signoff lines), using git-commit -s.

But perhaps a config option...
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
Andy Parkins· Nov 28, 2006, 11:46 UTC · re: Jakub Narebski · lore
On Tuesday 2006 November 28 11:15, Jakub Narebski wrote:
> Yes. You are supposed to add Signed-off-by on commit (I hope that
> git-format-patch doesn't dulicate signoff lines), using git-commit -s.
> But perhaps a config option...
I achieve reasonable results by having the following in my .git/config
[format]                                                                                                                                                              
    headers = "To: git@vger.kernel.org\n"                                                                                                                             
                                                                                                                                                                      
[alias]                                                                                                                                                               
    email=format-patch --signoff --stdout

By tuning this per-project I know that a "git email" will generate the correct sort of patch for this project.

The thing that's missing is a config option to make git-commit add the signoff automatically. I think this would be useful, as "signing off" is probably a per-project decision rather than a per-commit decision. It seems awkward to require the user to remember what the project policy is and always get the right git-commit for each project.

Andy
-- 
Dr Andy Parkins, M Eng (hons), MIEE
Johannes Schindelin· Nov 28, 2006, 13:28 UTC · re: Andy Parkins · lore
Hi,
On Tue, 28 Nov 2006, Andy Parkins wrote:
> The thing that's missing is a config option to make git-commit add the 
> signoff automatically.

No. As has been often said, a signoff _has_ to be a conscious act, or else it will lose its meaning.

Once you are reasonably convinced you want to sign off on that commit, just add "-s" to git-commit. And if you forgot, fix it by "git commit -s --amend". (Note that this is another nice example why "-a" by default would be wrong, wrong, wrong.)

Ciao, Dscho

Andy Parkins· Nov 28, 2006, 14:03 UTC · re: Johannes Schindelin · lore
On Tuesday 2006 November 28 13:28, Johannes Schindelin wrote:
> No. As has been often said, a signoff _has_ to be a conscious act, or else
> it will lose its meaning.

I'm not suggesting that a project integrator would have that switch on, but for me, in my own repository, where I am the only person writing patches, what possible case is there that I won't sign off?

> Once you are reasonably convinced you want to sign off on that commit,

I am always convinced. Perhaps I am doing wrong - please explain to me under what circumstance I would /not/ want to sign off on a commit. (assuming I am acting merely as a developer on a project, I am not accepting patches from anyone but me).

> just add "-s" to git-commit. And if you forgot, fix it by "git commit -s
> --amend". (Note that this is another nice example why "-a" by default
> would be wrong, wrong, wrong.)

I don't see what one has to do with the other. There are good arguments for not having "-a" default, but signing off isn't one of them.

Andy
-- 
Dr Andy Parkins, M Eng (hons), MIEE
Johannes Schindelin· Nov 28, 2006, 14:40 UTC · re: Andy Parkins · lore
Hi,
On Tue, 28 Nov 2006, Andy Parkins wrote:
Show 8 quoted lines
> On Tuesday 2006 November 28 13:28, Johannes Schindelin wrote:
> 
> > No. As has been often said, a signoff _has_ to be a conscious act, or else
> > it will lose its meaning.
> 
> I'm not suggesting that a project integrator would have that switch on, 
> but for me, in my own repository, where I am the only person writing 
> patches, what possible case is there that I won't sign off?

You are probably different than me. What with my track record, I _trust_ my patches to be not perfect at all. Nevertheless, I commit here and now, and usually I regroup the commits into a nice patch (series) (AKA poor man's StGit).

So I will never need something like you suggest. Having said that, if you think it is best for you to mark every commit as signed-off-by you, just add an alias:

	git repo-config --global alias.c "commit -s"

and you're done. I highly doubt that it makes sense for the average developer, though.

Andy Parkins· Nov 28, 2006, 15:06 UTC · re: Johannes Schindelin · lore
On Tuesday 2006 November 28 14:40, Johannes Schindelin wrote:
> You are probably different than me. What with my track record, I _trust_
> my patches to be not perfect at all. Nevertheless, I commit here and now,
> and usually I regroup the commits into a nice patch (series) (AKA poor
> man's StGit).

I'm certainly not perfect, nor would I ever claim to be. Perhaps I have misunderstood the purpose of the Signed-Off line. I had understood it was a legal tool to trace the provenance of a patch - not to sign off on it being bug free (which surely is impossible).

Since I know that I, and I alone wrote that patch, I can sign off on it regardless of it being any good technically.

This is in agreement with my understanding of the Documentation/SubmittingPatches file included with git.

"The sign-off is a simple line at the end of the explanation for the patch, which certifies that you wrote it or otherwise have the right to pass it on as a open-source patch."

Show 5 quoted lines
> So I will never need something like you suggest. Having said that, if you
> think it is best for you to mark every commit as signed-off-by you, just
> add an alias:
>
> 	git repo-config --global alias.c "commit -s"

That requires that I introduce a new command; I want the existing command to do The Right Thing. Also; I certainly wouldn't want it global, as I said in my original message - this is a per-project choice. Some projects don't have Signed-Off lines, so there is no point there.

Ideally, I'd be able to do
        git repo-config alias.commit "commit -s"
Just as I can with shell commands.
Andy
-- 
Dr Andy Parkins, M Eng (hons), MIEE
Shawn Pearce· Nov 28, 2006, 15:31 UTC · re: Andy Parkins · lore
Andy Parkins <andyparkins@gmail.com> wrote:
Show 14 quoted lines
> > So I will never need something like you suggest. Having said that, if you
> > think it is best for you to mark every commit as signed-off-by you, just
> > add an alias:
> >
> > 	git repo-config --global alias.c "commit -s"
> 
> That requires that I introduce a new command; I want the existing command to 
> do The Right Thing.  Also; I certainly wouldn't want it global, as I said in 
> my original message - this is a per-project choice.  Some projects don't have 
> Signed-Off lines, so there is no point there.
> 
> Ideally, I'd be able to do
>         git repo-config alias.commit "commit -s"
> Just as I can with shell commands.

Long ago we decided that aliasing over shipped commands was a baaaad idea, as it might get a shell script into trouble when all of a sudden the "-s" option is being given to every commit invocation.

But you can install a commit-msg hook (.git/hooks/commit-msg) in any project you want to ensure a Signed-off-by line is in the commit message for. Its handed the COMMIT_EDITMSG file, which is what the message will be generated from. Looking at the code for git-commit.sh its perfectly OK if the hook edits the file too.

Further the hook could be interactive, prompting the user "are you sure you don't want to sign this commit?" or can be skipped by handing --no-verify to commit.

I just learned about commit-msg hook the other day when I was reading through git-commit.sh and noticed I didn't implement invoking that particular hook in git-gui...

Junio C Hamano· Nov 28, 2006, 18:29 UTC · re: Andy Parkins · lore
Andy Parkins <andyparkins@gmail.com> writes:
Show 8 quoted lines
> On Tuesday 2006 November 28 14:40, Johannes Schindelin wrote:
>
>> You are probably different than me. What with my track record, I _trust_
>> my patches to be not perfect at all...
>
> ...  I had understood it was a 
> legal tool to trace the provenance of a patch - not to sign off on it being 
> bug free (which surely is impossible).

Johannes, Andy's interpretation is in line with the policy in SubmittingPatches. S-o-b is about warranty of provenance, and not about correctness or cheering (Acked-by).

And I think it makes sense to add "-s" automatically to commits made in a private working repository in which the developer who configured "-s" to be added automatically is the only person who makes commits. As already mentioned in the thread, one of the hooks should be usable for that. And it certainly is a possibility to add a config to turn "-s" on.

But I suspect that it would be cleaner and more useful to teach "git commit" to use a commit message template per repository and put the S-o-b in there -- that mechanism would be usable for things other than just S-o-b lines as projects see fit.

Johannes Schindelin· Nov 29, 2006, 09:29 UTC · re: Junio C Hamano · lore
Hi,
On Tue, 28 Nov 2006, Junio C Hamano wrote:
> Johannes, Andy's interpretation is in line with the policy in 
> SubmittingPatches.  S-o-b is about warranty of provenance, and not about 
> correctness or cheering (Acked-by).
Fair enough.
Ciao,

← back to recent threads