git-commit: allow From: line to be entered in commit message

git-commit: allow From: line to be entered in commit message

[sean]

Mostly just for comment to see if there is any support
for this feature....

Sean

---
Use the author name and email information given as the 
first line of the commit message in the form of:

From: name <email>

as the author's name and email address in the resulting
commit object.  This makes committing foreign patches
a little less cumbersome to handle for some workflows.


diff --git a/git-commit.sh b/git-commit.sh
index 193feeb..6004cd4 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -219,7 +219,7 @@ t)
 	fi
 esac
 
-grep -v '^#' < "$GIT_DIR"/COMMIT_EDITMSG |
+grep -v '^#' < "$GIT_DIR"/COMMIT_EDITMSG | sed -e '1s/^[ \t]*from:.*//I' |
 git-stripspace > "$GIT_DIR"/COMMIT_MSG
 
 if cnt=`grep -v -i '^Signed-off-by' "$GIT_DIR"/COMMIT_MSG |
@@ -227,6 +227,13 @@ if cnt=`grep -v -i '^Signed-off-by' "$GI
 	wc -l` &&
    test 0 -lt $cnt
 then
+	FROM=$(grep -v '^#' < "$GIT_DIR"/COMMIT_EDITMSG | sed -ne '1s/from:[ \t]*\(.*\)/\1/Ip;q')
+	NAME=$(echo "$FROM" | sed -e 's/<.*//;s/[ \t]*$//')
+	EMAIL=$(echo "$FROM" | sed -e 's/.*<\(.*\)>.*/\1/')
+	if test -n "$FROM"; then
+		export GIT_AUTHOR_NAME="$NAME"
+		export GIT_AUTHOR_EMAIL="$EMAIL"
+	fi
 	tree=$(git-write-tree) &&
 	commit=$(cat "$GIT_DIR"/COMMIT_MSG | git-commit-tree $tree $PARENTS) &&
 	git-update-ref HEAD $commit $current &&

Re: git-commit: allow From: line to be entered in commit message

[sean]

On Thu, 12 Jan 2006 09:37:00 -0500
sean <seanlkml@sympatico.ca> wrote:

> Mostly just for comment to see if there is any support
> for this feature....

Sorry.  Slightly better version of the patch below:

---
Use the author name and email information given as the 
first line of the commit message in the form of:
 
From: name <email>
 
as the author's name and email address in the resulting
commit object.  This makes committing foreign patches
a little less cumbersome to handle for some workflows.

diff --git a/git-commit.sh b/git-commit.sh
index 193feeb..163e2d7 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -219,14 +219,19 @@ t)
 	fi
 esac
 
-grep -v '^#' < "$GIT_DIR"/COMMIT_EDITMSG |
-git-stripspace > "$GIT_DIR"/COMMIT_MSG
+grep -v '^#' < "$GIT_DIR"/COMMIT_EDITMSG | git-stripspace | 
+sed -e '1s/^[ \t]*from:.*//I' | git-stripspace > "$GIT_DIR"/COMMIT_MSG
 
 if cnt=`grep -v -i '^Signed-off-by' "$GIT_DIR"/COMMIT_MSG |
 	git-stripspace |
 	wc -l` &&
    test 0 -lt $cnt
 then
+	FROM=$(sed -ne '/^#/d;/^[ \t]*$/d;s/from:[ \t]*\(.*\)/\1/Ip;q' "$GIT_DIR"/COMMIT_EDITMSG)
+	if test -n "$FROM"; then
+		export GIT_AUTHOR_NAME=$(echo "$FROM" | sed -e 's/[ \t]*<.*//')
+		export GIT_AUTHOR_EMAIL=$(echo "$FROM" | sed -e 's/.*<\(.*\)>.*/\1/')
+	fi
 	tree=$(git-write-tree) &&
 	commit=$(cat "$GIT_DIR"/COMMIT_MSG | git-commit-tree $tree $PARENTS) &&
 	git-update-ref HEAD $commit $current &&

Re: git-commit: allow From: line to be entered in commit message

[Joel Becker]

On Thu, Jan 12, 2006 at 09:37:00AM -0500, sean wrote:
> Use the author name and email information given as the 
> first line of the commit message in the form of:
> 
> From: name <email>
> 
> as the author's name and email address in the resulting
> commit object.  This makes committing foreign patches
> a little less cumbersome to handle for some workflows.

	If we do this, can we have it populated up front?  That is, when
the edit opens, the current idea of author is in the comments as "From:"
so I can see what the author would be if I changed nothing.  This would
catch surprises where I'd forgotten to set AUTHOR_*, etc.

Joel
 

-- 

Life's Little Instruction Book #182

	"Be romantic."

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127

Re: git-commit: allow From: line to be entered in commit message

[Junio C Hamano]

sean <seanlkml@sympatico.ca> writes:

> Mostly just for comment to see if there is any support
> for this feature....
>
> Sean
>
> ---
> Use the author name and email information given as the 
> first line of the commit message in the form of:
>
> From: name <email>
>
> as the author's name and email address in the resulting
> commit object.  This makes committing foreign patches
> a little less cumbersome to handle for some workflows.

Actually, I've considered this a couple of times in the past,
but I ended up saying no.

If the workflow is driving "git commit" from a script (i.e. your
own Porcelain), the script can set GIT_AUTHOR_* environment
variables, so this is a non issue.

Which means that this 'From: ' thing is coming from the end
user.  Either you as the end user pasted it from some text file,
or typed that line because you knew that the change was made by
that person, not by you.

If you pasted that line from somewhere else, I wonder what that
"somewhere else" file is -- and what else that file contained.
If the change came in an e-mail message, we already have tools
for that (am/applymbox), and they do not lose the author-date
information as your change to git-commit does, so I think it is
a non issue.

And I do not think of anything else that would have author name
but does not have a patch text that you can feed git-apply with.
Pasting from your address book just to save typing does not
count as "pasting" --- that is still typing in this context.

If you typed that line, why somebody else's change ended up in
your working tree is a mystery to me, but let's say an
office-mate edited things for you and said "this should work.
test it out and if it is OK commit it for me."  I have seen this
kind of thing done in real life.

If that is what happened, then what you are adding is a more
convenient way than setting two GIT_AUTHOR_* environment
variables.  Maybe you forgot about preserving author date, in
which case you would add 'Date: ' as well to your patch, and
that would save your user from setting three environment
variables.

So the matter really is how much this patch is better than
setting GIT_AUTHOR_* environment variables, unless it simplifies
things for other programs (one possibility I have not looked
into is that we _might_ be able to use "git commit" with this
modification from "git am/applimbox/revert/cherry-pick").

Re: git-commit: allow From: line to be entered in commit message

[Alex Riesen]

sean, Thu, Jan 12, 2006 15:37:00 +0100:
> 
> Mostly just for comment to see if there is any support
> for this feature....
> 
> Sean
> 
> ---
> Use the author name and email information given as the 
> first line of the commit message in the form of:
> 
> From: name <email>
> 

Isn't this what git-am expect (as a part of mbox) and handle?

Re: git-commit: allow From: line to be entered in commit message

[Junio C Hamano]

Joel Becker <Joel.Becker@oracle.com> writes:

> On Thu, Jan 12, 2006 at 09:37:00AM -0500, sean wrote:
>> Use the author name and email information given as the 
>> first line of the commit message in the form of:
>> 
>> From: name <email>
>> 
> 	If we do this, can we have it populated up front?  That is, when
> the edit opens, the current idea of author is in the comments as "From:"
> so I can see what the author would be if I changed nothing.  This would
> catch surprises where I'd forgotten to set AUTHOR_*, etc.

Committing somebody else's changes by hand ought to be a rare
event.  Otherwise that is an indication that there needs to be a
"git am/applymbox" equivalent for the mythical transport medium
(other than e-mail) that feeds you somebody else's changes to
you and have you commit.  If something is a regular event in a
workflow, we would want to be able to automate things, and
having the user type in whom the changes have come from is not
the way to do it.

Most of the time when I use "git commit", I'll be committing my
own changes; I do not want to see "From: me" every time I
commit.

"Populate upfront, only if it is different from yourself" is
perhaps acceptable, but that is probably hard to arrange.  There
is no reliable way to know what is "yourself", and that was why
we have GIT_AUTHOR_* environment variables to override things to
begin with.

Re: git-commit: allow From: line to be entered in commit message

[Andreas Ericsson]

Junio C Hamano wrote:
> 
> If you typed that line, why somebody else's change ended up in
> your working tree is a mystery to me, but let's say an
> office-mate edited things for you and said "this should work.
> test it out and if it is OK commit it for me."  I have seen this
> kind of thing done in real life.
> 

This happens from time to time where I work, but I think it would be 
more useful to have

	--from="Some User <some.user@theoffice.org>"

which would save even more typing.

I had thought of coupling this with some translation-scheme thingie, so 
that "--from=jd" would be automagically converted to the proper name and 
email address. I first came to think about this when I imported most of 
our projects from CVS, but I ended up doing a quick-hack to 
git-cvsimport instead.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: git-commit: allow From: line to be entered in commit message

[Junio C Hamano]

Andreas Ericsson <ae@op5.se> writes:

> Junio C Hamano wrote:
>
>> ... let's say an
>> office-mate edited things for you and said "this should work.
>> test it out and if it is OK commit it for me."...
>
> This happens from time to time where I work, but I think it would be
> more useful to have
>
> 	--from="Some User <some.user@theoffice.org>"
>

I agree this would be more useful, direct, easy to understand
and explain way to do it.

Re: git-commit: allow From: line to be entered in commit message

[sean]

On Thu, 12 Jan 2006 12:13:52 -0800
Junio C Hamano <junkio@cox.net> wrote:

> Actually, I've considered this a couple of times in the past,
> but I ended up saying no.
> 
> If the workflow is driving "git commit" from a script (i.e. your
> own Porcelain), the script can set GIT_AUTHOR_* environment
> variables, so this is a non issue.

Yes, obviously if there is another wrapper this isn't needed because
that script could parse the From: line out of the text as well.

> Which means that this 'From: ' thing is coming from the end
> user.  Either you as the end user pasted it from some text file,
> or typed that line because you knew that the change was made by
> that person, not by you.
> 
> If you pasted that line from somewhere else, I wonder what that
> "somewhere else" file is -- and what else that file contained.
> If the change came in an e-mail message, we already have tools
> for that (am/applymbox), and they do not lose the author-date
> information as your change to git-commit does, so I think it is
> a non issue.

This idea came up because recently on tLKML there was someone who 
asked Linus to pull from him that had all the author names as his
own and a From: line in a bunch of the commit messages.
When I sent him an email asking why he explained that it was
just too cumbersome to bother setting up the proper author
using git environment variables.   Apparently he is more or less
hand munging mutliple cvs branches into a nice git package for 
Linus to pull.  He said that many of the patches don't apply as-is
and need some manual tweaking before committing.

 
> And I do not think of anything else that would have author name
> but does not have a patch text that you can feed git-apply with.
> Pasting from your address book just to save typing does not
> count as "pasting" --- that is still typing in this context.
> 
> If you typed that line, why somebody else's change ended up in
> your working tree is a mystery to me, but let's say an
> office-mate edited things for you and said "this should work.
> test it out and if it is OK commit it for me."  I have seen this
> kind of thing done in real life.
> 
> If that is what happened, then what you are adding is a more
> convenient way than setting two GIT_AUTHOR_* environment
> variables.  Maybe you forgot about preserving author date, in
> which case you would add 'Date: ' as well to your patch, and
> that would save your user from setting three environment
> variables.

Naw, I just don't think the date is as important or generally
cared about as much, but you're right maybe that'd help someone
too.

> So the matter really is how much this patch is better than
> setting GIT_AUTHOR_* environment variables, unless it simplifies
> things for other programs (one possibility I have not looked
> into is that we _might_ be able to use "git commit" with this
> modification from "git am/applimbox/revert/cherry-pick").
> 

Yeah, i wondered about that too.

I think something like this patch, or as someone else suggested
one that accepts the author on the command line, is needed.
Having to set environment variables for this information just
doesn't make much sense if you ever need to change it in a manual
way, which is bound to happen from time to time.

Cheers,
Sean

Re: git-commit: allow From: line to be entered in commit message

[sean]

On Thu, 12 Jan 2006 22:53:09 +0100
Andreas Ericsson <ae@op5.se> wrote:

> Junio C Hamano wrote:
> > 
> > If you typed that line, why somebody else's change ended up in
> > your working tree is a mystery to me, but let's say an
> > office-mate edited things for you and said "this should work.
> > test it out and if it is OK commit it for me."  I have seen this
> > kind of thing done in real life.
> > 
> This happens from time to time where I work, but I think it would be 
> more useful to have
> 
> 	--from="Some User <some.user@theoffice.org>"
> 
> which would save even more typing.
> 
> I had thought of coupling this with some translation-scheme thingie, so 
> that "--from=jd" would be automagically converted to the proper name and 
> email address. I first came to think about this when I imported most of 
> our projects from CVS, but I ended up doing a quick-hack to 
> git-cvsimport instead.

Yeah, this might be the way to go; however if you are cutting and pasting
the commit message already, this might be slightly less convenient because
now you have to copy-n-paste to the command line instead of just to your
commit editor.   Hopefully it would help to avoid the need for others
to hack the scripts ;o)   Also it would be nice if it could help simplify
the git-am script as Junio suggested too.

Sean

Re: git-commit: allow From: line to be entered in commit message

[sean]

On Thu, 12 Jan 2006 21:16:46 +0100
Alex Riesen <raa.lkml@gmail.com> wrote:

> > Use the author name and email information given as the 
> > first line of the commit message in the form of:
> > 
> > From: name <email>
> > 
> Isn't this what git-am expect (as a part of mbox) and handle?
> 

Hi Alex,

Yes it is, but not everyone is processing patches in mbox format.   If 
this facility is good enough for the mbox users, it seems like it would
be good enough for non-mbox users.   In fact, it would seem more
consistent to tell someone that a From: line will be handled properly
whether they use git-am or git-commit. 

Sean

Re: git-commit: allow From: line to be entered in commit message

[sean]

On Thu, 12 Jan 2006 19:58:20 -0800
Junio C Hamano <junkio@cox.net> wrote:

> sean <seanlkml@sympatico.ca> writes:
> 
> > ...   In fact, it would seem more
> > consistent to tell someone that a From: line will be handled properly
> > whether they use git-am or git-commit. 
> 
> Yuck.
> 
> Somebody using am/applymbox is not writing that "From: " line
> himself.  The person who writes that "From: " line writes that
> into his MUA when sending a patch --- that is "editing an
> email", so there is a consistency between that activity and use
> of word "From: ".
> 
> The editor for commit message does not have anything to do with
> e-mail.  What you are talking about is not consistency, but
> confusion.
> 

I don't imagine that the person "editing" the commit message is
doing so in this case either, rather copy-n-pasting.  If you're
really dead-set against this method, you should at least consider
adding it as a command line option, because having to set this
via environment variables is a much bigger Yuck.

Sean

Re: git-commit: allow From: line to be entered in commit message

[Junio C Hamano]

sean <seanlkml@sympatico.ca> writes:

> ...   In fact, it would seem more
> consistent to tell someone that a From: line will be handled properly
> whether they use git-am or git-commit. 

Yuck.

Somebody using am/applymbox is not writing that "From: " line
himself.  The person who writes that "From: " line writes that
into his MUA when sending a patch --- that is "editing an
email", so there is a consistency between that activity and use
of word "From: ".

The editor for commit message does not have anything to do with
e-mail.  What you are talking about is not consistency, but
confusion.

Re: git-commit: allow From: line to be entered in commit message

[Junio C Hamano]

sean <seanlkml@sympatico.ca> writes:

> ...   Apparently he is more or less
> hand munging mutliple cvs branches into a nice git package for 
> Linus to pull.  He said that many of the patches don't apply as-is
> and need some manual tweaking before committing.

Then what is needed is an exporter from those cvs branches into
git.  Well, don't we have one already?  If it does not work for
dirty changes, wouldn't it be better to fix it so it is
restartable, just like when rebase stops it lets you fix up and
go on, without having you to write "From: " or GIT_AUTHOR_*
yourself and just does the right thing?

Re: git-commit: allow From: line to be entered in commit message

[sean]

On Thu, 12 Jan 2006 20:03:36 -0800
Junio C Hamano <junkio@cox.net> wrote:

> sean <seanlkml@sympatico.ca> writes:
> 
> > ...   Apparently he is more or less
> > hand munging mutliple cvs branches into a nice git package for 
> > Linus to pull.  He said that many of the patches don't apply as-is
> > and need some manual tweaking before committing.
> 
> Then what is needed is an exporter from those cvs branches into
> git.  Well, don't we have one already?  If it does not work for
> dirty changes, wouldn't it be better to fix it so it is
> restartable, just like when rebase stops it lets you fix up and
> go on, without having you to write "From: " or GIT_AUTHOR_*
> yourself and just does the right thing?
> 

Yes perhaps there is some streamlining of the cvs importer that could
be done.  However, I got the impression from him that he was cherry 
picking stuff out of multiple cvs branches so perhaps that's beyond 
what the cvs importer was ever designed to handle.

Anyway, I think this is a more general problem than just the cvs 
importing case; the current interface for setting author information 
is brain damaged and a better method should be offered.

I think you're over estimating the downsides of allowing this to be
set the same was as it is in the git-am case and underestimating the
number of people who would find it useful, but I personally don't 
really care if you'd rather have it as a command line option.

Cheers,
Sean

Re: git-commit: allow From: line to be entered in commit message

[Junio C Hamano]

sean <seanlkml@sympatico.ca> writes:

> I think you're over estimating the downsides of allowing this to be
> set the same was as it is in the git-am case and underestimating the
> number of people who would find it useful, but I personally don't 
> really care if you'd rather have it as a command line option.

You are obviously not talking about the use of "git commit" as a
building block of some script (if you were, it would not make an
iota of difference whether it is a command line option, an extra
"echo From: $name" prepending that to the body of the message,
or setting GIT_AUTHOR_* variables).

So you must be talking about some manual process, at the end of
which the user invokes "git commit" from the command line.

But I would imagine that "git commit" is preceded by a bigger
process of preparing the tree to the committable state out of
what is stored in the foreign SCM, after the user figures out
which commit to pick from (in the original example; the
committable state may come from something other than SCM ---
e.g. set of tarballs or patch application or random monkey
typing).  And the whole process of "preparing the tree" and
"committing" would be done number of times (otherwise we would
not be having this discussion --- just use GIT_AUTHOR_* which is
already available), so having to set them as separate steps
between 'preparing the tree' and 'committing using "git commit"'
is cumbersome.

But you would write 'preparing the tree' (which may include
"figuring out who the author is and what the log has to say" if
the committable state is coming from a foreign SCM) script
anyway, and I simply do not understand why inserting a couple of
setting and exporting of GIT_AUTHOR_* variables at the very end
of that script before calling "git commit" from it, to make it
not just a 'preparing the tree' script but 'prepare the tree and
commit' script is such a big deal for you.

If the committable state does not come from foreign SCM, then
'preparing tree' stage may only be able to prepare a committable
tree, and log and authorship information might need to be
typed/pasted by the user.  But then your script would just do
"read author" or "${VISUAL-vi} .msgfile" before eventually
calling 'GIT_AUTHOR_NAME="$author" git commit -F .msgfile' from
there, so I do not think it is such a big deal either.

I guess the disagreement is primarily coming from that you think
"git commit" is always the uppermost UI layer, while I feel "git
commit" is _one_ possible building block of bigger scripts, but
the true building block is "git commit-tree".

Re: git-commit: allow From: line to be entered in commit message

[sean]

On Thu, 12 Jan 2006 20:35:54 -0800
Junio C Hamano <junkio@cox.net> wrote:

> You are obviously not talking about the use of "git commit" as a
> building block of some script (if you were, it would not make an
> iota of difference whether it is a command line option, an extra
> "echo From: $name" prepending that to the body of the message,
> or setting GIT_AUTHOR_* variables).

Correct.  Although, even as a building block script this might
be a nice little touch; as you mentioned it might be able to 
simplify the git-am script.
 
> So you must be talking about some manual process, at the end of
> which the user invokes "git commit" from the command line.

Yes, and in truth I only have a vague notion of his process.
 
> But I would imagine that "git commit" is preceded by a bigger
> process of preparing the tree to the committable state out of
> what is stored in the foreign SCM, after the user figures out
> which commit to pick from (in the original example; the
> committable state may come from something other than SCM ---
> e.g. set of tarballs or patch application or random monkey
> typing).  And the whole process of "preparing the tree" and
> "committing" would be done number of times (otherwise we would
> not be having this discussion --- just use GIT_AUTHOR_* which is
> already available), so having to set them as separate steps
> between 'preparing the tree' and 'committing using "git commit"'
> is cumbersome.

Agreed, except even in the one-off case I think being able to set
the author info on the command line would be better.   The GIT_AUTHOR_*
variables only really make sense for defaults, and even that is better
handled with .git/config nowadays.

> 
> But you would write 'preparing the tree' (which may include
> "figuring out who the author is and what the log has to say" if
> the committable state is coming from a foreign SCM) script
> anyway, and I simply do not understand why inserting a couple of
> setting and exporting of GIT_AUTHOR_* variables at the very end
> of that script before calling "git commit" from it, to make it
> not just a 'preparing the tree' script but 'prepare the tree and
> commit' script is such a big deal for you.

Hmmm.. we've already agreed that if there is a script to prepare
the tree then this is a non-issue.   We're only talking when
everything is done from the command line.   In fact, i'm suggesting
that if you offer this on the command line (or From: line) that fewer
scripts would need to be hacked together by git users for some simple
cases.

> If the committable state does not come from foreign SCM, then
> 'preparing tree' stage may only be able to prepare a committable
> tree, and log and authorship information might need to be
> typed/pasted by the user.  But then your script would just do
> "read author" or "${VISUAL-vi} .msgfile" before eventually
> calling 'GIT_AUTHOR_NAME="$author" git commit -F .msgfile' from
> there, so I do not think it is such a big deal either.

Yes, this is almost what I emailed to the gentleman in the first place,
but as you noted there is more than just one variable to set so you can't
do it that way.. you end up having to:

$ export GIT_AUTHOR_NAME="$author"
$ GIT_AUTHOR_EMAIL="$email" git commit -F .msgfile

Which is cumbersome and also ends up destroying your defaults if you happen
to use that method, so afterward you have to unset them or reset them back
to your own author info.   If git handled a GIT_AUTHOR_COMBINED or some such
where you could give the name and email together in one variable which 
would be parsed, then that suggestion would be slightly more palatable
but still seems more obtuse than either just accepting it on the command
line or via a From: line.
 
> I guess the disagreement is primarily coming from that you think
> "git commit" is always the uppermost UI layer, while I feel "git
> commit" is _one_ possible building block of bigger scripts, but
> the true building block is "git commit-tree".
> 

Yes, I think you nailed it here.   I do see git-commit as a end-user script
rather than just a building block.

Sean

Re: git-commit: allow From: line to be entered in commit message

[Joel Becker]

On Thu, Jan 12, 2006 at 12:22:53PM -0800, Junio C Hamano wrote:
> Committing somebody else's changes by hand ought to be a rare
> event.  Otherwise that is an indication that there needs to be a
>...
> Most of the time when I use "git commit", I'll be committing my
> own changes; I do not want to see "From: me" every time I
> commit.

	Well, I'm wary of putting
GIT_AUTHOR_EMAIL=joel.becker@oracle.com as a permanent part of my
environment, for fear of overriding some other authors at some point.
On the other hand, if I don't put it in the environment, I get a bogus
author line (jlbec@thisbox.oracle.com).  So I end up having to
hand-write the AUTHOR_EMAIL lines on each commit line; not a solution
I'm happy with.
	This way, I'd have a chance to edit it and be sure :-)

Joel
 

-- 

Life's Little Instruction Book #274

	"Leave everything a little better than you found it."

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127

Re: git-commit: allow From: line to be entered in commit message

[Junio C Hamano]

Joel Becker <Joel.Becker@oracle.com> writes:

> Well, I'm wary of putting
> GIT_AUTHOR_EMAIL=joel.becker@oracle.com as a permanent part of my
> environment, for fear of overriding some other authors at some point.

The weakest default comes from .git/config so you could have
this in your .git/config:

	[user]
        	name = Joel Becker 
                email = Joel.Becker@oracle.com

and you can have GIT_AUTHOR_* override it as necessary.

Re: git-commit: allow From: line to be entered in commit message

[Artem Khodush]

> $ export GIT_AUTHOR_NAME="$author"
> $ GIT_AUTHOR_EMAIL="$email" git commit -F .msgfile

> Which is cumbersome and also ends up destroying your defaults if you happen
> to use that method, so afterward you have to unset them or reset them back
> to your own author info.

Hello,

I had a similar problem on cygwin. I agree that setting environment
variables by hand
is cumbersome, and modifying global environment is undesirable. I ended up with
writing shell script, named git-env.sh, that sets all variables
requred for git to work,
and got used to habit of typing

. git-env.sh

every time I intend to do some work in git.
When that environment is not needed any more,
I just close that particular shell window.


hope this helps,
Artem.

Re: git-commit: allow From: line to be entered in commit message

[Junio C Hamano]

Artem Khodush <greenkaa@gmail.com> writes:

>> $ export GIT_AUTHOR_NAME="$author"
>> $ GIT_AUTHOR_EMAIL="$email" git commit -F .msgfile
>
>> Which is cumbersome and also ends up destroying your defaults if you happen
>> to use that method, so afterward you have to unset them or reset them back
>> to your own author info.
>
> I had a similar problem on cygwin. I agree that setting environment
> variables by hand
> is cumbersome, and modifying global environment is undesirable...

Have you two known that more than one environment variables can
be set for one-shot command execution?

	$ GIT_AUTHOR_NAME="$author" \
	  GIT_AUTHOR_EMAIL="$email" git commit -F .msgfile

would give these environment variables for this "git commit"
without affecting the later commands.

Not that this really matters, since the above example was an
excerpt of my suggestion about how to do this in a script,
somehow made to look as if it was a suggestion about running
things by hand from the command line...

Re: git-commit: allow From: line to be entered in commit message

[sean]

On Fri, 13 Jan 2006 09:40:24 -0800
Junio C Hamano <junkio@cox.net> wrote:

> Have you two known that more than one environment variables can
> be set for one-shot command execution?
> 
> 	$ GIT_AUTHOR_NAME="$author" \
> 	  GIT_AUTHOR_EMAIL="$email" git commit -F .msgfile
> 
> would give these environment variables for this "git commit"
> without affecting the later commands.

No, I didn't know that; thanks for the lesson.

> 
> Not that this really matters, since the above example was an
> excerpt of my suggestion about how to do this in a script,
> somehow made to look as if it was a suggestion about running
> things by hand from the command line...
> 

I said quite a few times now this has nothing to do with running
git-commit from a script.   This is just a simple request
to not require the use of environment variables to pass useful
parameters.

I really don't understand your gripe on this one, when someone 
else suggested using a command line parameter for author
information you said:

<quote>

> 	--from="Some User <some.user@theoffice.org>"
>

I agree this would be more useful, direct, easy to understand
and explain way to do it.

</quote>


So do you still agree with that, would you accept a patch?  Or do you have
some fundamental reason to think that environment variables are a better
way to pass information in this case?

Cheers,
Sean

Re: git-commit: allow From: line to be entered in commit message

[Joel Becker]

On Thu, Jan 12, 2006 at 11:06:07PM -0800, Junio C Hamano wrote:
> Joel Becker <Joel.Becker@oracle.com> writes:
> 
> > Well, I'm wary of putting
> > GIT_AUTHOR_EMAIL=joel.becker@oracle.com as a permanent part of my
> > environment, for fear of overriding some other authors at some point.
> 
> The weakest default comes from .git/config so you could have
> this in your .git/config:
> 
> 	[user]
>         	name = Joel Becker 
>                 email = Joel.Becker@oracle.com

	This configuration is something I have the opportunity to forget
every time I call git-clone.  So I still need to leave it in the
environment permanently.
	Am I correct in assuming that "From:" lines will override the
environment when using git-applymbox?  If so, I guess leaving
GIT_AUTHOR_* in my environment permanently will be ok.

Joel

-- 

"War doesn't determine who's right; war determines who's left."

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127

Re: git-commit: allow From: line to be entered in commit message

[Junio C Hamano]

Joel Becker <Joel.Becker@oracle.com> writes:

> 	Am I correct in assuming that "From:" lines will override the
> environment when using git-applymbox?  If so, I guess leaving
> GIT_AUTHOR_* in my environment permanently will be ok.

That's what I do.  Although I use git-am not git-applymbox, both
of them are designed to work that way.

Re: git-commit: allow From: line to be entered in commit message

[Junio C Hamano]

sean <seanlkml@sympatico.ca> writes:

> So do you still agree with that, would you accept a patch?  Or do you have
> some fundamental reason to think that environment variables are a better
> way to pass information in this case?

Fundamental reason of not doing anything is (1) not to make
unnecessary changes and (1) to avoidi decisions ;-).

No objections to --from='John Doe <john.doe@example.com>' by
itself, other than "You could say GIT_AUTHOR_* before the
command instead of --from after the command; as long as it is
not done regularly as an interactive command, the difference
does not matter".  At that point, "making no unneeded changes"
kicks in.  While I do understand that it might be necessary to
commit somebody else's patch occasionally, you have not
convinced me that is not such a rare thing, so until then the
change stays at lower priority.

After I am convinced that it is not so rare and having an easier
and more consistent way (something coming from environment and
other things from command line is inconsistent) would generally
be a good addition, I further need to think about these issues
before taking such a patch, in the context of the "git commit"
command as a whole:

 - Is --from the right word?  Shouldn't it be --author?
 - Do we want author date?  If not, why not?
 - What about committer information?  If not, why not?

Re: git-commit: allow From: line to be entered in commit message

[Joel Becker]

On Fri, Jan 13, 2006 at 11:39:17AM -0800, Junio C Hamano wrote:
> That's what I do.  Although I use git-am not git-applymbox, both
> of them are designed to work that way.

	While I can see that git-am and git-applymbox have different
options for the same basic task, I can't quite see why one would be
preferred to the other.  What does git-am do that git-applymbox does
not?

Joel

-- 

"I'm so tired of being tired,
 Sure as night will follow day.
 Most things I worry about
 Never happen anyway."

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127

Re: git-commit: allow From: line to be entered in commit message

[Junio C Hamano]

Joel Becker <Joel.Becker@oracle.com> writes:

> On Fri, Jan 13, 2006 at 11:39:17AM -0800, Junio C Hamano wrote:
>> That's what I do.  Although I use git-am not git-applymbox, both
>> of them are designed to work that way.
>
> 	While I can see that git-am and git-applymbox have different
> options for the same basic task, I can't quite see why one would be
> preferred to the other.  What does git-am do that git-applymbox does
> not?

Sorry about the confusion.  This is turning into a FAQ and it is
all _my_ fault [*1*].

Some historical background.

 - "applymbox" was there first.  It was renamed from a tool
   'dotest' Linus had used since BK days, with somewhat
   unextensible command line syntax.

 - "am" was invented later, to majorly redo what applymbox does
   with extensible command line syntax.  It is supposed to do
   everything applymbox does, but the only thing it does not
   support is to be command-line compatible.

The primary reason why I kept applymbox maintained is because
many "How to hack kernel with git" documents floating around
talk about applymbox, and it still is used by Linus to apply
patches with his trained fingers.  Worse yet, it could be that
applymbox is used as a building block in larger private scripts
used by kernel developers, and its removal would force them to
update their scripts to use "am" instead.  I do not want to see
the kernel people spending their time on adjusting their private
tools for git changes unnecessarily; their time is better spent
on improving the kernel.

So in short, I tend to recommend "am" to new people, but
"applymbox" is still usable.


[Footnote]

*1* I do not mind keeping applymbox maintained, but at the same
time I know I would feel it stupid to carry two tools that do
almost the same thing if it were somebody else's project, and
every time this issue comes up I feel the urge to say "in 3
months, git-applymbox will be removed, please get used to
git-am", which so far I ended up resisting.

Re: git-commit: allow From: line to be entered in commit message

[Junio C Hamano]

Junio C Hamano <junkio@cox.net> writes:

> Joel Becker <Joel.Becker@oracle.com> writes:
>
>> On Fri, Jan 13, 2006 at 11:39:17AM -0800, Junio C Hamano wrote:
>>> That's what I do.  Although I use git-am not git-applymbox, both
>>> of them are designed to work that way.
>>
>> 	While I can see that git-am and git-applymbox have different
>> options for the same basic task, I can't quite see why one would be
>> preferred to the other.  What does git-am do that git-applymbox does
>> not?

The behaviour upon seeing unapplicable patch is somewhat
different.  In Linus workflow, he reviews (and modifies if
necessary) all patches inside mbox and runs "applymbox"; upon
failure, he blows what remains in .dotest away, trims mbox to
get rid of what has already been applied and re-runs it from
scratch.  The failure recovery method "applymbox" had (this
happened before my time IIRC) is to edit .dotest/patch to make
it applicable and re-run it.  OTOH, "am" tries to do better by
allowing you to hand tweak the working tree to match what would
have resulted if the patch applied cleanly and say "--resolved".

Another difference is that "am" can be told to handle binary
file changes and apply such as long as the patch is intra
repository (i.e. both pre and post image blob are available in
the repository).  This is used as a backend to do "git rebase".

Re: git-commit: allow From: line to be entered in commit message

[Johannes Schindelin]

Hi,

On Fri, 13 Jan 2006, Joel Becker wrote:

> On Thu, Jan 12, 2006 at 11:06:07PM -0800, Junio C Hamano wrote:
> > Joel Becker <Joel.Becker@oracle.com> writes:
> > 
> > > Well, I'm wary of putting
> > > GIT_AUTHOR_EMAIL=joel.becker@oracle.com as a permanent part of my
> > > environment, for fear of overriding some other authors at some point.
> > 
> > The weakest default comes from .git/config so you could have
> > this in your .git/config:
> > 
> > 	[user]
> >         	name = Joel Becker 
> >                 email = Joel.Becker@oracle.com
> 
> 	This configuration is something I have the opportunity to forget
> every time I call git-clone.  So I still need to leave it in the
> environment permanently.

Of course, you could put it in your templates and never forget.

Ciao,
Dscho

Re: git-commit: allow From: line to be entered in commit message

[Johannes Schindelin]

Hi,

On Fri, 13 Jan 2006, Junio C Hamano wrote:

> sean <seanlkml@sympatico.ca> writes:
> 
> > So do you still agree with that, would you accept a patch?  Or do you have
> > some fundamental reason to think that environment variables are a better
> > way to pass information in this case?
> 
> Fundamental reason of not doing anything is (1) not to make
> unnecessary changes and (1) to avoidi decisions ;-).

You forgot the 3rd (1).

> No objections to --from='John Doe <john.doe@example.com>' by
> itself, other than "You could say GIT_AUTHOR_* before the
> command instead of --from after the command; as long as it is
> not done regularly as an interactive command, the difference
> does not matter".

Well, they are not completely idempotent. If you call

	git commit --form='Me <bla@bla.com>'

it will tell you that you misspelt an option. Try that with

	GIT_AUTOR_NAME='Me without H <dumm@my.com>' git commit


>  - Is --from the right word?  Shouldn't it be --author?
>  - Do we want author date?  If not, why not?
>  - What about committer information?  If not, why not?

These are very valid objections, however. As is: why would you want to do 
that instead of creating an mbox-style file in the first place. 

IIRC there was this strange use case which tried to make a clean git tree 
from several CVS repositories. IMHO it is much easier to cvsimport them, 
and fix everything from within git, which should be relatively easy with 
the nice recursive merge.

My 2 cents,
Dscho