Imports without Tariffs

[mfwitten@MIT.EDU]

[INTRO]

	Hello,
	
	I have come across a problem that could be easily addressed
	in order to improve interoperability between CVS and git.
	
	
	I'm new to using git (and a novice with SCMs in general),
	and I really enjoy the way that git allows me to think.
	
	Unfortunately, I am forced to deal with CVS (for one of
	my classes), but I have been courageously trying to use
	git behind the scenes, as I can already tell CVS is a
	nightmare.
	

[SCENARIO]
	
	I would like to do the following sequence:
		
		(1) Checkout a CVS repository as a git working tree.
				
			=> git cvsimport -A /path -a -k -v -r cvs -C work module
			
		(2) Edit the git working tree and make commits there.
				
			=> cd work
			=> vim ... # emacs can go live with CVS ;-P
			=> git commit -a -m ...
				
		(3) Export my git working tree commits back to CVS.
			
			=> cd ..; cvs co modules; cd modules
			
			=> for each pertinent git commit hash, HASH:
				GIT_DIR=../work/.git git-cvsexportcommit -vc HASH
				
		(4) Update my git working tree from CVS (at some later time).
			
			=> cd ../work
			=> git cvsimport -a -k -v -r cvs -C . module
		
[PROBLEM]
	
	git-cvsimport creates new hash IDs for the same ol' commits.
	
	
	Running git-cvsimport does indeed do an incremental update of
	the 'cvs' remote in the 'work' git repository.
	
	However, the updates are brought in as brand new git commits
	with the CVS dates in the log (though changed to UTC +0000!!).
	
	Therefore, when the updated 'cvs' remote branches are merged into
	my local branches, git treats the commits I made with cvsexportcommit
	as separate history; thus, history is duplicated and merge commits
	appear where they shouldn't.

[PARTIAL SOLUTION]
	
	The trick is to populate the 'cvs' remote branches with commits that
	have the right hash IDs.
	
	I thought I could do this by hand.
	
	I updated the cvsexportcommit/cvsimport sequence by pushing
	my local branches into their respective 'cvs' remote branches,
	before running that last cvsimport:
		
		=> for each pertinent git commit hash, HASH:
			GIT_DIR=../work/.git git-cvsexportcommit -vc HASH
		
		=>=>=> git push . refs/heads/master:refs/remotes/cvs/master
		
		=> git cvsimport -a -k -v -r cvs -C . module
	
	Of course, git-cvsimport still adds the commits to the 'cvs'
	remote branches, duplicating (log) histories.
	
	The difference is that the 'cvs' remote branches become descendants
	of the local branches, causing a fast-forward merge with the local
	branches; this removes the split histories, but still duplicates
	information in an even dumber way, as changes are undone and then
	redone.

[SOLUTION]
	
	The trick is to make both git-cvsimport and the user smarter
		---- A TALL ORDER!
	
	
	To make things simple, I think all of the necessary machinery
	should be put into git-cvsimport.
	
	The user should first git-cvsexportcommit as necessary.
	
	Then the user should tell git-cvsimport to push from the pertinent git
	branches into the pertinent cvsimport branch. To make things even  
simpler,
	I think that git-cvsimport should make the -r option mandatory; then
	git-cvsimport would simply do the pushing as I did:
		
		git push . refs/heads/<branch1>:refs/remotes/<remote>/<branch2>
	
	Then git-cvsimport would mark for each pushed-into branch the timestamp
	for when the push occurred. These marks could be put in some special  
file,
	say .git/CVSIMPORT.
	
	The next time git-cvsimport is used as normal, it can consult this  
file for
	timestamps, rather than relying on git log timestamps, to determine  
if creat-
	ing a new commit is necessary.

[CONCLUSION]
	
	I feel that not much is being put into converting between git and  
CVS, which
	is unfortunate, because a lot of stuff is in CVS out there; here at  
MIT,
	*all* CS students have to use CVS for at least one semester of  
grueling programming
	labs.
	
	If conversion between git and CVS is hard, many students will just  
learn
	what seems easiest---CVS---and they'll decide to use CVS for their  
projects
	later on (I've already seen this happen); that's not a future I want  
to have!
	
	Sincerely,
	Michael Witten
	
[OTHER PROBLEMS]
	
	(1) git-cvsimport creates log entries with UTC times; maybe that's  
correct.
	(2) git-cvsimport's -A argument must be a full path.
	(3) git-cvsexportcommit should automatically handle contiguous commits.
	(4) git-cvsimport is written in the most unmaintainable perl ever!