{"thread":{"id":"21465","subject":"Re: [PATCH] commit -c/-C/--amend: reset timestamp and authorship to committer with --mine","startedAt":"2009-11-03T18:21:50Z","lastAt":"2009-11-03T18:21:50Z","messageCount":1,"participants":["Erick Mattos"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"126664","messageId":"55bacdd30911031021s6d5ac03aka0f0b5aae273db1@mail.gmail.com","threadId":"21465","inReplyTo":null,"subject":"Re: [PATCH] commit -c/-C/--amend: reset timestamp and authorship to committer with --mine","fromName":"Erick Mattos","fromEmail":"erick.mattos@gmail.com","sentAt":"2009-11-03T18:21:50Z","receivedAt":"2009-11-03T18:21:50Z","isPatch":true,"sender":{"key":"erick.mattos@gmail.com","avatar":"https://avatars.githubusercontent.com/u/134001?v=4"},"body":"Please don't forget your comments down here wasn't about the last sent\npatch.  Please see it, in case you don't have it, at:\nhttp://marc.info/?l=git&m=125712272606721&w=2\n\nAnyway I am answering your comments down here:\n\n2009/11/2 Junio C Hamano <gitster@pobox.com>:\n> Erick Mattos <erick.mattos@gmail.com> writes:\n>\n>> 2009/11/1 Junio C Hamano <gitster@pobox.com>:\n>>> Erick Mattos <erick.mattos@gmail.com> writes:\n>>>\n>>>>>    % git commit --claim --author='Erick Mattos <eric@mattos>' -C HEAD\n>>>>>\n>>>>> Should you detect an error?  Does your code do so?  Do you have a test\n>>>>> that catches this error?\n>>>>\n>>>> It works as intended.  Both together.\n>>>\n>>> That does not make any sense.  If you are saying this is yours and it is\n>>> his at the same time, there can be no sane way to work \"as intended\", no?.\n>>\n>> I am adding a new option not changing the option --author already in\n>> git.  So it does work together.\n>\n> Somebody who says \"this commit is mine, and its author is this other\n> person\" is not making any sense.  The resulting commit can either have\n> that person (i.e. the committer) as the author, which is what the \"claim\"\n> option means, or it can have the person named with --author as the author,\n> but both cannot be true at the same time.\n>\n> When you introduce a new option, sometimes it cannot sanely be used with\n> an existing option.  In such a case, two options (the new one and the\n> existing one) are called mutually exclusive.  And you add some code to\n> catch an user error to use them together.\n\nAs --author text says: \"override author for commit\".\nAs I see, something that OVERRIDES supersedes everything else.\nIMHO --author shouldn't be blocked by the new option.  Probably your\npoint is about \"mine\" name.\nCutting --author away would make impossible for someone to force a new\nauthor with a new timestamp in case he is templating.  Of course he\ncan be using the --author because he is doing a change in a computer\nnot his own or something alike.  So I would not wipe \"author\" out from\nthe new option.\nPlease don't forget that I am just being a small contributor.  I am\njust suggesting things.  You have the final word.\n\n>>>>>> +     git commit -c HEAD <<EOF\n>>>>>> +     \"Changed\"\n>>>>>> +     EOF &&\n>>>>>\n>>>>> What editor is reading this \"Changed\"?\n>>>>\n>>>> Nobody cares...  Just a text to change the file.\n>>>\n>>> I actually care.  Who uses that Changed string, and where does it end up\n>>> with?  At the end of the log message?  At the beginning?  What \"file\"?\n>>\n>> I didn't get it.  -c option does not accept -m option and starts an\n>> editor to change the message.  The text \"Changed is just a forced\n>> message.  I can not use an editor in interactive mode in a script...\n>\n> How are the existing tests that try \"commit -c\" do this?  I do not think\n> there is any here-text redirect into \"git commit\".\n\nSorry, it was automatic for me.  Just supposing a here-text...   :-)\nI am going to fix it.\n\n> It is sometimes easier to show by example than by giving nudging words\n> that only show direction, so here is a suggested rewrite on top of your\n> patch.  I am not very happy with the option name \"mine\" either, but at\n> least I think this gets the semantics right.\n\nWe could call it --reset-author.  What do you think?\n\n> +       if (force_author && renew_authorship)\n> +               die(\"Using both --mine and --author does not make sense\");\n> +\n\nAs previously said up there.\n"}]}