> I find it very balanced to point out the quirks people
quoted text
> 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.

quoted text
> I have finished only the first half because it's not my git day
> today, but so far...

Well, thank you for your time!

quoted text
>> * 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
        };

quoted text
>> 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.

quoted text
> "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.

quoted text
>> * 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.

quoted text
>> * 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
path is different.
-
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