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
Re: Switching heads and head vs branch after CVS import
On Tue, 16 Aug 2005, Martin Langhoff 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. 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. 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
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
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
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 Mon, Aug 15, 2005 at 12:38:53PM +0200, Matthias Urlichs wrote: > Hi, Wolfgang Denk wrote: > > > 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? > > Two ways: > - you can enhance cvs2git to do it at the appropriate time. Good luck. > - after the fact, and after finding the relevant heads manually, you can > use .git/info/grafts to fake it. - Create the merge commit manually and then rebase the rest of the branch on top of that commit. Maybe you could enhance git-rebase to rebase on top of more than one head, performing the merge for you. 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
Hi, Wolfgang Denk wrote:
> 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?
Two ways:
- you can enhance cvs2git to do it at the appropriate time. Good luck.
- after the fact, and after finding the relevant heads manually, you can
use .git/info/grafts to fake it.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
As crazy as hauling timber into the woods.
-- Quintus Horatius Flaccus (Horace)
-
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
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
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
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
On Mon, 15 Aug 2005, Martin Langhoff wrote:
>
> > 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
Oh, wow. The new cvsimport is obviously being a hell of a lot smarter than
my original one was. Goodie.
> 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..
> > 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?
Well, you actually are _expected_ to get clashes.
What happens normally (at least for core git) is that the ".git/branches"
directory contains external sources for the branches (for example, a "git
clone" will fill in the "origin" source, while I often have a
".git/branches/parent" in my tree because). That is just a pointer to
where the external branch exists.
Then, when you do something like
git fetch parent
it will look up the source of "parent" by looking in the
".git/branches/parent" file, and update the ".git/refs/heads/parent"
branch appropriately from that external branch.
So in this example the parent "head" ("local branch") points to the actual
_commit_ we have, while the ".git/branches/parent thing points to what
_external_ branch it came from.
But yes, you _can_ mess this up if you want to. If you have the same
"external branch" name that you use for an "internal branch", you deserve
all the confusion you get ;)
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
> 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
Re: Switching heads and head vs branch after CVS import
On Mon, 15 Aug 2005, Martin Langhoff wrote: > > 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. Just do git checkout branch-name to switch between them. 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. > And I am confused about the difference between heads and branches. Confusion of naming. branches and heads are the same thing in git. However, largely due to historical reasons, I encouraged "one tree pre branch", and then you had "external branches" which were totally separate repositories. Now, we're stuck with both the "internal branches" (heads) and "external branches" (other repositories) _both_ being confusingly called "branch", and then to make it more confusing, sometimes you'll see people say "head" to make clear that it's a branch internal to one repo. > 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? They are "proper branches", and sorry about the confusion. A head is a branch. 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
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
