2009/11/4 Junio C Hamano <gitster@xxxxxxxxx>: > Erick Mattos <erick.mattos@xxxxxxxxx> writes: > >> Cutting --author away would make impossible for someone to force a new author >> with a new timestamp in case he is templating. As an example he can be using >> the --author because he is doing a change in a computer not his own or >> something alike. > > Sorry, but I cannot help feeling a bit frustrated and mildly irritated. > > I had an impression that we have already established that setting the > author with --author="Somebody Else <s@xxx>" and committing with the > current time does not make much sense from the workflow point of view long > time ago in this thread. > > The mail transport might have mangled the name, and when using --amend (or > read-tree followed by commit -c), it is handy to fix the mangled name by > using --author, but in such a case you would actively want to keep the > timestamp obtained from the e-mail via either --amend or -c. > > But allowing this combination, even though it might not make much sense, > is just giving extra length to the rope, so it may not be such a big deal. I don't see a reason to be hassled by a suggestion, made because I didn't really was confident you got it right from me from the previous email flood. No big deal. > I didn't feel motivated enough to read the whole thing while other patches > are in my inbox, so I instead ran diff between the previous one (without > my suggestion today) and this round. I really can't imagine all the work you have. Probably very hard. As we were doing before, you were saying what was wrong to you and I was fixing it to your demands. So I imagine that you are doing the diffs over my versions. I haven't got a change in that way of working. > I see that you fixed a lot of grammar in the log message of my earlier > suggestion, all of which looked very good. Also you added a check in the > program to make sure that --renew is given only when -C/-c/--amend is > given, which is also good. Neither of our set of tests checks this > condition, though. IOW, we would need to add something like this at the > end of my version (adjust to --reset-author for your version): > > test_expect_success '--mine should be rejected without -c/-C/--amend' ' > git checkout Initial && > echo "Test 7" >>foo && > test_tick && > test_must_fail git commit -a --mine -m done > ' > > I am not sure why you insist to use your version of test script and keep > changing it, though. It looks a lot worse even only after reviewing its > early part. As I told you before I thought you were wanting me to do it. I didn't get a change about me working under your supervision as the coder... I know anyone in this list is able to code those or any other change. It is just about who is available to work at anything in particular. > - author_id runs an extra grep that is unnecessary. The separation of > _id and _timestamp are unnecessary if you checked against an expected > author ident and timestamp as a single string, i.e. author_id or author_timestamp could be changed independently and a single string would find it corrected in any case. The new option ought to change both as expected in the algorithm. > FRIGATE='Frigate <flying@xxxxxxxxxx>' ;# do this only once at the beginning > ... > git commit -C HEAD --reset-author --author="$FRIGATE" && > echo "author $FRIGATE $GIT_AUTHOR_TIME" >expect && > author_header HEAD >actual && > test_cmp expect actual If you make my script fail in any of the checks then you are going to have "trash..." folder holding the full message log history and the file foo with each step recorded on it with the "initials" separating the -C, -c and --amend. This way you can also check the differences in the author log timestamp among cited options because the "initials" make a barrier in between. I made it purposely to become easier to audit. > This becomes irrelevant if we don't support mixing --renew and > --author, of course. It won't be supported. > - message_body() now has a backslash whose sole purpose is to be an > eyesore. No backslash then. > - initiate_test() does not string the commands together with && It is not something difficult to add. > I might change my mind after I take a break, review others' patches, and > spend some time on my own hacking on other topics before revisiting this > patch, but at this point I find that reviewing newer rounds of this series > has rather quickly diminishing value, and more time is being spent on > teaching shell scripting to you rather than on polishing the end result. Now you are being impolite and then I am not saying anything back. > Sorry, but I cannot help feeling a bit frustrated and mildly irritated. > Time to take a break and attend other topics for a change. > Again: I don't see a reason to be irritated by a suggestion... Sorry fellow. I just tried to help. Let me know if you want my work anytime. And sorry for any communication problem we had, taking in account that I am not a native english speaker. Best regards. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html