Re: Switching heads and head vs branch after CVS import

In message [off-list ref] 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

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)

On Mon, Aug 15, 2005 at 12:38:53PM +0200, Matthias Urlichs wrote:

Hi, Wolfgang Denk wrote:

quoted

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

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

On 8/16/05, Linus Torvalds [off-list ref] 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

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

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