Re: [PATCH] Keep committer and committer dates

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

 



Hi,

On Thu, 5 Jun 2008, Jaroslav Kysela wrote:

> On Thu, 5 Jun 2008, Johannes Sixt wrote:
> 
> > Johannes Schindelin schrieb:
> > > 
> > > On Thu, 5 Jun 2008, Stephan Beyer wrote:
> > > 
> > >>> - as has been pointed out several times now, you _are_ the 
> > >>>   committer, and you seem to want to lie there.
> > >> Lying is already possible with GIT_COMMITTER_{NAME,EMAIL,NAME} 
> > >> environment variables.
> > > 
> > > Of course it is possible!  I even pointed to a method!
> > > 
> > > The _point_ was that we do not want to recommend it.  And giving 
> > > prominent support for it, such as introducing a command line 
> > > parameter, _would_ have the effect of recommending it.
> > 
> > Furthermore, if you mess with committer dates, you can screw up revision
> > walking to some degree. committer dates aren't merely informational.
> 
> Of course, you can find many reasons to not use this function.

The reasons were not so much about avoiding to use it, but avoiding to 
introduce it, because the existence alone would cause more harm than good.

The existence would help people lie about who did what, and confuse rather 
than help users find who did what (and whom to blame^Wask for assistance).

It would make a wonderfully helpful tool less helpful.

> I just used the proposed function when we migrated from HG to GIT to 
> rebase with actual Linus's tree without touching commiters (because I've 
> not changed patches itself).

But that would have been much easier with a single graft and a subsequent 
clone, no?

> Also, having a possibility to easy remove a changeset (hardly - not 
> revert) without touching all other changesets on top is a function worth 
> to include.

The problem there is that you -- again -- lie about the committers.  They 
_never_ saw, approved, or tested those commits.

Unless the trees were identical, in which case grafting is the way to go.

> If there are not real technical reasons agains, it should go in.

I hope that I finally made it clear that I do not see technical reasons 
against it.

> I saw only "political" comments that it's evil to do so in some (most 
> of) cases.

If you really think this is about politics instead of semantics, then I 
did not get my point across.

Sad,
Dscho

--
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