Thread (1 message) 1 message, 1 author, 2016-06-15

Re: [PATCH v2 0/1] git-clone: fix relative path problem in the alternates

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:51:52

Junio C Hamano [off-list ref] writes:
quoted
3. current existing add_to_alternates_file() will unconditionally append
"/objects" at each new added line, that need us to parse and  remove
"/objects" from each line read out from source alternates, this is a little
bit complicated.
Clone with --reference is the only other caller of that function; I would
say it is perfectly fine to make it the caller's responsibility to append
"/objects" if that makes the resulting code easier to maintain.
I would further suggest moving add_to_alternates_file() from sha1_file.c
to builtin/clone.c and make it file-scope static function, and change the
way it should be used.

 - The caller should first obtain a lock file to info/alternates. If it
   truncates first or opens the file for appending is up to the caller.

 - When adding an alternate (either from --reference or your new
   codepath), the caller should give the lockfile instance it obtained
   earlier, and a path to the object store it wants to borrow objects from
   (not the repository, i.e. the caller should add "/objects" at the end
   if needed before calling the function), to add_to_alternates_file()
   function;

 - The function should just write the path to the locked info/alternates
   file, and link it to alt_odb list. Do not commit the alternates file,
   to allow multiple calls to the function be made without opening and
   closing the file number of times.

 - The caller should commit the updated alternates file once it is done.

While at it, we may probably want to update the command option handling so
that you can give more than one --reference= parameters.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help