Switching heads and head vs branch after CVS import

Switching heads and head vs branch after CVS import

[Martin Langhoff]

After having done a cvs import of Moodle using git-cvsimport-script
all the cvs branches show up as heads. How do I switch heads within a
checkout? cogito doesn't seem to be able to, and I'm unsure on how to
do it with git.

And I am confused about the difference between heads and branches. Git
and cogito seem  prepared to merge across the heads (using cg-update
for instance, when pointed to a different head merged it in, rather
than switched to it), that would match a workflow where a group of
people maintain very closely related heads and merge constantly
across.

Branches don't seem to have the same expectation or support in the
toolset. Why? What makes a branch different from a head, apart from
the fact that they would be expected to drift further apart?

In any case, should the cvsimport turn cvs branches into git branches
instead of heads? Is there are way to turn a head into a proper
branch?

cheers,

martin

Re: Switching heads and head vs branch after CVS import

[Junio C Hamano]

Martin Langhoff <martin.langhoff@gmail.com> writes:

> After having done a cvs import of Moodle using git-cvsimport-script
> all the cvs branches show up as heads. How do I switch heads within a
> checkout? cogito doesn't seem to be able to, and I'm unsure on how to
> do it with git.

The documentation may be quite sketchy on this front.

I do not speak for Pasky, so Cogito may treat them a little
differently, but at the core GIT level, you can treat branches
and heads synonymously.

What you have recorded in .git/refs/heads/frotz file is the SHA1
object name of the commit that is at the top of "frotz" branch.
When your .git/HEAD symlink points at refs/heads/nitfol, your
working tree is said to be on "nitfol" branch.

You switch branches by using "git checkout".  You can create a
new branch using "git checkout -b newbranch commit-id".  You
examine which branch you are on by "readlink .git/HEAD".  As you
already found out, you can merge branches with "git resolve
master other-branch 'comment'".  The last one is briefly covered
by the tutorial.

Re: Switching heads and head vs branch after CVS import

[Linus Torvalds]

On Mon, 15 Aug 2005, Martin Langhoff wrote:
>
> After having done a cvs import of Moodle using git-cvsimport-script
> all the cvs branches show up as heads. How do I switch heads within a
> checkout? cogito doesn't seem to be able to, and I'm unsure on how to
> do it with git.

Just do

	git checkout branch-name

to switch between them.

One thing that "git cvsimport" does not know to do is to show when a
branch was merged back into the HEAD. That would be a very interesting
thing to see, but I don't think there's any way to get that information
out of CVS (so you'd have to basically make an educated guess by looking
at the changes).

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

> And I am confused about the difference between heads and branches.

Confusion of naming.

branches and heads are the same thing in git. However, largely due to 
historical reasons, I encouraged "one tree pre branch", and then you had 
"external branches" which were totally separate repositories.

Now, we're stuck with both the "internal branches" (heads) and "external
branches" (other repositories) _both_ being confusingly called "branch", 
and then to make it more confusing, sometimes you'll see people say 
"head" to make clear that it's a branch internal to one repo.

> In any case, should the cvsimport turn cvs branches into git branches
> instead of heads? Is there are way to turn a head into a proper
> branch?

They are "proper branches", and sorry about the confusion. A head is a 
branch.

			Linus

Re: Switching heads and head vs branch after CVS import

[Martin Langhoff]

> Just do
> 
>         git checkout branch-name
> 
> to switch between them.

thanks! I was doing cg-branch-chg branch-name and it wasn't working.

> 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: that was a feature branch where people worked on for a
while and merged back. I haven't had time to explore it more, but it
looks promising.

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

> > And I am confused about the difference between heads and branches.
> 
> Confusion of naming.
> 
> 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?

> They are "proper branches", and sorry about the confusion. 

Don't worry! Means I'll have to wake up and pay attention from now on...

thanks,


martin

Re: Switching heads and head vs branch after CVS import

[Linus Torvalds]

On Mon, 15 Aug 2005, Martin Langhoff wrote:
> 
> > 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..

> > 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

Re: Switching heads and head vs branch after CVS import

[Sven Verdoolaege]

On Sun, Aug 14, 2005 at 07:49:26PM -0700, Linus Torvalds wrote:
> On Mon, 15 Aug 2005, Martin Langhoff wrote:
> > 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..
> 

I don't have any strong opinion on that, but I do think
that by default a cvsimport should give you the same
file contents that a "cvs import" would.
Martin's patch seems to be going in the right direction.

skimo

Re: Switching heads and head vs branch after CVS import

[Matthias Urlichs]

Hi, Linus Torvalds wrote:

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

Umm, actually, no, cvsimport doesn't do merges. Dunno where Martin got his
from, but it wasn't me. ;-)

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

I have intentionally kept keyword expansion on when I wrote the code,
because matching up the files from CVS with files gathered from tarballs,
Debian repositories, and what-not, becomes a whole lot easier that way.

For me, that's a major use case, esp. with CVS getting confused about its
tags (as people haphazardly copy whole subtrees from one CVS repository
into a different one).

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
I hope you will find the courage to keep on living
despite the existence of this feature.

	-- Richard Stallman

Re: Switching heads and head vs branch after CVS import

[Martin Langhoff]

On 8/15/05, Matthias Urlichs <smurf@smurf.noris.de> wrote:
> Umm, actually, no, cvsimport doesn't do merges. Dunno where Martin got his
> from, but it wasn't me. ;-)

Just wishful thinking, and a viewing things on a remote box over a
slow x11-over-ssh connection. When I think about it, it doesn't seem
possible either, so I better stop dreaming.

> > Sven, Matthias, opinions? I've never used CVS keyword expansion, and
> > always felt it was pointless, but hey..
> 
> I have intentionally kept keyword expansion on when I wrote the code,
> because matching up the files from CVS with files gathered from tarballs,
> Debian repositories, and what-not, becomes a whole lot easier that way.

Makes sense in that context. On the other hand, if you are you're
migrating a project from cvs to git, getting rid of the noise is good.

And the resulting git repo will actually let you do trivial merges of
old commits after you've switched -- otherwise every file-level merge
will conflict, as it does in cvs when you don't use -kk.

cheers,


martin

Re: Switching heads and head vs branch after CVS import

[Wolfgang Denk]

In message <Pine.LNX.4.58.0508141737270.3553@g5.osdl.org> you wrote:
> 
> One thing that "git cvsimport" does not know to do is to show when a
> branch was merged back into the HEAD. That would be a very interesting
> thing to see, but I don't think there's any way to get that information
> out of CVS (so you'd have to basically make an educated guess by looking
> at the changes).
> 
> So in a cvsimport, you'll never see a merge back to the head, even if one 
> technically took place. 

I asked this question before without receiving any reply:

Assume I know exactly where the merge back happenend - is  there  any
way to tell git about it, so I don't see all these dangling heads any
more?


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"The number  of  Unix  installations  has  grown  to  10,  with  more
expected."    - The Unix Programmer's Manual, 2nd Edition, June, 1972

Re: Switching heads and head vs branch after CVS import

[Matthias Urlichs]

Hi, Wolfgang Denk wrote:

> Assume I know exactly where the merge back happenend - is  there  any
> way to tell git about it, so I don't see all these dangling heads any
> more?

Two ways:
- you can enhance cvs2git to do it at the appropriate time. Good luck.
- after the fact, and after finding the relevant heads manually, you can
  use .git/info/grafts to fake it.

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
As crazy as hauling timber into the woods.
		-- Quintus Horatius Flaccus (Horace)

Re: Switching heads and head vs branch after CVS import

[Sven Verdoolaege]

On Mon, Aug 15, 2005 at 12:38:53PM +0200, Matthias Urlichs wrote:
> Hi, Wolfgang Denk wrote:
> 
> > Assume I know exactly where the merge back happenend - is  there  any
> > way to tell git about it, so I don't see all these dangling heads any
> > more?
> 
> Two ways:
> - you can enhance cvs2git to do it at the appropriate time. Good luck.
> - after the fact, and after finding the relevant heads manually, you can
>   use .git/info/grafts to fake it.
- Create the merge commit manually and then rebase the rest of the branch
  on top of that commit.
  Maybe you could enhance git-rebase to rebase on top of more than
  one head, performing the merge for you.

skimo

Re: Switching heads and head vs branch after CVS import

[Linus Torvalds]

On Mon, 15 Aug 2005, Wolfgang Denk wrote:
> 
> I asked this question before without receiving any reply:
> 
> Assume I know exactly where the merge back happenend - is  there  any
> way to tell git about it, so I don't see all these dangling heads any
> more?

You'd have to teach cvsimport about it. Basically, in cvsimport, you have

		...
                my @par = ();
                @par = ("-p",$parent) if $parent;

which sets the parent. Right now the parent is _always_ just the previous 
head of the branch we're committing to (I'm no good with perl, but I think 
Martin was wrong - there's no code to handle the case of a merge: once we 
branch off, "git cvsimport" will not currently ever create a 
merge-commit).

But if you have some heuristic for figuring out that it's a merge, and
know the other branch is, you could add more parents by just adding
another ("-p", $merge_parent) to the parameters to git-commit-tree.

The problem is literally how to figure out that it's a merge. You can 
probably make a guess from the commit message together with possibly 
looking at the diff. 

The good news is that if you guess wrong, and you claim a merge where none
exists, it doesn't really do any real damage. It might make th history
look strange, and it might make subsequent git merges harder if the branch
is actually still live and you want to continue development within git.
But even that is debatable (if the eventual git merge isn't trivial,
you're likely to have to merge by hand anyway - and it's going to be as
hard as a CVS merge would have been, because quite frankly, you've got the
same information CVS had..).

		Linus

Re: Switching heads and head vs branch after CVS import

[Martin Langhoff]

On 8/16/05, Linus Torvalds <torvalds@osdl.org> wrote:
> The good news is that if you guess wrong, and you claim a merge where none
> exists, it doesn't really do any real damage. 

I had figured out what part of the code I wanted to hack, but was
concerned that marking things that were merges in cvs-speak but not in
git-speak would leave me with broken import and problems going
forward.

If I find the time, I'll add some sort of pattern-match parameters to
be tried against the commitmsg to extract likely head/branch names
where we are merging from. My problem right now is that the only cvs
repo with interesting branches and merges I have is huge, and takes an
hour to import. That puts a damper on things, unfortunately.

cheers,


martin

Re: Switching heads and head vs branch after CVS import

[Wolfgang Denk]

In message <46a038f90508151309269ffc04@mail.gmail.com> you wrote:
>
> If I find the time, I'll add some sort of pattern-match parameters to
> be tried against the commitmsg to extract likely head/branch names
> where we are merging from. My problem right now is that the only cvs
> repo with interesting branches and merges I have is huge, and takes an
> hour to import. That puts a damper on things, unfortunately.

In a first step, and to try things out, it might be sufficient if one
could feed in this information manually, like by providing a list  of
PatchSet ID's which are known to be merges ?

At least in my case where the number of branches and merges is  small
this would be completely satisfactory.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
What is mind?  No matter.  What is matter?  Never mind.
                                      -- Thomas Hewitt Key, 1799-1875

Re: Switching heads and head vs branch after CVS import

[Linus Torvalds]

On Tue, 16 Aug 2005, Martin Langhoff wrote:
> 
> If I find the time, I'll add some sort of pattern-match parameters to
> be tried against the commitmsg to extract likely head/branch names
> where we are merging from. My problem right now is that the only cvs
> repo with interesting branches and merges I have is huge, and takes an
> hour to import. That puts a damper on things, unfortunately.

I was seriously considering just breaking the "remote cvs" support
entirely (you can always just use cvsup or something to download it to
make it local), and just taking the RCS parsing code from GNU rcs/cvs and
making a C language CVS importer. That would speed things up by an order
of magnitude or more, as far as I can tell.

			Linus

Re: Switching heads and head vs branch after CVS import

[Johannes Schindelin]

Hi,

On Mon, 15 Aug 2005, Linus Torvalds wrote:

> I was seriously considering just breaking the "remote cvs" support
> entirely (you can always just use cvsup or something to download it to
> make it local), and just taking the RCS parsing code from GNU rcs/cvs and
> making a C language CVS importer. That would speed things up by an order
> of magnitude or more, as far as I can tell.

That may be true for many "cvs import" tasks, but not _at all_ for "cvs 
update" tasks. I, for one, keep track of _lots_ of CVS projects via 
git-cvsimport. I would hate it if I could no longer do that.

Ciao,
Dscho