Re: efficient cloning

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: efficient cloning

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

Andreas Ericsson [off-list ref] writes:
That way the only extra dwimery would be to add "remotes" after
"heads" under .git/refs and accept directory in .git/remotes/ as ref
and tack on '/master' at the end of it as the last option to
search. For a specific branch on an imported remote, one would have to
say "jc/next". This means we still only handle 'master' specially so
we don't introduce any new protected or special names.
Two things that holding me back from doing what you suggested
are (1) "master" is just a convention and indeed non-negligible
number of kernel.org trees have "test" and "release" instead
without "master"; (2) I'd really really really want to avoid
teaching get_sha1_basic() C-level about .git/remotes/$origin
file, even though that function is more of a UI level than the
rest of the really core C-level routines.

But if I were forced to choose between the above 2, I would
probably pick defaulting to "master".

The reason I would like to avoid .git/remotes/$origin is because
it is designed to be Porcelainish thing.  The underlying C-level
git-fetch-pack never sees it; instead the information fed to
C-level is prepared by the upper layer using that file.  As far
as I understand, Cogito does not understand it either, except
that it ships with bash completion code that reads from
filenames there.

Re: efficient cloning

From: Jeff King <hidden>
Date: 2016-06-15 22:42:22

On Tue, Mar 21, 2006 at 12:42:02AM -0800, Junio C Hamano wrote:
The reason I would like to avoid .git/remotes/$origin is because
it is designed to be Porcelainish thing.  The underlying C-level
git-fetch-pack never sees it; instead the information fed to
C-level is prepared by the upper layer using that file.  As far
as I understand, Cogito does not understand it either, except
that it ships with bash completion code that reads from
filenames there.
Then why not create .git/refs/remotes/$origin/HEAD at the time of clone
(or later)? Then the core looks for:
  (current order, .git/refs, etc)
  .git/refs/remotes/foo
  .git/refs/remotes/foo/HEAD
The porcelain can take care of managing the contents of HEAD. If there
is no HEAD in the directory, then it cannot be looked up by 'foo'
('foo/remote-branch' must be used instead).

-Peff
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help