# git-commit: allow From: line to be entered in commit message 16 messages from 2006-01-12 to 2006-01-13. Participants: sean, Junio C Hamano, Andreas Ericsson, Artem Khodush, Johannes Schindelin. Thread: https://gitlist.dev/t/3060 ## sean, 2006-01-12 14:37 Subject: git-commit: allow From: line to be entered in commit message Message-ID: URL: https://gitlist.dev/e/BAYC1-PASMTP117A18814EAAFACFE0F31DAE270%40CEZ.ICE ``` 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 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 && ``` ## sean, 2006-01-12 15:21 Subject: Re: git-commit: allow From: line to be entered in commit message Message-ID: URL: https://gitlist.dev/e/BAYC1-PASMTP07EE5172C7652A5DD3131DAE270%40CEZ.ICE In-Reply-To: ``` On Thu, 12 Jan 2006 09:37:00 -0500 sean 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 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 && ``` ## Junio C Hamano, 2006-01-12 20:13 Subject: Re: git-commit: allow From: line to be entered in commit message Message-ID: <7vzmm1mcfz.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vzmm1mcfz.fsf%40assigned-by-dhcp.cox.net In-Reply-To: ``` sean 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 > > 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"). ``` ## Andreas Ericsson, 2006-01-12 21:53 Subject: Re: git-commit: allow From: line to be entered in commit message Message-ID: <43C6CFC5.5010902@op5.se> URL: https://gitlist.dev/e/43C6CFC5.5010902%40op5.se In-Reply-To: <7vzmm1mcfz.fsf@assigned-by-dhcp.cox.net> ``` 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 " 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 ``` ## Junio C Hamano, 2006-01-12 22:15 Subject: Re: git-commit: allow From: line to be entered in commit message Message-ID: <7v4q49ks83.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7v4q49ks83.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <43C6CFC5.5010902@op5.se> ``` Andreas Ericsson 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 " > I agree this would be more useful, direct, easy to understand and explain way to do it. ``` ## sean, 2006-01-13 02:32 Subject: Re: git-commit: allow From: line to be entered in commit message Message-ID: URL: https://gitlist.dev/e/BAYC1-PASMTP102ED7B30D2B48BEE601F5AE260%40CEZ.ICE In-Reply-To: <7vzmm1mcfz.fsf@assigned-by-dhcp.cox.net> ``` On Thu, 12 Jan 2006 12:13:52 -0800 Junio C Hamano 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 ``` ## sean, 2006-01-13 02:43 Subject: Re: git-commit: allow From: line to be entered in commit message Message-ID: URL: https://gitlist.dev/e/BAYC1-PASMTP0804299A4D3C5C1973FF6CAE260%40CEZ.ICE In-Reply-To: <43C6CFC5.5010902@op5.se> ``` On Thu, 12 Jan 2006 22:53:09 +0100 Andreas Ericsson 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 " > > 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 ``` ## Junio C Hamano, 2006-01-13 04:03 Subject: Re: git-commit: allow From: line to be entered in commit message Message-ID: <7v4q48hizr.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7v4q48hizr.fsf%40assigned-by-dhcp.cox.net In-Reply-To: ``` sean 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? ``` ## sean, 2006-01-13 04:06 Subject: Re: git-commit: allow From: line to be entered in commit message Message-ID: URL: https://gitlist.dev/e/BAYC1-PASMTP067B249A8110916F036FB3AE260%40CEZ.ICE In-Reply-To: <7v4q48hizr.fsf@assigned-by-dhcp.cox.net> ``` On Thu, 12 Jan 2006 20:03:36 -0800 Junio C Hamano wrote: > sean 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 ``` ## Junio C Hamano, 2006-01-13 04:35 Subject: Re: git-commit: allow From: line to be entered in commit message Message-ID: <7vzmm0eod1.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vzmm0eod1.fsf%40assigned-by-dhcp.cox.net In-Reply-To: ``` sean 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". ``` ## sean, 2006-01-13 04:51 Subject: Re: git-commit: allow From: line to be entered in commit message Message-ID: URL: https://gitlist.dev/e/BAYC1-PASMTP01A07DAA61F181E9D9679EAE260%40CEZ.ICE In-Reply-To: <7vzmm0eod1.fsf@assigned-by-dhcp.cox.net> ``` On Thu, 12 Jan 2006 20:35:54 -0800 Junio C Hamano 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 ``` ## Artem Khodush, 2006-01-13 11:11 Subject: Re: git-commit: allow From: line to be entered in commit message Message-ID: <40b2b7d90601130311v78db741dx7c5eaa57ad300850@mail.gmail.com> URL: https://gitlist.dev/e/40b2b7d90601130311v78db741dx7c5eaa57ad300850%40mail.gmail.com In-Reply-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. 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. ``` ## Junio C Hamano, 2006-01-13 17:40 Subject: Re: git-commit: allow From: line to be entered in commit message Message-ID: <7v64oo9gc7.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7v64oo9gc7.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <40b2b7d90601130311v78db741dx7c5eaa57ad300850@mail.gmail.com> ``` Artem Khodush 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... ``` ## sean, 2006-01-13 17:54 Subject: Re: git-commit: allow From: line to be entered in commit message Message-ID: URL: https://gitlist.dev/e/BAYC1-PASMTP0918AE856AD34E35597CA4AE260%40CEZ.ICE In-Reply-To: <7v64oo9gc7.fsf@assigned-by-dhcp.cox.net> ``` On Fri, 13 Jan 2006 09:40:24 -0800 Junio C Hamano 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: > --from="Some User " > I agree this would be more useful, direct, easy to understand and explain way to do it. 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 ``` ## Junio C Hamano, 2006-01-13 19:51 Subject: Re: git-commit: allow From: line to be entered in commit message Message-ID: <7vy81j6h56.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vy81j6h56.fsf%40assigned-by-dhcp.cox.net In-Reply-To: ``` sean 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 ' 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? ``` ## Johannes Schindelin, 2006-01-13 21:53 Subject: Re: git-commit: allow From: line to be entered in commit message Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.63.0601132247530.32562%40wbgn013.biozentrum.uni-wuerzburg.de In-Reply-To: <7vy81j6h56.fsf@assigned-by-dhcp.cox.net> ``` Hi, On Fri, 13 Jan 2006, Junio C Hamano wrote: > sean 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 ' 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 ' it will tell you that you misspelt an option. Try that with GIT_AUTOR_NAME='Me without H ' 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 ```