[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!
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
