Re: Please undo "Use git-merge instead of git-resolve in

From: Jon Loeliger <jdl@freescale.com>
Date: 2005-09-23 04:32:45
Linus schreib:
>
>	git fetch rsync:..../linus-2.6-git <src>:<dst>
>
> will fetch the <src> branch (ie you'd usually use "master") from my tree 
> and write it to the <dst> branch on your tree.

... "origin".  OK.

Und, Petr schreib auch:
> Then it creates an 'origin' head, and will copy all the history from
> the remote repository's 'master' head there. So this head exists to
> reflect the state of the remote repository. The important point is
> that it is called 'origin' in our new repository, even through it
> corresponds to a 'master' head in the old repository. This is normal -
> you can name your local heads whatever you want.

Wait.

For me, this paragraph suddenly turned on one missing light:
The default construction of repository branches/heads _mismatches_
names on local and remote ends: "origin" local came from "master"
remote.  Did I miss reading that somewhere else? (Likely.)

And I sat through the Great Remote Name Discussion of '05
("How is working on arbitrary remote heads supposed to work in Cogito")
but I just didn't get it back then.

(This is an intentional asymmetry, right?  Distributed systems, right?)

In any case, I just tried this:

    git fetch rsync://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.gi\t master:origin

And got this mess:

    sent 18136 bytes  received 2731519 bytes  60431.98 bytes/sec
    total size is 97584183  speedup is 35.49
    rsync: link_stat "/scm/linux/kernel/git/torvalds/linux-2.6.git/objects/info/alt\ernates" (in pub) failed: No such file or directory (2)
    rsync error: some files could not be transferred (code 23) at main.c(1173)
    * non-commit: 3fd07d3bf0077dcc0f5a33d2eb1938ea050da8da
      branch 'master' of rsync://www.kernel.org/pub/scm/linux/kernel/git/torvalds/l\inux-2.6
    * refs/heads/origin: does not fast forward to branch 'master' of rsync://www.ke\rnel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6;
      leaving it in 'refs/heads/origin.remote'

And this is due to kernel.org being Not Quite Right, right?

Which points out one of the other points of frustration
that I feel should be addressed eventually:  A whole section
about "What To Do When It Goes Wonky" needs to be written.

OK, so it didn't merge?  Now what?  What got left where?
How do I recover?  What bits are in my tree, and what bits
are in the Index, and what bits are in the Object store now?

OK, so it didn't download it left you "refs/heads/rigin.remote".
What should I do with it now?  And later, should I re-execute
the same "git fetch" command and hope it recovers and patches
the pieces together?  Should I do a round of house cleaning
before attempting to re-run some (the same?) command?

Things of that nature.

And more as I get further too. :-)

Thanks!
jdl


-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Received on Fri Sep 23 04:33:31 2005

This archive was generated by hypermail 2.1.8 : 2005-09-23 04:33:34 EST