Re: [RFC] A Change to Commit IDs Too Ridiculous to Consider?

From: Jakub Narębski <jnareb@gmail.com>
Date: Jul 24, 2016, 20:42 UTC
Message-ID: <57952834.60706@gmail.com>
In-Reply-To: <cfff11c9-e212-88a1-c00b-3e7a361e0db9@gmail.com>

W dniu 2016-07-24 o 21:20, Jon Forrest pisze:

Show 8 quoted lines

> On 7/24/2016 11:46 AM, Jakub Narębski wrote:
>> 
>> Another possibility is to set authordate and committerdate to some
>> specified time by the way of appropriate environment variables.
> 
> That sounds like a great idea. Assuming it
> works the way I envision, this wouldn't require
> any changes to the source code.

This would however require for user to write more. The environment variables are GIT_AUTHOR_DATE and GIT_COMMITTER_DATE; their format is described in the "DATE FORMATS" section in the git-commit(1) manpage.

And it is not something that the user would do when working with Git themselves, for their own project.

Show 9 quoted lines

>> What I think you don't realize is that "commit" objects are not
>> treated in any way special. Object identifiers of all objects are
>> SHA-1 hash of uncompressed loose representation of said object
>> (type + length + contents).
> 
> I know this, but I thought that commit object IDs were the only
> ones that included a date in what gets run through the SHA-1
> hash function. If there are others, then you're right - they'd
> need to be included in this proposal.

The problem is that many function in Git are object-type agnostic. Changing how 'commit' objects are treated would require heavy code surgery... unless done as filter (see below), but even then extra code would be needed, for small benefit and large maintenance burden.

Now that I think about this, it could be done when displaying object names (in `git log` and `git show`), replacing true commit object with SHA-1 of those objects with dates stripped. Still needs work.

Show 7 quoted lines

>> Well, you could not record dates in commit object, but I think
>> Git considers such objects broken.
> 
> You mean that Git could, after the fact, detect commit IDs
> that didn't include a date? If this is true, then your
> idea of using fixed dates from environment variables
> would be the only way to do this.

I think^H^H `git fsck` can check that objects are well formed, and warn if they are not.

$ git fsck
error in commit 6deb0829fecdf1feab0cc7c66061a92a93cb19e7: 
  missingSpaceBeforeDate: invalid author/committer line - missing space before date
error in commit 762f28c2567c07d378d485c3e2a498947d49f406: 
  badDate: invalid author/committer line - bad date

Show 5 quoted lines

>> IMVHO it would require heavy surgery of Git for little benefit
>> (see the beginning of reply for alternate solutions).
> 
> Even using your environment variable solution that wouldn't
> require any code changes?

No, this do not need no changes to git code, of course.

-- 
Jakub Narębski