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

["Jakub Narębski" <jnareb@gmail.com>]

W dniu 2016-07-24 o 21:20, Jon Forrest pisze:
> 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.

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

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

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