On Wed, May 30, 2018 at 11:46:16AM +0900, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > - When we fetch from a remote that has refs/remotes/$name/HEAD, and
> >if the protocol notices that their HEAD today is pointing to a
> >branch different from what our side has, should we repo
Ævar Arnfjörð Bjarmason writes:
> We already have to deal with this special case of origin/HEAD
> being re-pointed in a repository that we "clone", so we would just
> do whatever happens to a repository that's cloned.
OK. Not visiting that issue while we discuss this "origin/HEAD is
useful, so
On Wed, May 30 2018, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>> If you make an initial commit and push to a remote repo "origin", you
>> don't get a remote origin/HEAD reference, and a "fetch" won't create it
>> either.
>> ...
>> Some code spelunking reveals remote_head_points
Junio C Hamano writes:
> - When we fetch from a remote that has refs/remotes/$name/HEAD, and
>if the protocol notices that their HEAD today is pointing to a
>branch different from what our side has, should we repoint ours
>to match?
>
>I am leaning against doing this, but mostl
Ævar Arnfjörð Bjarmason writes:
> If you make an initial commit and push to a remote repo "origin", you
> don't get a remote origin/HEAD reference, and a "fetch" won't create it
> either.
> ...
> Some code spelunking reveals remote_head_points_at, guess_remote_head()
> etc. in builtin/clone.c. I.
On 05/29, Ævar Arnfjörð Bjarmason wrote:
> Here's some more #leftoverbits where we have a clone/fetch feature
> discrepancy and where clone is magical in ways that "fetch" isn't.
>
> If you make an initial commit and push to a remote repo "origin", you
> don't get a remote origin/HEAD reference, a
6 matches
Mail list logo
