On 10. okt.. 2007, at 04.34, Michael Haggerty wrote:
[...]
Thanks for the response! I should have explained that my goal is to
convince my coworkers that git is worth the effort to learn, and IMO,
making imported git repositories look as "clean" as possible to
someone familiar with the CVS repository is an important part of
that. My suggestions and complaints should be seen in that light :)
* Tags each get a branch with a single commit, with the actual tag
pointing to that commit. This makes it harder than necessary to
figure
out what the history looks like; gitk's default view won't show any
tags, for example, since it only shows the master branch and not the
single-commit tag branches.
I just fixed this in cvs2svn trunk r4213. Now it reuses a single
branch
called 'refs/heads/TAG.FIXUP' whenever it needs to make a tag fixup
branch, and it resets that branch when done. (Resetting the tag fixup
branch changes it to 0000000000000000000000000000000000000000 but
doesn't really delete it; I don't know the ramifications of that but
at
least it doesn't appear in gitk output any more.)
Great! I'll try this out at the first opportunity.
The main problem I have with the current branched-tag behaviour is
that nothing exists on the branch to show that a tag is branched off,
so no tags are shown at all when running gitk on a single branch. A
git newbie who is familiar with the CVS repository will probably just
assume that tags haven't been imported, which is unfortunate.
Tagging the branch point is an obvious solution to that problem, but I
wonder if branching for tag fixups could be made optional. Instead of
representing a tag with differences to the commit it's closest to like
this:
o--*--o--...
\--t
(where "*" represents the closest commit on the branch, and "t"
represents the fixup commit), might the following be possible and/or
desirable?
o--*--t--r--o--...
"r" being a commit that reverts the changes in "t".
It might just be me, but I think of a tag as being "on" a branch even
when it has been messed with (sliding, omitting files, etc), and a
linear history preserves that illusion.
* Branches all get a useless commit at their branch point. All
branches
from the main branch appear to be merged from the vendor branch
(ie, the
useless commit has the vendor branch as an extra parent), which might
make sense to someone who knows what the vendor branch is for, but
makes
no sense to me. This combined with the previous point makes "gitk
--all" look needlessly spaghetti-like if you have a slightly
complicated
CVS history.
I assume that the "useless commit" that you are referring to is the
one
with log message "This commit was manufactured by cvs2svn to create
branch 'BRANCH'." Is that correct?
Yes. And I'm regretting my choice of words already. "Unexpected
commit" would have been better.
I'm not a git expert, so I don't know whether these commits are in
fact
useless. But let me explain the reason I put them in and you can tell
me whether it is nonsense.
[...]
I know barely enough about git (or CVS, for that matter) to be
dangerous, but your explanation makes sense to me.
I imagine that *if* a branch is created with a single parent branch,
and
*if* each and every file from the parent branch is added to the new
branch, then it is possible that the "useless commit" could be
omitted.
But this decision would require information that cvs2svn doesn't
currently have at that stage of the conversion, and keeping the
necessary records would be quite expensive.
Right; that is how I think of a branch, even if CVS doesn't. To me,
the extra commit is useless because it should be identical to the
branch point commit on the parent branch. I don't think having an
extra commit there is a huge problem, though.
[...]
Regarding the superfluous vendorbranch parent: vendor branches are an
obscure CVS feature for tracking upstream sources. The file
contents on
the vendorbranch are typically exactly the same as that on trunk,
and if
a branch is created while the vendorbranch is active, CVS doesn't
record
whether the branch's parent was trunk or the vendorbranch. Haven't
yet
built the heuristics into cvs2svn to make this decision more
intelligently, so sometimes "vendorbranch" is listed as a branch
parent
when it could be omitted.
I don't think I've ever seen the vendor branch used for anything but
the initial import (creation) of a repository, and then only because
it is a required parameter to "cvs import". Is there any chance you
could add an option to ignore the vendor branch?
Thanks for the feedback!
Thanks for making cvs2svn the best CVS-to-git conversion tool :) Now
if it would only support incremental importing...
Eyvind Bernhardsen
-
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
