{"thread":{"id":"3060","subject":"git-commit: allow From: line to be entered in commit message","startedAt":"2006-01-12T14:37:00Z","lastAt":"2006-01-13T21:53:44Z","messageCount":16,"participants":["sean","Junio C Hamano","Andreas Ericsson","Artem Khodush","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"14550","messageId":"BAYC1-PASMTP117A18814EAAFACFE0F31DAE270@CEZ.ICE","threadId":"3060","inReplyTo":null,"subject":"git-commit: allow From: line to be entered in commit message","fromName":"sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-01-12T14:37:00Z","receivedAt":"2006-01-12T14:37:00Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"\nMostly just for comment to see if there is any support\nfor this feature....\n\nSean\n\n---\nUse the author name and email information given as the \nfirst line of the commit message in the form of:\n\nFrom: name <email>\n\nas the author's name and email address in the resulting\ncommit object.  This makes committing foreign patches\na little less cumbersome to handle for some workflows.\n\n\ndiff --git a/git-commit.sh b/git-commit.sh\nindex 193feeb..6004cd4 100755\n--- a/git-commit.sh\n+++ b/git-commit.sh\n@@ -219,7 +219,7 @@ t)\n \tfi\n esac\n \n-grep -v '^#' < \"$GIT_DIR\"/COMMIT_EDITMSG |\n+grep -v '^#' < \"$GIT_DIR\"/COMMIT_EDITMSG | sed -e '1s/^[ \\t]*from:.*//I' |\n git-stripspace > \"$GIT_DIR\"/COMMIT_MSG\n \n if cnt=`grep -v -i '^Signed-off-by' \"$GIT_DIR\"/COMMIT_MSG |\n@@ -227,6 +227,13 @@ if cnt=`grep -v -i '^Signed-off-by' \"$GI\n \twc -l` &&\n    test 0 -lt $cnt\n then\n+\tFROM=$(grep -v '^#' < \"$GIT_DIR\"/COMMIT_EDITMSG | sed -ne '1s/from:[ \\t]*\\(.*\\)/\\1/Ip;q')\n+\tNAME=$(echo \"$FROM\" | sed -e 's/<.*//;s/[ \\t]*$//')\n+\tEMAIL=$(echo \"$FROM\" | sed -e 's/.*<\\(.*\\)>.*/\\1/')\n+\tif test -n \"$FROM\"; then\n+\t\texport GIT_AUTHOR_NAME=\"$NAME\"\n+\t\texport GIT_AUTHOR_EMAIL=\"$EMAIL\"\n+\tfi\n \ttree=$(git-write-tree) &&\n \tcommit=$(cat \"$GIT_DIR\"/COMMIT_MSG | git-commit-tree $tree $PARENTS) &&\n \tgit-update-ref HEAD $commit $current &&\n"},{"id":"14552","messageId":"BAYC1-PASMTP07EE5172C7652A5DD3131DAE270@CEZ.ICE","threadId":"3060","inReplyTo":"BAYC1-PASMTP117A18814EAAFACFE0F31DAE270@CEZ.ICE","subject":"Re: git-commit: allow From: line to be entered in commit message","fromName":"sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-01-12T15:21:23Z","receivedAt":"2006-01-12T15:21:23Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Thu, 12 Jan 2006 09:37:00 -0500\nsean <seanlkml@sympatico.ca> wrote:\n\n> Mostly just for comment to see if there is any support\n> for this feature....\n\nSorry.  Slightly better version of the patch below:\n\n---\nUse the author name and email information given as the \nfirst line of the commit message in the form of:\n \nFrom: name <email>\n \nas the author's name and email address in the resulting\ncommit object.  This makes committing foreign patches\na little less cumbersome to handle for some workflows.\n\ndiff --git a/git-commit.sh b/git-commit.sh\nindex 193feeb..163e2d7 100755\n--- a/git-commit.sh\n+++ b/git-commit.sh\n@@ -219,14 +219,19 @@ t)\n \tfi\n esac\n \n-grep -v '^#' < \"$GIT_DIR\"/COMMIT_EDITMSG |\n-git-stripspace > \"$GIT_DIR\"/COMMIT_MSG\n+grep -v '^#' < \"$GIT_DIR\"/COMMIT_EDITMSG | git-stripspace | \n+sed -e '1s/^[ \\t]*from:.*//I' | git-stripspace > \"$GIT_DIR\"/COMMIT_MSG\n \n if cnt=`grep -v -i '^Signed-off-by' \"$GIT_DIR\"/COMMIT_MSG |\n \tgit-stripspace |\n \twc -l` &&\n    test 0 -lt $cnt\n then\n+\tFROM=$(sed -ne '/^#/d;/^[ \\t]*$/d;s/from:[ \\t]*\\(.*\\)/\\1/Ip;q' \"$GIT_DIR\"/COMMIT_EDITMSG)\n+\tif test -n \"$FROM\"; then\n+\t\texport GIT_AUTHOR_NAME=$(echo \"$FROM\" | sed -e 's/[ \\t]*<.*//')\n+\t\texport GIT_AUTHOR_EMAIL=$(echo \"$FROM\" | sed -e 's/.*<\\(.*\\)>.*/\\1/')\n+\tfi\n \ttree=$(git-write-tree) &&\n \tcommit=$(cat \"$GIT_DIR\"/COMMIT_MSG | git-commit-tree $tree $PARENTS) &&\n \tgit-update-ref HEAD $commit $current &&\n"},{"id":"14570","messageId":"7vzmm1mcfz.fsf@assigned-by-dhcp.cox.net","threadId":"3060","inReplyTo":"BAYC1-PASMTP117A18814EAAFACFE0F31DAE270@CEZ.ICE","subject":"Re: git-commit: allow From: line to be entered in commit message","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-01-12T20:13:52Z","receivedAt":"2006-01-12T20:13:52Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"sean <seanlkml@sympatico.ca> writes:\n\n> Mostly just for comment to see if there is any support\n> for this feature....\n>\n> Sean\n>\n> ---\n> Use the author name and email information given as the \n> first line of the commit message in the form of:\n>\n> From: name <email>\n>\n> as the author's name and email address in the resulting\n> commit object.  This makes committing foreign patches\n> a little less cumbersome to handle for some workflows.\n\nActually, I've considered this a couple of times in the past,\nbut I ended up saying no.\n\nIf the workflow is driving \"git commit\" from a script (i.e. your\nown Porcelain), the script can set GIT_AUTHOR_* environment\nvariables, so this is a non issue.\n\nWhich means that this 'From: ' thing is coming from the end\nuser.  Either you as the end user pasted it from some text file,\nor typed that line because you knew that the change was made by\nthat person, not by you.\n\nIf you pasted that line from somewhere else, I wonder what that\n\"somewhere else\" file is -- and what else that file contained.\nIf the change came in an e-mail message, we already have tools\nfor that (am/applymbox), and they do not lose the author-date\ninformation as your change to git-commit does, so I think it is\na non issue.\n\nAnd I do not think of anything else that would have author name\nbut does not have a patch text that you can feed git-apply with.\nPasting from your address book just to save typing does not\ncount as \"pasting\" --- that is still typing in this context.\n\nIf you typed that line, why somebody else's change ended up in\nyour working tree is a mystery to me, but let's say an\noffice-mate edited things for you and said \"this should work.\ntest it out and if it is OK commit it for me.\"  I have seen this\nkind of thing done in real life.\n\nIf that is what happened, then what you are adding is a more\nconvenient way than setting two GIT_AUTHOR_* environment\nvariables.  Maybe you forgot about preserving author date, in\nwhich case you would add 'Date: ' as well to your patch, and\nthat would save your user from setting three environment\nvariables.\n\nSo the matter really is how much this patch is better than\nsetting GIT_AUTHOR_* environment variables, unless it simplifies\nthings for other programs (one possibility I have not looked\ninto is that we _might_ be able to use \"git commit\" with this\nmodification from \"git am/applimbox/revert/cherry-pick\").\n"},{"id":"14578","messageId":"43C6CFC5.5010902@op5.se","threadId":"3060","inReplyTo":"7vzmm1mcfz.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-commit: allow From: line to be entered in commit message","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-01-12T21:53:09Z","receivedAt":"2006-01-12T21:53:09Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> \n> If you typed that line, why somebody else's change ended up in\n> your working tree is a mystery to me, but let's say an\n> office-mate edited things for you and said \"this should work.\n> test it out and if it is OK commit it for me.\"  I have seen this\n> kind of thing done in real life.\n> \n\nThis happens from time to time where I work, but I think it would be \nmore useful to have\n\n\t--from=\"Some User <some.user@theoffice.org>\"\n\nwhich would save even more typing.\n\nI had thought of coupling this with some translation-scheme thingie, so \nthat \"--from=jd\" would be automagically converted to the proper name and \nemail address. I first came to think about this when I imported most of \nour projects from CVS, but I ended up doing a quick-hack to \ngit-cvsimport instead.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"},{"id":"14580","messageId":"7v4q49ks83.fsf@assigned-by-dhcp.cox.net","threadId":"3060","inReplyTo":"43C6CFC5.5010902@op5.se","subject":"Re: git-commit: allow From: line to be entered in commit message","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-01-12T22:15:56Z","receivedAt":"2006-01-12T22:15:56Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andreas Ericsson <ae@op5.se> writes:\n\n> Junio C Hamano wrote:\n>\n>> ... let's say an\n>> office-mate edited things for you and said \"this should work.\n>> test it out and if it is OK commit it for me.\"...\n>\n> This happens from time to time where I work, but I think it would be\n> more useful to have\n>\n> \t--from=\"Some User <some.user@theoffice.org>\"\n>\n\nI agree this would be more useful, direct, easy to understand\nand explain way to do it.\n"},{"id":"14588","messageId":"BAYC1-PASMTP102ED7B30D2B48BEE601F5AE260@CEZ.ICE","threadId":"3060","inReplyTo":"7vzmm1mcfz.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-commit: allow From: line to be entered in commit message","fromName":"sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-01-13T02:32:07Z","receivedAt":"2006-01-13T02:32:07Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Thu, 12 Jan 2006 12:13:52 -0800\nJunio C Hamano <junkio@cox.net> wrote:\n\n> Actually, I've considered this a couple of times in the past,\n> but I ended up saying no.\n> \n> If the workflow is driving \"git commit\" from a script (i.e. your\n> own Porcelain), the script can set GIT_AUTHOR_* environment\n> variables, so this is a non issue.\n\nYes, obviously if there is another wrapper this isn't needed because\nthat script could parse the From: line out of the text as well.\n\n> Which means that this 'From: ' thing is coming from the end\n> user.  Either you as the end user pasted it from some text file,\n> or typed that line because you knew that the change was made by\n> that person, not by you.\n> \n> If you pasted that line from somewhere else, I wonder what that\n> \"somewhere else\" file is -- and what else that file contained.\n> If the change came in an e-mail message, we already have tools\n> for that (am/applymbox), and they do not lose the author-date\n> information as your change to git-commit does, so I think it is\n> a non issue.\n\nThis idea came up because recently on tLKML there was someone who \nasked Linus to pull from him that had all the author names as his\nown and a From: line in a bunch of the commit messages.\nWhen I sent him an email asking why he explained that it was\njust too cumbersome to bother setting up the proper author\nusing git environment variables.   Apparently he is more or less\nhand munging mutliple cvs branches into a nice git package for \nLinus to pull.  He said that many of the patches don't apply as-is\nand need some manual tweaking before committing.\n\n \n> And I do not think of anything else that would have author name\n> but does not have a patch text that you can feed git-apply with.\n> Pasting from your address book just to save typing does not\n> count as \"pasting\" --- that is still typing in this context.\n> \n> If you typed that line, why somebody else's change ended up in\n> your working tree is a mystery to me, but let's say an\n> office-mate edited things for you and said \"this should work.\n> test it out and if it is OK commit it for me.\"  I have seen this\n> kind of thing done in real life.\n> \n> If that is what happened, then what you are adding is a more\n> convenient way than setting two GIT_AUTHOR_* environment\n> variables.  Maybe you forgot about preserving author date, in\n> which case you would add 'Date: ' as well to your patch, and\n> that would save your user from setting three environment\n> variables.\n\nNaw, I just don't think the date is as important or generally\ncared about as much, but you're right maybe that'd help someone\ntoo.\n\n> So the matter really is how much this patch is better than\n> setting GIT_AUTHOR_* environment variables, unless it simplifies\n> things for other programs (one possibility I have not looked\n> into is that we _might_ be able to use \"git commit\" with this\n> modification from \"git am/applimbox/revert/cherry-pick\").\n> \n\nYeah, i wondered about that too.\n\nI think something like this patch, or as someone else suggested\none that accepts the author on the command line, is needed.\nHaving to set environment variables for this information just\ndoesn't make much sense if you ever need to change it in a manual\nway, which is bound to happen from time to time.\n\nCheers,\nSean\n"},{"id":"14589","messageId":"BAYC1-PASMTP0804299A4D3C5C1973FF6CAE260@CEZ.ICE","threadId":"3060","inReplyTo":"43C6CFC5.5010902@op5.se","subject":"Re: git-commit: allow From: line to be entered in commit message","fromName":"sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-01-13T02:43:07Z","receivedAt":"2006-01-13T02:43:07Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Thu, 12 Jan 2006 22:53:09 +0100\nAndreas Ericsson <ae@op5.se> wrote:\n\n> Junio C Hamano wrote:\n> > \n> > If you typed that line, why somebody else's change ended up in\n> > your working tree is a mystery to me, but let's say an\n> > office-mate edited things for you and said \"this should work.\n> > test it out and if it is OK commit it for me.\"  I have seen this\n> > kind of thing done in real life.\n> > \n> This happens from time to time where I work, but I think it would be \n> more useful to have\n> \n> \t--from=\"Some User <some.user@theoffice.org>\"\n> \n> which would save even more typing.\n> \n> I had thought of coupling this with some translation-scheme thingie, so \n> that \"--from=jd\" would be automagically converted to the proper name and \n> email address. I first came to think about this when I imported most of \n> our projects from CVS, but I ended up doing a quick-hack to \n> git-cvsimport instead.\n\nYeah, this might be the way to go; however if you are cutting and pasting\nthe commit message already, this might be slightly less convenient because\nnow you have to copy-n-paste to the command line instead of just to your\ncommit editor.   Hopefully it would help to avoid the need for others\nto hack the scripts ;o)   Also it would be nice if it could help simplify\nthe git-am script as Junio suggested too.\n\nSean\n"},{"id":"14596","messageId":"7v4q48hizr.fsf@assigned-by-dhcp.cox.net","threadId":"3060","inReplyTo":"BAYC1-PASMTP102ED7B30D2B48BEE601F5AE260@CEZ.ICE","subject":"Re: git-commit: allow From: line to be entered in commit message","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-01-13T04:03:36Z","receivedAt":"2006-01-13T04:03:36Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"sean <seanlkml@sympatico.ca> writes:\n\n> ...   Apparently he is more or less\n> hand munging mutliple cvs branches into a nice git package for \n> Linus to pull.  He said that many of the patches don't apply as-is\n> and need some manual tweaking before committing.\n\nThen what is needed is an exporter from those cvs branches into\ngit.  Well, don't we have one already?  If it does not work for\ndirty changes, wouldn't it be better to fix it so it is\nrestartable, just like when rebase stops it lets you fix up and\ngo on, without having you to write \"From: \" or GIT_AUTHOR_*\nyourself and just does the right thing?\n"},{"id":"14598","messageId":"BAYC1-PASMTP067B249A8110916F036FB3AE260@CEZ.ICE","threadId":"3060","inReplyTo":"7v4q48hizr.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-commit: allow From: line to be entered in commit message","fromName":"sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-01-13T04:06:33Z","receivedAt":"2006-01-13T04:06:33Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Thu, 12 Jan 2006 20:03:36 -0800\nJunio C Hamano <junkio@cox.net> wrote:\n\n> sean <seanlkml@sympatico.ca> writes:\n> \n> > ...   Apparently he is more or less\n> > hand munging mutliple cvs branches into a nice git package for \n> > Linus to pull.  He said that many of the patches don't apply as-is\n> > and need some manual tweaking before committing.\n> \n> Then what is needed is an exporter from those cvs branches into\n> git.  Well, don't we have one already?  If it does not work for\n> dirty changes, wouldn't it be better to fix it so it is\n> restartable, just like when rebase stops it lets you fix up and\n> go on, without having you to write \"From: \" or GIT_AUTHOR_*\n> yourself and just does the right thing?\n> \n\nYes perhaps there is some streamlining of the cvs importer that could\nbe done.  However, I got the impression from him that he was cherry \npicking stuff out of multiple cvs branches so perhaps that's beyond \nwhat the cvs importer was ever designed to handle.\n\nAnyway, I think this is a more general problem than just the cvs \nimporting case; the current interface for setting author information \nis brain damaged and a better method should be offered.\n\nI think you're over estimating the downsides of allowing this to be\nset the same was as it is in the git-am case and underestimating the\nnumber of people who would find it useful, but I personally don't \nreally care if you'd rather have it as a command line option.\n\nCheers,\nSean\n"},{"id":"14600","messageId":"7vzmm0eod1.fsf@assigned-by-dhcp.cox.net","threadId":"3060","inReplyTo":"BAYC1-PASMTP067B249A8110916F036FB3AE260@CEZ.ICE","subject":"Re: git-commit: allow From: line to be entered in commit message","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-01-13T04:35:54Z","receivedAt":"2006-01-13T04:35:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"sean <seanlkml@sympatico.ca> writes:\n\n> I think you're over estimating the downsides of allowing this to be\n> set the same was as it is in the git-am case and underestimating the\n> number of people who would find it useful, but I personally don't \n> really care if you'd rather have it as a command line option.\n\nYou are obviously not talking about the use of \"git commit\" as a\nbuilding block of some script (if you were, it would not make an\niota of difference whether it is a command line option, an extra\n\"echo From: $name\" prepending that to the body of the message,\nor setting GIT_AUTHOR_* variables).\n\nSo you must be talking about some manual process, at the end of\nwhich the user invokes \"git commit\" from the command line.\n\nBut I would imagine that \"git commit\" is preceded by a bigger\nprocess of preparing the tree to the committable state out of\nwhat is stored in the foreign SCM, after the user figures out\nwhich commit to pick from (in the original example; the\ncommittable state may come from something other than SCM ---\ne.g. set of tarballs or patch application or random monkey\ntyping).  And the whole process of \"preparing the tree\" and\n\"committing\" would be done number of times (otherwise we would\nnot be having this discussion --- just use GIT_AUTHOR_* which is\nalready available), so having to set them as separate steps\nbetween 'preparing the tree' and 'committing using \"git commit\"'\nis cumbersome.\n\nBut you would write 'preparing the tree' (which may include\n\"figuring out who the author is and what the log has to say\" if\nthe committable state is coming from a foreign SCM) script\nanyway, and I simply do not understand why inserting a couple of\nsetting and exporting of GIT_AUTHOR_* variables at the very end\nof that script before calling \"git commit\" from it, to make it\nnot just a 'preparing the tree' script but 'prepare the tree and\ncommit' script is such a big deal for you.\n\nIf the committable state does not come from foreign SCM, then\n'preparing tree' stage may only be able to prepare a committable\ntree, and log and authorship information might need to be\ntyped/pasted by the user.  But then your script would just do\n\"read author\" or \"${VISUAL-vi} .msgfile\" before eventually\ncalling 'GIT_AUTHOR_NAME=\"$author\" git commit -F .msgfile' from\nthere, so I do not think it is such a big deal either.\n\nI guess the disagreement is primarily coming from that you think\n\"git commit\" is always the uppermost UI layer, while I feel \"git\ncommit\" is _one_ possible building block of bigger scripts, but\nthe true building block is \"git commit-tree\".\n"},{"id":"14601","messageId":"BAYC1-PASMTP01A07DAA61F181E9D9679EAE260@CEZ.ICE","threadId":"3060","inReplyTo":"7vzmm0eod1.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-commit: allow From: line to be entered in commit message","fromName":"sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-01-13T04:51:03Z","receivedAt":"2006-01-13T04:51:03Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Thu, 12 Jan 2006 20:35:54 -0800\nJunio C Hamano <junkio@cox.net> wrote:\n\n> You are obviously not talking about the use of \"git commit\" as a\n> building block of some script (if you were, it would not make an\n> iota of difference whether it is a command line option, an extra\n> \"echo From: $name\" prepending that to the body of the message,\n> or setting GIT_AUTHOR_* variables).\n\nCorrect.  Although, even as a building block script this might\nbe a nice little touch; as you mentioned it might be able to \nsimplify the git-am script.\n \n> So you must be talking about some manual process, at the end of\n> which the user invokes \"git commit\" from the command line.\n\nYes, and in truth I only have a vague notion of his process.\n \n> But I would imagine that \"git commit\" is preceded by a bigger\n> process of preparing the tree to the committable state out of\n> what is stored in the foreign SCM, after the user figures out\n> which commit to pick from (in the original example; the\n> committable state may come from something other than SCM ---\n> e.g. set of tarballs or patch application or random monkey\n> typing).  And the whole process of \"preparing the tree\" and\n> \"committing\" would be done number of times (otherwise we would\n> not be having this discussion --- just use GIT_AUTHOR_* which is\n> already available), so having to set them as separate steps\n> between 'preparing the tree' and 'committing using \"git commit\"'\n> is cumbersome.\n\nAgreed, except even in the one-off case I think being able to set\nthe author info on the command line would be better.   The GIT_AUTHOR_*\nvariables only really make sense for defaults, and even that is better\nhandled with .git/config nowadays.\n\n> \n> But you would write 'preparing the tree' (which may include\n> \"figuring out who the author is and what the log has to say\" if\n> the committable state is coming from a foreign SCM) script\n> anyway, and I simply do not understand why inserting a couple of\n> setting and exporting of GIT_AUTHOR_* variables at the very end\n> of that script before calling \"git commit\" from it, to make it\n> not just a 'preparing the tree' script but 'prepare the tree and\n> commit' script is such a big deal for you.\n\nHmmm.. we've already agreed that if there is a script to prepare\nthe tree then this is a non-issue.   We're only talking when\neverything is done from the command line.   In fact, i'm suggesting\nthat if you offer this on the command line (or From: line) that fewer\nscripts would need to be hacked together by git users for some simple\ncases.\n\n> If the committable state does not come from foreign SCM, then\n> 'preparing tree' stage may only be able to prepare a committable\n> tree, and log and authorship information might need to be\n> typed/pasted by the user.  But then your script would just do\n> \"read author\" or \"${VISUAL-vi} .msgfile\" before eventually\n> calling 'GIT_AUTHOR_NAME=\"$author\" git commit -F .msgfile' from\n> there, so I do not think it is such a big deal either.\n\nYes, this is almost what I emailed to the gentleman in the first place,\nbut as you noted there is more than just one variable to set so you can't\ndo it that way.. you end up having to:\n\n$ export GIT_AUTHOR_NAME=\"$author\"\n$ GIT_AUTHOR_EMAIL=\"$email\" git commit -F .msgfile\n\nWhich is cumbersome and also ends up destroying your defaults if you happen\nto use that method, so afterward you have to unset them or reset them back\nto your own author info.   If git handled a GIT_AUTHOR_COMBINED or some such\nwhere you could give the name and email together in one variable which \nwould be parsed, then that suggestion would be slightly more palatable\nbut still seems more obtuse than either just accepting it on the command\nline or via a From: line.\n \n> I guess the disagreement is primarily coming from that you think\n> \"git commit\" is always the uppermost UI layer, while I feel \"git\n> commit\" is _one_ possible building block of bigger scripts, but\n> the true building block is \"git commit-tree\".\n> \n\nYes, I think you nailed it here.   I do see git-commit as a end-user script\nrather than just a building block.\n\nSean\n"},{"id":"14610","messageId":"40b2b7d90601130311v78db741dx7c5eaa57ad300850@mail.gmail.com","threadId":"3060","inReplyTo":"BAYC1-PASMTP01A07DAA61F181E9D9679EAE260@CEZ.ICE","subject":"Re: git-commit: allow From: line to be entered in commit message","fromName":"Artem Khodush","fromEmail":"greenkaa@gmail.com","sentAt":"2006-01-13T11:11:33Z","receivedAt":"2006-01-13T11:11:33Z","isPatch":false,"sender":{"key":"greenkaa@gmail.com","avatar":null},"body":"> $ export GIT_AUTHOR_NAME=\"$author\"\n> $ GIT_AUTHOR_EMAIL=\"$email\" git commit -F .msgfile\n\n> Which is cumbersome and also ends up destroying your defaults if you happen\n> to use that method, so afterward you have to unset them or reset them back\n> to your own author info.\n\nHello,\n\nI had a similar problem on cygwin. I agree that setting environment\nvariables by hand\nis cumbersome, and modifying global environment is undesirable. I ended up with\nwriting shell script, named git-env.sh, that sets all variables\nrequred for git to work,\nand got used to habit of typing\n\n. git-env.sh\n\nevery time I intend to do some work in git.\nWhen that environment is not needed any more,\nI just close that particular shell window.\n\n\nhope this helps,\nArtem.\n"},{"id":"14618","messageId":"7v64oo9gc7.fsf@assigned-by-dhcp.cox.net","threadId":"3060","inReplyTo":"40b2b7d90601130311v78db741dx7c5eaa57ad300850@mail.gmail.com","subject":"Re: git-commit: allow From: line to be entered in commit message","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-01-13T17:40:24Z","receivedAt":"2006-01-13T17:40:24Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Artem Khodush <greenkaa@gmail.com> writes:\n\n>> $ export GIT_AUTHOR_NAME=\"$author\"\n>> $ GIT_AUTHOR_EMAIL=\"$email\" git commit -F .msgfile\n>\n>> Which is cumbersome and also ends up destroying your defaults if you happen\n>> to use that method, so afterward you have to unset them or reset them back\n>> to your own author info.\n>\n> I had a similar problem on cygwin. I agree that setting environment\n> variables by hand\n> is cumbersome, and modifying global environment is undesirable...\n\nHave you two known that more than one environment variables can\nbe set for one-shot command execution?\n\n\t$ GIT_AUTHOR_NAME=\"$author\" \\\n\t  GIT_AUTHOR_EMAIL=\"$email\" git commit -F .msgfile\n\nwould give these environment variables for this \"git commit\"\nwithout affecting the later commands.\n\nNot that this really matters, since the above example was an\nexcerpt of my suggestion about how to do this in a script,\nsomehow made to look as if it was a suggestion about running\nthings by hand from the command line...\n"},{"id":"14620","messageId":"BAYC1-PASMTP0918AE856AD34E35597CA4AE260@CEZ.ICE","threadId":"3060","inReplyTo":"7v64oo9gc7.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-commit: allow From: line to be entered in commit message","fromName":"sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-01-13T17:54:04Z","receivedAt":"2006-01-13T17:54:04Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Fri, 13 Jan 2006 09:40:24 -0800\nJunio C Hamano <junkio@cox.net> wrote:\n\n> Have you two known that more than one environment variables can\n> be set for one-shot command execution?\n> \n> \t$ GIT_AUTHOR_NAME=\"$author\" \\\n> \t  GIT_AUTHOR_EMAIL=\"$email\" git commit -F .msgfile\n> \n> would give these environment variables for this \"git commit\"\n> without affecting the later commands.\n\nNo, I didn't know that; thanks for the lesson.\n\n> \n> Not that this really matters, since the above example was an\n> excerpt of my suggestion about how to do this in a script,\n> somehow made to look as if it was a suggestion about running\n> things by hand from the command line...\n> \n\nI said quite a few times now this has nothing to do with running\ngit-commit from a script.   This is just a simple request\nto not require the use of environment variables to pass useful\nparameters.\n\nI really don't understand your gripe on this one, when someone \nelse suggested using a command line parameter for author\ninformation you said:\n\n<quote>\n\n> \t--from=\"Some User <some.user@theoffice.org>\"\n>\n\nI agree this would be more useful, direct, easy to understand\nand explain way to do it.\n\n</quote>\n\n\nSo do you still agree with that, would you accept a patch?  Or do you have\nsome fundamental reason to think that environment variables are a better\nway to pass information in this case?\n\nCheers,\nSean\n"},{"id":"14629","messageId":"7vy81j6h56.fsf@assigned-by-dhcp.cox.net","threadId":"3060","inReplyTo":"BAYC1-PASMTP0918AE856AD34E35597CA4AE260@CEZ.ICE","subject":"Re: git-commit: allow From: line to be entered in commit message","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-01-13T19:51:17Z","receivedAt":"2006-01-13T19:51:17Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"sean <seanlkml@sympatico.ca> writes:\n\n> So do you still agree with that, would you accept a patch?  Or do you have\n> some fundamental reason to think that environment variables are a better\n> way to pass information in this case?\n\nFundamental reason of not doing anything is (1) not to make\nunnecessary changes and (1) to avoidi decisions ;-).\n\nNo objections to --from='John Doe <john.doe@example.com>' by\nitself, other than \"You could say GIT_AUTHOR_* before the\ncommand instead of --from after the command; as long as it is\nnot done regularly as an interactive command, the difference\ndoes not matter\".  At that point, \"making no unneeded changes\"\nkicks in.  While I do understand that it might be necessary to\ncommit somebody else's patch occasionally, you have not\nconvinced me that is not such a rare thing, so until then the\nchange stays at lower priority.\n\nAfter I am convinced that it is not so rare and having an easier\nand more consistent way (something coming from environment and\nother things from command line is inconsistent) would generally\nbe a good addition, I further need to think about these issues\nbefore taking such a patch, in the context of the \"git commit\"\ncommand as a whole:\n\n - Is --from the right word?  Shouldn't it be --author?\n - Do we want author date?  If not, why not?\n - What about committer information?  If not, why not?\n"},{"id":"14636","messageId":"Pine.LNX.4.63.0601132247530.32562@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"3060","inReplyTo":"7vy81j6h56.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-commit: allow From: line to be entered in commit message","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-01-13T21:53:44Z","receivedAt":"2006-01-13T21:53:44Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 13 Jan 2006, Junio C Hamano wrote:\n\n> sean <seanlkml@sympatico.ca> writes:\n> \n> > So do you still agree with that, would you accept a patch?  Or do you have\n> > some fundamental reason to think that environment variables are a better\n> > way to pass information in this case?\n> \n> Fundamental reason of not doing anything is (1) not to make\n> unnecessary changes and (1) to avoidi decisions ;-).\n\nYou forgot the 3rd (1).\n\n> No objections to --from='John Doe <john.doe@example.com>' by\n> itself, other than \"You could say GIT_AUTHOR_* before the\n> command instead of --from after the command; as long as it is\n> not done regularly as an interactive command, the difference\n> does not matter\".\n\nWell, they are not completely idempotent. If you call\n\n\tgit commit --form='Me <bla@bla.com>'\n\nit will tell you that you misspelt an option. Try that with\n\n\tGIT_AUTOR_NAME='Me without H <dumm@my.com>' git commit\n\n\n>  - Is --from the right word?  Shouldn't it be --author?\n>  - Do we want author date?  If not, why not?\n>  - What about committer information?  If not, why not?\n\nThese are very valid objections, however. As is: why would you want to do \nthat instead of creating an mbox-style file in the first place. \n\nIIRC there was this strange use case which tried to make a clean git tree \nfrom several CVS repositories. IMHO it is much easier to cvsimport them, \nand fix everything from within git, which should be relatively easy with \nthe nice recursive merge.\n\nMy 2 cents,\nDscho\n"}]}