On Thu, 2005-04-21 at 22:29 +0200, Petr Baudis wrote: > Dear diary, on Thu, Apr 21, 2005 at 06:21:58PM CEST, I got a letter > where Martin Schlemmer <[EMAIL PROTECTED]> told me that... > > Hi, > > Hi, > > > Just pulled linux-2.6.git, and got this: > > > > ---- > > New branch: 3a6fd752a50af92765853879f4a11cc0cfcd0320 > > Tracked branch, applying changes... > > Merging 4d78b6c78ae6d87e4c1c8072f42efa716f04afb9 -> > > 3a6fd752a50af92765853879f4a11cc0cfcd0320 > > to a2755a80f40e5794ddc20e00f781af9d6320fafb... > > > > Enter commit message, terminated by ctrl-D on a separate line: > > Merge with 3a6fd752a50af92765853879f4a11cc0cfcd0320 > > ---- > > > > Weird thing was that I made no changes. > > did you compensate for the renamed hashes? Didn't you before update from > some very old git-pasky version? > > Actually, did you do that git init _after_ the unsuccessful pull, or > before? >
I re-pulled it from scratch after the sha1 changes, so not that. Just
the next pull that went wonky.
> > Digging a bit deeper, I saw that .git/HEAD was a symlink
> > to .git/heads/master, and the tracked branch was 'origin'. Due to the
> > fact that Linus only have a .git/heads/master on his rsync, and this
> > thus updated to the new sha1, but the 'origin' (and tracked) head is
> > still pointing to an older sha1 caused this confusion.
>
> Duh. The remote branch always grabs the HEAD over there; you don't need
> to care about the various branches over there, and you really do not
> *want* to care. Actually I might add some ^branchname to the rsync URL,
> to be able to refer to particular branches inside of the repository.
>
Well, I just did a quick peek. I thought it just changed the local head
to the sha1 of the remote, and then updated the local files - haven't
yet looked at gitmerge.sh.
> > I replicated the linux tree via:
> >
> > ----
> > git init URL
> > ----
> >
> > So I had a look at gitinit.sh, which first creates the .git/heads/master
> > and symlinks HEAD to it, then on seeing a URL was supplied, creates
> > a .git/heads/origin, track it, but do *not* change the .git/HEAD
> > symlink ... Is this intended? I see also that gittrack.sh do not update
> > the HEAD symlink ... Is this also intended?
>
> Yes.
>
> You never work directly on the remote branch. Ever. That's what this
> tracking stuff is for; you set up a local branch which follows the
> remote one.
>
Ok, but for some weird reason it wanted to commit the merge between
remote and local.
> Otherwise, you fork to two trees, one is remote branch, second is local
> branch, and you do git pull remotebranch in the second. You are in
> trouble now. Also, if you do some local commit on the remote branch,
> what would happen? This kind of stuff is why I decided that you just
> cannot work on remote branches directly.
>
> > The last option however brings a problem or two. First, how do you do
> > the multi-head thing? Maybe add a command 'git lsheads' (and while at
> > it, also add 'git lstags'?)? Secondly, if there was more than one head,
>
> Perhaps it would be useful to have some "command classes" (with at least
> cg-*-(add|ls|rm)), like:
>
> cg-branch-ls
> cg-remote-rm
> cg-tag-add
>
Might make things more sane.
> > the local copy needs to be checked out ... don't know if 'git cancel' is
> > the logical thing the user will think to do ('git clone' perhaps?) ...
>
> I don't know what do you mean here.
>
Don't worry, no biggy.
--
Martin Schlemmer
signature.asc
Description: This is a digitally signed message part
