On Sun, Jul 14, 2024 at 11:43:38AM +0200, Omar Polo wrote:
> This changes the worktree code and the fileindex so they know about
> sha256.  It is only to have `got checkout' and `got update' working,
> there's no code yet to write objects so commit/tag/rebase/merge etc
> won't work.
> 
> The worktree gains a new file, .got/object-format, so that we know what
> to expect when opening a worktree.  The fileindex version is bumped and
> it gains a new field for the hashing algorithm, as well as changes to
> accomodate for sha256 hashes.
> 
> Be careful when testing the diff: several got operations will re-create
> the fileindex and a v3 one will be created.  If we then commit a
> different diff, the worktree may be unusable.  Also, the worktree will
> be unusable by previous got version.
> 
> I'm changing a few uint8_t *_sha1[SHA1_DIGEST_LENGTH] to structures
> got_object_id because it makes a lot of things way more easy to handle.
> 
> I'm not happy about the way I'm handling the absence of the
> object-format file.  read_meta_file doesn't really gives us a way to
> know whether the file is just not there.
> 
> ok?

No, mainly because by adding a new file in .got this patch changes the
work tree format without bumping the work tree format number (checked
by open_worktree()).

I believe the hash algorithm should be stored in the fileindex itself.
Adding another file in .got creates a risk of inconsistency (both
this file and fileindex data must agree).
We could then keep the work tree format the same and only bump the
fileindex version.

Regardless, perhaps both the work tree format number and the fileindex
format number should be bumped. Otherwise old got clients might assume
that writing the current sha1-only format is fine.
However, we currently have no code to upgrade the work tree format since
it has not yet been changed since got-0.1.