Re: Switching heads and head vs branch after CVS import
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 the -ko flag to disable keyword expansion or whatever the magic flag is. Sven, Matthias, opinions? I've never used CVS keyword expansion, and always felt it was pointless, but hey.. I don't have any strong opinion on that, but I do think that by default a cvsimport should give you the same file contents that a cvs import would. Martin's patch seems to be going in the right direction. skimo - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Switching heads and head vs branch after CVS import
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 make an educated guess by looking at the changes). So in a cvsimport, you'll never see a merge back to the head, even if one technically took place. 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? Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] The number of Unix installations has grown to 10, with more expected.- The Unix Programmer's Manual, 2nd Edition, June, 1972 - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Switching heads and head vs branch after CVS import
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, actually, no, cvsimport doesn't do merges. Dunno where Martin got his
from, but it wasn't me. ;-)
Sven, Matthias, opinions? I've never used CVS keyword expansion, and
always felt it was pointless, but hey..
I have intentionally kept keyword expansion on when I wrote the code,
because matching up the files from CVS with files gathered from tarballs,
Debian repositories, and what-not, becomes a whole lot easier that way.
For me, that's a major use case, esp. with CVS getting confused about its
tags (as people haphazardly copy whole subtrees from one CVS repository
into a different one).
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
I hope you will find the courage to keep on living
despite the existence of this feature.
-- Richard Stallman
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Switching heads and head vs branch after CVS import
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 possible either, so I better stop dreaming. Sven, Matthias, opinions? I've never used CVS keyword expansion, and always felt it was pointless, but hey.. I have intentionally kept keyword expansion on when I wrote the code, because matching up the files from CVS with files gathered from tarballs, Debian repositories, and what-not, becomes a whole lot easier that way. Makes sense in that context. On the other hand, if you are you're migrating a project from cvs to git, getting rid of the noise is good. And the resulting git repo will actually let you do trivial merges of old commits after you've switched -- otherwise every file-level merge will conflict, as it does in cvs when you don't use -kk. cheers, martin - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Switching heads and head vs branch after CVS import
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. Basically, in cvsimport, you have ... my @par = (); @par = (-p,$parent) if $parent; which sets the parent. Right now the parent is _always_ just the previous head of the branch we're committing to (I'm no good with perl, but I think Martin was wrong - there's no code to handle the case of a merge: once we branch off, git cvsimport will not currently ever create a merge-commit). But if you have some heuristic for figuring out that it's a merge, and know the other branch is, you could add more parents by just adding another (-p, $merge_parent) to the parameters to git-commit-tree. The problem is literally how to figure out that it's a merge. You can probably make a guess from the commit message together with possibly looking at the diff. 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. It might make th history look strange, and it might make subsequent git merges harder if the branch is actually still live and you want to continue development within git. But even that is debatable (if the eventual git merge isn't trivial, you're likely to have to merge by hand anyway - and it's going to be as hard as a CVS merge would have been, because quite frankly, you've got the same information CVS had..). Linus - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Switching heads and head vs branch after CVS import
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 cvs-speak but not in git-speak would leave me with broken import and problems going forward. 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 have is huge, and takes an hour to import. That puts a damper on things, unfortunately. cheers, martin - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Switching heads and head vs branch after CVS import
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 have is huge, and takes an hour to import. That puts a damper on things, unfortunately. In a first step, and to try things out, it might be sufficient if one could feed in this information manually, like by providing a list of PatchSet ID's which are known to be merges ? At least in my case where the number of branches and merges is small this would be completely satisfactory. Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] What is mind? No matter. What is matter? Never mind. -- Thomas Hewitt Key, 1799-1875 - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Mergeback patch - (was: Switching heads and head vs branch after CVS import)
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 for this. I want to make the regexes configurable, and
have a more decent way of extracting the parent sha. B
diff --git a/git-cvsimport-script b/git-cvsimport-script
--- a/git-cvsimport-script
+++ b/git-cvsimport-script
@@ -542,6 +542,24 @@ my $commit = sub {
my @par = ();
@par = (-p,$parent) if $parent;
+
+ # detect additional branches
+ my @rx = ( qr/Merged from (\w+)/i , qr/merge of (\w+)/i );
+ foreach my $rx (@rx) {
+ if ($logmsg =~ $rx) {
+ my $parent = $1;
+ if ($parent eq 'HEAD') { $parent = 'origin'};
+ if ( -e $git_dir/refs/heads/$parent) {
+ warn grabbing $parent;
+ $parent = `cat $git_dir/refs/heads/$parent`;
+ chomp $parent;
+ warn grabbed $parent;
+ push @par, '-p', $parent;
+ }
+ }
+ }
+ # %seen_branches
+
exec(env,
GIT_AUTHOR_NAME=$author,
GIT_AUTHOR_EMAIL=$author,
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Switching heads and head vs branch after CVS import
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. That would speed things up by an order of magnitude or more, as far as I can tell. That may be true for many cvs import tasks, but not _at all_ for cvs update tasks. I, for one, keep track of _lots_ of CVS projects via git-cvsimport. I would hate it if I could no longer do that. Ciao, Dscho - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Switching heads and head vs branch after CVS import
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 and cogito seem prepared to merge across the heads (using cg-update for instance, when pointed to a different head merged it in, rather than switched to it), that would match a workflow where a group of people maintain very closely related heads and merge constantly across. Branches don't seem to have the same expectation or support in the toolset. Why? What makes a branch different from a head, apart from the fact that they would be expected to drift further apart? In any case, should the cvsimport turn cvs branches into git branches instead of heads? Is there are way to turn a head into a proper branch? cheers, martin - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Switching heads and head vs branch after CVS import
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 quite sketchy on this front. I do not speak for Pasky, so Cogito may treat them a little differently, but at the core GIT level, you can treat branches and heads synonymously. What you have recorded in .git/refs/heads/frotz file is the SHA1 object name of the commit that is at the top of frotz branch. When your .git/HEAD symlink points at refs/heads/nitfol, your working tree is said to be on nitfol branch. You switch branches by using git checkout. You can create a new branch using git checkout -b newbranch commit-id. You examine which branch you are on by readlink .git/HEAD. As you already found out, you can merge branches with git resolve master other-branch 'comment'. The last one is briefly covered by the tutorial. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Switching heads and head vs branch after CVS import
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 at least one branch opening and merging back into origin, and it has figured it out correctly: that was a feature branch where people worked on for a while and merged back. I haven't had time to explore it more, but it looks promising. Except for the keyword expansion. surely there's a way to tell cvsps to not do it. Why would we ever want it? And I am confused about the difference between heads and branches. Confusion of naming. branches and heads are the same thing in git. right. There are two separate directories in .git for them, so I was misled by that. Should I assume git is safe from name clashes or is it up to porcelain to deal with such minutiae? They are proper branches, and sorry about the confusion. Don't worry! Means I'll have to wake up and pay attention from now on... thanks, martin - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
