Re: git-rev-list in local commit order

From: Sean <seanlkml@sympatico.ca>
Date: May 15, 2005, 19:57 UTC
Message-ID: <4971.10.10.10.24.1116187076.squirrel@linux1>
In-Reply-To: <1116186533.11872.152.camel@tglx>

On Sun, May 15, 2005 3:48 pm, Thomas Gleixner said:

Show 14 quoted lines

> On Sat, 2005-05-14 at 17:44 -0400, Sean wrote:
>> Attached is a preliminary hackish patch to sort git-rev-list in local
>> commit order.
>
> +unsigned long sha1_local_date(const unsigned char *sha1)
> +{
> +       struct stat st;
> +       if (find_sha1_file(sha1, &st))
> +               return st.st_mtime;
> +       return 0;
> +}
>
> Do you really want to base workflow and history information on file
> times ?

The local commit order just isn't all that important in many situations. And for situations where it is important, this proposal seems completely adequate. Mind you, the patch in question is complete crap.

> File times are local and completely error prone in distributed
> environments.

I disagree that they're inherently error prone, steps can be taken to make them as secure as you desire. Also, many people just will not care about this local-commit-time as they will simply be tracking a remote repository. For applications like David Woodhouse's need to present the newest commits first on a web page, this is _completely_ adequate. I've yet to see an intended use for this information that isn't completely handled by this proposal. Afterall, most people using git are getting by just fine without such a facility today.

Regards, Sean