On Sun, Aug 14, 2005 at 07:49:26PM -0700, Linus Torvalds wrote:
On Mon, 15 Aug 2005, Martin Langhoff wrote:
Except for the keyword expansion. surely there's a way to tell cvsps
to not do it. Why would we ever want it?
Ahh. I don't think we should blame cvsps, I think cvsimport should use
In message [EMAIL PROTECTED] 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
Hi, Linus Torvalds wrote:
There may be some surprises in here! gitk --all shows at least one
branch opening and merging back into origin, and it has figured it out
correctly
Oh, wow. The new cvsimport is obviously being a hell of a lot smarter
than my original one was. Goodie.
Umm,
On 8/15/05, Matthias Urlichs [EMAIL PROTECTED] wrote:
Umm, actually, no, cvsimport doesn't do merges. Dunno where Martin got his
from, but it wasn't me. ;-)
Just wishful thinking, and a viewing things on a remote box over a
slow x11-over-ssh connection. When I think about it, it doesn't seem
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.
On 8/16/05, Linus Torvalds [EMAIL PROTECTED] 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
In message [EMAIL PROTECTED] you 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
Just a work-in-progress sample. I've done a pretty successful import
of a small tree with this patch. It is showing the merges /almost/ in
the right place. The almost is due to bad cvs practices, and not this
code.
Definitely doable, though it'll never be nice -- CVS doesn't have
the right data
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.
After having done a cvs import of Moodle using git-cvsimport-script
all the cvs branches show up as heads. How do I switch heads within a
checkout? cogito doesn't seem to be able to, and I'm unsure on how to
do it with git.
And I am confused about the difference between heads and branches. Git
Martin Langhoff [EMAIL PROTECTED] writes:
After having done a cvs import of Moodle using git-cvsimport-script
all the cvs branches show up as heads. How do I switch heads within a
checkout? cogito doesn't seem to be able to, and I'm unsure on how to
do it with git.
The documentation may be
Just do
git checkout branch-name
to switch between them.
thanks! I was doing cg-branch-chg branch-name and it wasn't working.
So in a cvsimport, you'll never see a merge back to the head, even if one
technically took place.
There may be some surprises in here! gitk --all shows
12 matches
Mail list logo
