edit Author/Date metadata as part of 'git commit' $EDITOR invocation?

Hi, folks.

From the output of 'git show', it appears that a commit has a few fields

of metadata associated with it in addition to the comment.  These fields
seem to include Author, AuthorDate, Committer, and CommitDate.

  1. Are there other fields aside from these four?

  2. When I invoke 'git commit' without the '-m' argument I'm dropped
     into the cozy $EDITOR of my choice and given the opportunity to
     edit the commit message.  Is there any way to include the metadata
     fields in this editing session?  That way I could both sanity-check
     them as I perform the commit (important) and modify them if they're
     wrong (less important).

     I've been having problems lately with running git on machines where
     I forgot to set up my .gitconfig; I wind up with patches that have
     committers like root@mymachine and so forth.  Being automatically
     shown the committer/author when I make the commit would help me
     avoid these situations.

Thanks,

  - a

Heya,

On Sun, Jan 3, 2010 at 18:32, Adam Megacz [off-list ref] wrote:

    I've been having problems lately with running git on machines where
    I forgot to set up my .gitconfig; I wind up with patches that have
    committers like root@mymachine and so forth.  Being automatically
    shown the committer/author when I make the commit would help me
    avoid these situations.

At the very least it should be easy to include these fields as
comments in the message template. But of course you would still be
bitten if you used "git commit -m" :(.

-- 
Cheers,

Sverre Rabbelier

Sverre Rabbelier [off-list ref] writes:

On Sun, Jan 3, 2010 at 18:32, Adam Megacz [off-list ref] wrote:

quoted

    I've been having problems lately with running git on machines where
    I forgot to set up my .gitconfig; I wind up with patches that have
    committers like root@mymachine and so forth.  Being automatically
    shown the committer/author when I make the commit would help me
    avoid these situations.

At the very least it should be easy to include these fields as
comments in the message template.

That would be great.

But of course you would still be bitten if you used "git commit -m"
:(.

Perhaps a preference (off by default) demanding that they be set
explicitly when "git commit -m" is used?

Some people care more than others about the metadata; this is for the
folks to whom it matters a lot.

  - a

Heya,

On Mon, Jan 4, 2010 at 16:08, Adam Megacz [off-list ref] wrote:

Perhaps a preference (off by default) demanding that they be set
explicitly when "git commit -m" is used?

Heh, what use would that be? On a different/new box you would have
neither that setting nor the email set, so that doens't solve the
problem methinks :P.

-- 
Cheers,

Sverre Rabbelier

On Mon, Jan 04, 2010 at 05:52:42PM -0500, Sverre Rabbelier wrote:

Heya,

On Mon, Jan 4, 2010 at 16:08, Adam Megacz [off-list ref] wrote:

quoted

Perhaps a preference (off by default) demanding that they be set
explicitly when "git commit -m" is used?

Heh, what use would that be? On a different/new box you would have
neither that setting nor the email set, so that doens't solve the
problem methinks :P.

-- 
Cheers,

Sverre Rabbelier

Workaround:

If you use "git commit -s" it includes a Signed-off-by line
which includes your name and email.

Seeing "Signed-off-by: root <root@localhost>" would give you a
hint that you should abort the commit, set the vars, and
try again.


-- 
		David

Quoting Adam Megacz [off-list ref]

Perhaps a preference (off by default) demanding that they be set
explicitly when "git commit -m" is used?

Sverre pointed out why this won't work.

Some people care more than others about the metadata; this is for the
folks to whom it matters a lot.

So the only workable solution is to check your commits with "git show -s" until you become confident that you configured your new box correctly. Some people unfortunately don't care enough to do so, but it is for the people to whom it matters.

-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/

Nanako Shiraishi [off-list ref] writes:

Quoting Adam Megacz [off-list ref]

quoted

Perhaps a preference (off by default) demanding that they be set
explicitly when "git commit -m" is used?

Sverre pointed out why this won't work.

quoted

Some people care more than others about the metadata; this is for the
folks to whom it matters a lot.

So the only workable solution is to check your commits with "git show
-s" until you become confident that you configured your new box
correctly. Some people unfortunately don't care enough to do so, but it
is for the people to whom it matters.

Traditionally, we've only had a minimal sanity check (e.g. to barf when
the name is empty, or something silly like that) and tried to come up with
a reasonable name/email given the available system information.

The approach may have been Ok 10 years ago, back when `whoami`@`hostname`,
at least on systems that were competently maintained, gave a reasonable
mail address for most people, but I don't think it is adequate anymore to
majority of people, especially the ones who work on Open Source projects
as individuals, whose desired public identities are often tied to their
email account at their ISPs or mailbox providers (like gmail), and there
is no way for us to guess what it is from `whoami` nor `hostname` [*1*].

So I don't think anybody minds if we refuse to work if we are going to end
up using a name that we didn't get from an explicit end user configuration
(i.e. GIT_*_EMAIL and GIT_*_NAME environment and user.* configuration
variables).


[Footnote]

*1* Inside corporate environments, `whoami`@`hostname -f` might still be a
reasonable and usable default, though.

Junio C Hamano [off-list ref] writes:

Nanako Shiraishi [off-list ref] writes:

quoted

Quoting Adam Megacz [off-list ref]

quoted

Perhaps a preference (off by default) demanding that they be set
explicitly when "git commit -m" is used?

quoted

Sverre pointed out why this won't work.

I agree; making it a preference will not help.

I propose instead that "git commit -e" cause the metadata headers to be
provided to $EDITOR.  People who care about the metadata can simply get
in the habit of always passing that option when invoking "git commit".

The approach may have been Ok 10 years ago, back when `whoami`@`hostname`,
at least on systems that were competently maintained, gave a reasonable
mail address for most people, but I don't think it is adequate anymore to
majority of people,

I agree.

So I don't think anybody minds if we refuse to work if we are going to end
up using a name that we didn't get from an explicit end user configuration
(i.e. GIT_*_EMAIL and GIT_*_NAME environment and user.* configuration
variables).

I support that as well, although I'd still like to be shown the data.  I
wear a few different hats (each with its own email address), and I don't
think I want to pick one of them as the default.

Thanks,

  - a