Re: Switching heads and head vs branch after CVS import

On Mon, 15 Aug 2005, Martin Langhoff wrote:

quoted

So in a cvsimport, you'll never see a merge back to the head, even if one
technically took place.

There may be some surprises in here! gitk --all shows at least one
branch opening and merging back into origin, and it has figured it out
correctly

Oh, wow. The new cvsimport is obviously being a hell of a lot smarter than 
my original one was. Goodie.

Except for the keyword expansion. surely there's a way to tell cvsps
to not do it. Why would we ever want it?

Ahh. I don't think we should blame cvsps, I think cvsimport should use the 
"-ko" flag to disable keyword expansion or whatever the magic flag is.

Sven, Matthias, opinions? I've never used CVS keyword expansion, and 
always felt it was pointless, but hey..

quoted

branches and heads are the same thing in git. 

right. There are two separate directories in .git for them, so I was
misled by that. Should I assume git is safe from name clashes or is it
up to porcelain to deal with such minutiae?

Well, you actually are _expected_ to get clashes.

What happens normally (at least for core git) is that the ".git/branches"  
directory contains external sources for the branches (for example, a "git
clone" will fill in the "origin" source, while I often have a
".git/branches/parent" in my tree because). That is just a pointer to 
where the external branch exists.

Then, when you do something like

	git fetch parent

it will look up the source of "parent" by looking in the
".git/branches/parent" file, and update the ".git/refs/heads/parent" 
branch appropriately from that external branch.

So in this example the parent "head" ("local branch") points to the actual
_commit_ we have, while the ".git/branches/parent thing points to what 
_external_ branch it came from.

But yes, you _can_ mess this up if you want to. If you have the same 
"external branch" name that you use for an "internal branch", you deserve 
all the confusion you get ;)

		Linus