Re: [PATCH] Keep committer and committer dates

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jun 5, 2008, 13:13 UTC
Message-ID: <alpine.DEB.1.00.0806051408520.21190@racer>
In-Reply-To: <Pine.LNX.4.61.0806051428390.1798@tm8103-a.perex-int.cz>

Hi,

On Thu, 5 Jun 2008, Jaroslav Kysela wrote:

Show 21 quoted lines

> 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