remotes

remotes

[Lev]

Dear List,


I accidentally added a remote of another repository to my config file. And so I
merged two different repositories together. Is there any real user case for
this? Is there any way to prevent this happening?

Thanks,
Lev

Re: remotes

[Junio C Hamano]

Lev <leventelist@gmail.com> writes:

> I accidentally added a remote of another repository to my config file. And so I
> merged two different repositories together. Is there any real user case for
> this?

Using multiple remotes is a perfectly normal way in which you are
expected to interact with a single project with other participants.
Perhaps there is one single authoritative and canonical repository
where everybody initially clones from, and it is likely that that
repository is your "origin".  Often there are cases where another
participant has a topic that is not yet ready for the mainline but
is worth considering for early adopters and/or is solid enough for
other project participants to build their work on.  In such cases,
you can add the repository of that other participant as the second
remote and fetch from her.

It makes no sense if the two repositories hold histories of totally
unrelated projects, of course.

Re: remotes

[Kovacs Levente]

[-- Attachment #1: Type: text/plain, Size: 1333 bytes --]

On Tue, 03 May 2016 13:38:22 -0700
Junio C Hamano <gitster@pobox.com> wrote:

> Lev <leventelist@gmail.com> writes:
> 
> > I accidentally added a remote of another repository to my config
> > file. And so I merged two different repositories together. Is there
> > any real user case for this?  
> 
> Using multiple remotes is a perfectly normal way in which you are
> expected to interact with a single project with other participants.
> Perhaps there is one single authoritative and canonical repository
> where everybody initially clones from, and it is likely that that
> repository is your "origin".  Often there are cases where another
> participant has a topic that is not yet ready for the mainline but
> is worth considering for early adopters and/or is solid enough for
> other project participants to build their work on.  In such cases,
> you can add the repository of that other participant as the second
> remote and fetch from her.

Yes, I use that feature.
 
> It makes no sense if the two repositories hold histories of totally
> unrelated projects, of course.

Would it make sense to implement some protection against these kind of
accidents? At least a question "are you sure you want to merge two
independent repositories/branches?"

Thanks,
Lev


-- 
73 de HA5OGL
Op.: Levente

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: remotes

[Stefan Beller]

On Tue, May 3, 2016 at 4:36 PM, Kovacs Levente <leventelist@gmail.com> wrote:
> On Tue, 03 May 2016 13:38:22 -0700
> Junio C Hamano <gitster@pobox.com> wrote:
>
>> Lev <leventelist@gmail.com> writes:
>>
>> > I accidentally added a remote of another repository to my config
>> > file. And so I merged two different repositories together. Is there
>> > any real user case for this?
>>
>> Using multiple remotes is a perfectly normal way in which you are
>> expected to interact with a single project with other participants.
>> Perhaps there is one single authoritative and canonical repository
>> where everybody initially clones from, and it is likely that that
>> repository is your "origin".  Often there are cases where another
>> participant has a topic that is not yet ready for the mainline but
>> is worth considering for early adopters and/or is solid enough for
>> other project participants to build their work on.  In such cases,
>> you can add the repository of that other participant as the second
>> remote and fetch from her.
>
> Yes, I use that feature.
>
>> It makes no sense if the two repositories hold histories of totally
>> unrelated projects, of course.
>
> Would it make sense to implement some protection against these kind of
> accidents? At least a question "are you sure you want to merge two
> independent repositories/branches?"

A recent addition is the check for unrelated histories via checking for added
root commits (i.e. commits with no parent) and refusing to merge them
by default.
you need to pass --allow-unrelated-histories to merge.

see
https://kernel.googlesource.com/pub/scm/git/git/+/e379fdf34fee96cd205be83ff4e71699bdc32b18

>
> Thanks,
> Lev
>
>
> --
> 73 de HA5OGL
> Op.: Levente

Re: remotes

[Junio C Hamano]

Stefan Beller <sbeller@google.com> writes:

> A recent addition is the check for unrelated histories via
> checking for added root commits (i.e. commits with no parent) and
> refusing to merge them by default.  you need to pass
> --allow-unrelated-histories to merge.
>
> see
> https://kernel.googlesource.com/pub/scm/git/git/+/e379fdf34fee96cd205be83ff4e71699bdc32b18

That commit however is not about "checking for added root commits",
which would be way more expensive to compute.  That commit is merely
about detecting that the other history does not have _any_ relation
to ours.

The difference is in this sequence.

 (1) Alice owns the canonical history.
 (2) Bob copies Alice's tip tree without history, starts a
     different root, and builds some history.
 (3) Alice builds some more history.
 (4) Bob pulls from Alice.  The check in e379fdf3 triggers here, but
     Bob can override it.
 (5) Alice builds even more history.
 (6) Bob also builds even more history.
 (7) Bob asks Alice to pull from him.
 (8) Alice pulls from Bob.  The common ancestor discovery finds the
     merge base between (4) and (5), which is (3).

    ---(1)---(3)---(5)---(8)
                \        /
          (2)---(4)---(6)

The history traversal is done at (8) to find merge-base for two
purposes.  One is to find the common ancestor to use in 3-way merge,
and the other is for the check introduced by e379fdf3.  It stops at
finding (3), and does not traverse the history all the way down to
(2).  But in order for Alice to notice that the merge would pull a
new root Alice never has seen, i.e. (2), a traversal needs to
continue down to the root of other's history.

Naively, it would be running

	rev-list --max-parents=0 ^HEAD MERGE_HEAD

and see if the result is not empty, in which case you found (2).
But that is way too expensive unless (2) is relatively shallow.

Re: remotes

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> The difference is in this sequence.
>
>  (1) Alice owns the canonical history.
>  (2) Bob copies Alice's tip tree without history, starts a
>      different root, and builds some history.
>  (3) Alice builds some more history.
>  (4) Bob pulls from Alice.  The check in e379fdf3 triggers here, but
>      Bob can override it.
>  (5) Alice builds even more history.
>  (6) Bob also builds even more history.
>  (7) Bob asks Alice to pull from him.
>  (8) Alice pulls from Bob.  The common ancestor discovery finds the
>      merge base between (4) and (5), which is (3).

Correction.  That merge-base is between (6) and (5); I renumbered
the steps while writing the document and failed to update the
reference.

>     ---(1)---(3)---(5)---(8)
>                 \        /
>           (2)---(4)---(6)
>
> The history traversal is done at (8) to find merge-base for two
> purposes.  One is to find the common ancestor to use in 3-way merge,
> and the other is for the check introduced by e379fdf3.  It stops at
> finding (3), and does not traverse the history all the way down to
> (2).  But in order for Alice to notice that the merge would pull a
> new root Alice never has seen, i.e. (2), a traversal needs to
> continue down to the root of other's history.
>
> Naively, it would be running
>
> 	rev-list --max-parents=0 ^HEAD MERGE_HEAD
>
> and see if the result is not empty, in which case you found (2).
> But that is way too expensive unless (2) is relatively shallow.

A not-so-naive optimization Linus alluded to in the discussion that
was a tangent of e379fdf3 was to teach unpack-objects and index-pack
to report when they see any root commits in the payload.  When Alice
pulls from Bob at (8), one of these two programs would already be
examining every object received from Bob's history, and they can
notice the presense of (2), a new root commit, and report it to the
caller with minimum additional cost.

Unfortunately that approach will not work in the general case of
"fetch to examine first and then decide to merge" workflow, as there
is no medium the first step, i.e. "fetch", can use to convey the
fact that it saw a new root to the later step, i.e. "merge".  Doubly
unfortunate is that "git pull" is in fact implemented in terms of
handling that general case.  We _might_ be able to futz with the
file format used in FETCH_HEAD to help "git pull", but that would
not help a true user-space "git fetch $there master:there/master"
followed by "git merge there/master" workflow.