Martin Langhoff [off-list ref] writes:
[PATCH] Add -k kill keyword expansion option to git-cvsimport
Early versions of git-cvsimport defaulted to using preexisting keyword
expansion settings. This change preserves compatibility with existing cvs
imports and allows new repository migrations to kill keyword expansion.
Should improve our chances of detecting merges and reduce imported
repository size.
The discussion between you and Linus since you brought this up
has kept me wondering if -ko is the only thing people may want
to do, or sometimes -kk or even -kb or -kv make sense for some
others, in which case instead of a -k option that does not allow
anything but -ko, making it take an optional single letter
o/k/b/v might might more sense. A single -k defaulting to -ko
is fine by me if you did so, because I think that is the most
useful and usual mode of operation while converting to GIT
repository.
Thoughts?
On 8/15/05, Junio C Hamano [off-list ref] wrote:
The discussion between you and Linus since you brought this up
has kept me wondering if -ko is the only thing people may want
to do, or sometimes -kk or even -kb or -kv make sense for some
The git-cvsimport script requests the full file at a given revision
straight from the cvs server daemon it has instantiated. So I suspect
we are mixing up cvs client flags with protocol flags. Hmm, reading up
on it ( http://www.elegosoft.com/cvs/cvsclient.html#SEC9 ) the flags
are carried through, and it sounds like it's pretty broken.
Still, it clearly leaves handling of newlines to the client. The
difference between -kb and -ko (we are using -ko ATM) is the newline
handling if you are using standard cvs clients. With git-cvsimport, we
are doing the unix thing, which happens to be right thing to do.
Perhaps repos created with early versions of CVSNT are broken in this
regard, but tough.
I think -kv is just the wrong thing to do if you are migrating to git.
Anyway, this script has so far followed cvs's own default... which is
-kv, and I am generally unwilling to break backwards compatibility.
Though we could make it default to 'on' and provide '-K' for those
masochistic enough to want it.
People with repos where cvswrappers was set to mark files as -kb or
-ko are safe from all this pain and tears.
cheers,
martin
Martin Langhoff [off-list ref] writes:
quoted
..., in which case instead of a -k option that does not allow
anything but -ko, making it take an optional single letter
o/k/b/v might might more sense. A single -k defaulting to -ko
is fine by me if you did so, because I think that is the most
useful and usual mode of operation while converting to GIT
repository.
Anyway, this script has so far followed cvs's own default... which is
-kv, and I am generally unwilling to break backwards compatibility.
I realize what I wrote was prone to be misunderstood. What I
meant about "single -k defaulting to -ko" was this:
cvsimport without -k<any> => cvs default
cvsimport -k == cvsimport -ko => use cvs -ko
cvsimoprt -kv => use cvs -kv