Re: [PATCH] Keep committer and committer dates

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

 



Jaroslav Kysela wrote:
> On Thu, 5 Jun 2008, Johannes Schindelin wrote:
> 
>> Clearly, you do not want to be convinced, no matter what arguments are 
>> thrown your way.
> 
> No, I just do not want to be restricted with one way to do things. All 
> what I read is about fear to misuse the proposed feature. It stops 
> evolution, especially in open source - propose to remove 'rm -rf /' from 
> all linux distros.  Anyway, GIT maintainer has a right to not accept my 
> change, altough I think that it's a drawback for other users - not for me. 
> Bye for now.
> 
> 					Jaroslav
> 
> -----
> Jaroslav Kysela <perex@xxxxxxxx>
> Linux Kernel Sound Maintainer
> ALSA Project, Red Hat, Inc.
> 

Please consider looking at this in another way.

You know how in git the crypto signature of the patch, which is it's
"object name" (OID) that you see in git log, also contains it's parent, though 
recursively proving that same OID is exactly, universe wide, the same tree.
and all this stuff about git...

Well consider the "committer" field to be the person how created and signed
that OID. That is, the person that first defined that universe unique tree.
An OID of a patch is not about the patch it's about the tree. And so is the
"committer" field. It's not who wrote the patch, it's about who signed the
tree up to this point.

If you absolutely need to emulate someone else name just do 
$ su that_other_one
But don't ask git to record an information that was not true at that
point in time.

My $0.017
Boaz
--
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]

  Powered by Linux