Re: [PATCH v2] commit -c/-C/--amend: reset timestamp and authorship to committer with --reset-author

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hey, I do understand you can be very stressed.  It is a huge project.
Very important for an uncountable group of people.  A lot of demands
and argumentation from all over.

I know too that it is human nature to ask other people to agree with
them completely.  Much more when they are in charge.

So, no problem.  It was just a big surprise when I read your email.
You had been so nice to me until that moment...

But let's keep talking about code.  I am not a big fan of human nature subjects.

Although I have to be more personal for just a little.  I want to show
you my way of seeing things:

I love defaults!  A command or an option already set for the most
common scenario... It's wonderful.

But I like to have full control of any tool I use.  If I want to do
any bizarre thing nobody has
ever thought about... I think I should be able to.  Without any hacking.

I can hammer a nail with a wrench.  But I would prefer a hammer for that.

I think your suggestions which changed the path of this intended
function since the beginning were very good for a default.  So I think
--reset-author did it.  Normally 95% of the time its behavior is what
people will be needing.

But cutting off a remote possibility for no heavy and unbearable
reason imho makes features incomplete.  That is why I had suggested
not cutting off --author functionality when using --reset-author.

I did not try to conceive all possible uses for this combination but I
knew someone could find some.  I have told you a simple case just to
picture some figures.  Nanako showed you a case you agreed.  Thanks
Nanako.

I was not defying your judgment or showing lack of respect to you.  My
text after "---" was very clear about that.  Thank you again Nanako
for showing me the importance of this little text.

About scripting abilities: I don't see a way to compare scripting
"levels".  Scripts are so easy that you just know or not.

Different approaches could be compared.  At start I really did not get
the use of the "t" folder tests.  I thought it was just to show
functionalities.

Nanako in her critics made me understand within her speach the
importance of those tests.  Then you clarified it much more later.  So
I got those informations and made another script trying to test
--reset-author completely.  Separating every bit of data that could
show a malfunctioning.  And taking also the care of letting auditing
more reliable and informational.

So I accepted your rough saying about "teaching" as an explosion of stress.

I have to tell that our work-flow on that time was: you demanded and I
made a change.  The script you added was an example to me under this
work-flow.

I am not a kid and I have a real and busy life but I do think spending
time sharing some changes I use to improve something which I value is
not a lost time.  As you can see by the time I had sent the emails, I
was doing them overtime.

So I would like to make clear that I did and do want to help as much
as I can.  If it is not possible to use my work then just know you and
every free software coder has a big fan in me.  I will be transmitting
good energies to you all in any case.

No hard feelings.  :-)

I hope you can continue doing the wonderful work you have been doing
for a very long future.

Best regards.

2009/11/5 Junio C Hamano <gitster@xxxxxxxxx>:
> Nanako Shiraishi <nanako3@xxxxxxxxxxx> writes:
>
>> It may be wise to forbid a combination of options if it
>> encourages mistakes or a wrong workflow, but I don't think
>> using --author and --reset-author with 'git commit --amend'
>> is such a case.
>>
>> Imagine somebody other than you (eg. me) were the maintainer,
>> and a message by Szeder was sent with a good commit log message.
>>
>>  http://article.gmane.org/gmane.comp.version-control.git/132029
>>
>> Then you sent a replacement patch that solves the same problem
>> in a more elegant way, but without anything that is usable as the
>> commit log message.
>>
>>  http://article.gmane.org/gmane.comp.version-control.git/132041
>>
>> If I were the maintainer, I would find it very convenient if I can
>> work like this:
>>
>>  % git am -s 132029   --- first I apply Szeder's version
>>
>> Then I see your message. Replace the code change but use Szeder's
>> log message.
>>
>>  % git reset --hard HEAD^
>>  % git am 132041   --- your version with no usable log message
>>  % git commit --amend -s -c @{2} --author='Junio C Hamano <...>'
>
> Thanks.
>
> So you commit Szeder's and then commit mine (make them independent), and
> amend the log message of the latter using the message from the former, and
> assign the authorship of the latter to the resulting commit?
>
> That is a much more understandable argument than just claiming "--author
> should be usable with --reset-author" without clearly stating why that
> would help.  I think you forgot to add --reset-author to the last command
> line, though.
>
> But I think it is showing that --reset-author is actually suboptimal way
> to solve your scenario.  In the last command in your sequence, you don't
> want to add "--reset-author --author=X" but want "--reuse-only-message"
> option.
>
> And I think it makes much more sense than the alternative semantics we
> came up with during this discussion.  --mine (or --reset-author) to
> declare that "I am the author" was not what we wanted after all(yes, I am
> guilty for suggesting it).  What we want is "I am using -C/-c/--amend and
> I want to borrow only the message part from the named commit (obviously
> "amend" names the HEAD commit implicitly).  Determine the authorship
> information (including author timestamp) as if I didn't use that option."
>
--
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]