Re: [DRAFT] Branching and merging with git
- From
- linux@horizon.com <linux@horizon.com>
- Date
- Nov 17, 2006, 01:13 UTC
- Message-ID
- <20061117011319.6738.qmail@science.horizon.com>
- In-Reply-To
- <7vslgj2bug.fsf@assigned-by-dhcp.cox.net>
> I find it very balanced to point out the quirks people > would find difficult and explain why things are so by including > historical notes in appropriate places when needed.
I'm trying; I've been following git since day 1, so occasionally an obsolete fact gets stuck in my head.
If anyone has any advice on how and why one would invoke git-merge directly (the one why I know is to do a >2-way merge), that would be appreciated.
> I have finished only the first half because it's not my git day > today, but so far...
Well, thank you for your time!
Show 11 quoted lines
>> * Naming revisions >>... >> Second, you can refer to a head or tag name. Git looks in the >> following places, in order, for a head: >> 1) .git >> 2) .git/refs >> 3) .git/refs/heads >> 4) .git/refs/tags > > You might want to check this with the array in sha1_name.c::get_sha1_basic(). > I think tags comes earlier than heads.
Quite right. It's
static const char *fmt[] = {
"%.*s",
"refs/%.*s",
"refs/tags/%.*s",
"refs/heads/%.*s",
"refs/remotes/%.*s",
"refs/remotes/%.*s/HEAD",
NULL
};Show 13 quoted lines
>> 2) Revert changes to a small number of files. >> >> git checkout [<revision>] [--] <paths> >> will copy the version of the <paths> from the index to the working >> directory. If a <revision> is given, the index for those paths will >> be updated from the given revision before copying from the index to >> the working tree. >> >> Unlike the version with no <paths> specified, this does NOT update >> HEAD, even if <paths> is ".". > > It's great that you talk correctly about the latest feature-fix > that is queued for maint but not yet pushed out.
Um... there's a fix in there? I thought that's how it always worked.
> "If there's a side branch which does NOT touch the paths..." I think.
Ah, yes, I added include/scsi to the example to illustrate how mutiple paths worked and didn't update the later paragraph.
Show 10 quoted lines
>> * Alternate branch naming >> >> The original git scheme mixes tracking branches with all the other heads. >> This requires that you remember which branches are tracking branches and >> which aren't. Hopefully, you remember what all your branches are for, >> but if you track a lot of remote repositories, you might not remember >> what every remote branch is for and what you called it locally. > > I think you wanted to mention .git/refs/remotes hierarchy and > separate-remote here, but haven't elaborated yet...
Yes, sorry. I meant to research that and update this (I've never used it before), but I forgot.
Show 30 quoted lines
>> * Remote tags
>>
>> TODO: Figure out how remote tags work, under what circumstances
>> they are fetched, and what git does if there are conflicts.
>
> refs/tags namespace is not policed at all by git and is treated
> as a global namespace, controlled mostly by social convention
> that your "upstream" (or central distribution point) supplies
> tags for people who use it to synchronize to share. Also, since
> there is no guarantee that tags point at commits (v2.6.11-tree
> tag is a pointer to a tree object, for example), there is no
> farst-forward check performed for them.
>
> The rule we use to autofollow tags currently is:
>
> When you use shorthand fetch (or pull), we find tags that do not
> exist locally, and if the object they point at are already found
> in the repository then we fetch them automatically. So for
> example, if you are only tracking my 'maint' and not 'master'
> nor 'next', and if you have tags up to v1.4.3.2, your "git fetch
> origin" would update your copy of 'maint' and bring the commits
> reachable from the tip of my 'maint'. After that it notices
> that v1.4.3.3, v1.4.3.4, v1.4.3.5 tags are in my repository but
> missing from yours. It also notices that now you have
> v1.4.3.3^{}, v1.4.3.4^{} and v1.4.3.5^{} in your repository, so
> it issues another round of "git fetch" internally to fetch these
> three tags. At the same time it would also notice that I have
> v1.4.4 tag that you do not have, but v1.4.4^0 commit is not
> something you would get by fetching 'maint', so it would not
> fetch it automatically.Ah, okay. Actually, v2.6.11-tree is a tag object (5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c) which points to a tree object (c39ae07f393806ccf406ef966e9a15afc43cc36a).
I was wondering if git only shared refs/tags that pointed to heavyweight tag objects and not lightweight tags.
That appears to be the case:
mkdir a b cd a git-init-db echo "Hello, world" > hello git add hello git commit -m "Initial commit" git tag light git tag -a -m "Test tag" heavy cd ../b git-init-db echo "URL: ../a" > .git/remotes/a echo "Pull: master:origin" >> .git/remotes/a git fetch a
But! It only fetches tags if you specify a destination branch name. I hadn't noticed that before, but "git-fetch <url> foo" and "git-fetch <url> foo:foo" do different things on the receiver. Didn't they used to be synonyms? (I think it's a net gain in flexibility.)
Oh! Also, the git-pull man page says that multiple branch names are allowed, even though the SYNOPSIS line says no.
I also need to mention that if you want to pull a remote tag, you need to prefix it with "tags/". For some reason, the search