{"thread":{"id":"8948","subject":"How to Import a bitkeeper repo into git","startedAt":"2007-07-09T16:57:09Z","lastAt":"2007-11-06T10:51:49Z","messageCount":39,"participants":["free cycle","VMiklos","Linus Torvalds","Pete/Piet Delaney","Shawn O. Pearce","David Brown","Marco Costalba","Andreas Ericsson","Jan Hudec","Robin Rosenberg","Johannes Schindelin","Jeff King","Jan Wielemaker"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"46878","messageId":"598689.78740.qm@web56015.mail.re3.yahoo.com","threadId":"8948","inReplyTo":null,"subject":"How to Import a bitkeeper repo into git","fromName":"free cycle","fromEmail":"freecycler23@yahoo.com","sentAt":"2007-07-09T16:57:09Z","receivedAt":"2007-07-09T16:57:09Z","isPatch":false,"sender":{"key":"freecycler23@yahoo.com","avatar":null},"body":"Hi,\n\nI'm looking for the best path to import a bk repo into git.\n\n\nI was not able to find the download site for the tailor repo-conversion application.\nIs it still supported and maintained?\n\nI think bk can export to CVS and then git can import from CVS.\nIs this the best way?\n\nThanks in advance,\n\nScott\n"},{"id":"46879","messageId":"20070709173720.GS29994@genesis.frugalware.org","threadId":"8948","inReplyTo":"598689.78740.qm@web56015.mail.re3.yahoo.com","subject":"Re: How to Import a bitkeeper repo into git","fromName":"VMiklos","fromEmail":"vmiklos@frugalware.org","sentAt":"2007-07-09T17:37:20Z","receivedAt":"2007-07-09T17:37:20Z","isPatch":false,"sender":{"key":"vmiklos@frugalware.org","avatar":"https://gravatar.com/avatar/401c1cbbb3a5d13e650c691a2c71d6fd0b80df1a01bc74d9f1972675dd58f2bd?d=mp&s=160"},"body":"Na Mon, Jul 09, 2007 at 09:57:09AM -0700, free cycle pisal(a):\n> I was not able to find the download site for the tailor repo-conversion application.\n> Is it still supported and maintained?\n\nhttp://progetti.arstecnica.it/tailor/\n\nyes, it's maintained but it does not support bitkeeper\n\n> I think bk can export to CVS and then git can import from CVS.\n\ni think so\n\n- VMiklos\n"},{"id":"46880","messageId":"alpine.LFD.0.999.0707091049080.31544@woody.linux-foundation.org","threadId":"8948","inReplyTo":"20070709173720.GS29994@genesis.frugalware.org","subject":"Re: How to Import a bitkeeper repo into git","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-07-09T17:51:22Z","receivedAt":"2007-07-09T17:51:22Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 9 Jul 2007, VMiklos wrote:\n> \n> > I think bk can export to CVS and then git can import from CVS.\n> \n> i think so\n\nThat's how I did my kernel history, and cvsps has a special \"BK mode\", \nwhich knows to trust the CVS timestamps more when importing from a BK CVS \narchive (since the timestamps will then be exact).\n\nThat said, the quality of the result isn't stellar. The CVS export will \nobviously linearize the BK information, so you do lose things. So there's \nactually a better kernel BK->git archive around which doesn't do that, but \nthat was done apparently from a custom database, so it's not reproducible.\n\n\t\t\tLinus\n"},{"id":"55923","messageId":"4713FA4A.5090501@bluelane.com","threadId":"8948","inReplyTo":"alpine.LFD.0.999.0707091049080.31544@woody.linux-foundation.org","subject":"Re: How to Import a bitkeeper repo into git","fromName":"Pete/Piet Delaney","fromEmail":"pete@bluelane.com","sentAt":"2007-10-15T23:39:54Z","receivedAt":"2007-10-15T23:39:54Z","isPatch":false,"sender":{"key":"pete@bluelane.com","avatar":null},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nLinus Torvalds wrote:\n> \n> On Mon, 9 Jul 2007, VMiklos wrote:\n>>> I think bk can export to CVS and then git can import from CVS.\n>> i think so\n> \n> That's how I did my kernel history, and cvsps has a special \"BK mode\", \n> which knows to trust the CVS timestamps more when importing from a BK CVS \n> archive (since the timestamps will then be exact).\n> \n> That said, the quality of the result isn't stellar. The CVS export will \n> obviously linearize the BK information, so you do lose things. So there's \n> actually a better kernel BK->git archive around which doesn't do that, but \n> that was done apparently from a custom database, so it's not reproducible.\n> \n> \t\t\tLinus\n> -\n\nWe have a CVS repository that we want to import into bitkeeper. I tried\nthe bk import option, including with a branch bug fix, but it's\nstill having problems.\n\nI imported the CVS repository to git and it worked great. Since all\nof our other repository are in bitkeeper the management would like to\nstick with CVS. With git apparently still being weak in the area of\nsupporting difftool on different version that seems somewhat reasonable\nfor the time being.\n\nThe folks at bitmover are converting you kernels to bk and it's\nmaintaining the branch history and I'd like to do the same. So far\nthey haven't help us convert the git repository to bk. Do you happen\nto know of someone else that might now how to do this in case the\nfolks at bitmover can't provide the scripts to convert this git\nrepository to bk?\n\nI was curious why the difftool paradigm hasn't been integrated into\nthe git GUIs. It's very comfortable and I think it has been used in\nother source code control systems, for example Sun Microsystems.\n\n- -piet\n\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.7 (GNU/Linux)\nComment: Using GnuPG with Mozilla - http://enigmail.mozdev.org\n\niD8DBQFHE/pKJICwm/rv3hoRAs/QAJoDL0HQDaOAI1x6UakEiVvti9tI2wCfUpGI\nbfyKH+ykUK7p2AL9CSE+XXc=\n=0gnp\n-----END PGP SIGNATURE-----\n"},{"id":"55925","messageId":"20071016000359.GT27899@spearce.org","threadId":"8948","inReplyTo":"4713FA4A.5090501@bluelane.com","subject":"Re: How to Import a bitkeeper repo into git","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-10-16T00:03:59Z","receivedAt":"2007-10-16T00:03:59Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Pete/Piet Delaney wrote:\n> I imported the CVS repository to git and it worked great. Since all\n> of our other repository are in bitkeeper the management would like to\n> stick with CVS. With git apparently still being weak in the area of\n> supporting difftool on different version that seems somewhat reasonable\n> for the time being.\n...\n> I was curious why the difftool paradigm hasn't been integrated into\n> the git GUIs. It's very comfortable and I think it has been used in\n> other source code control systems, for example Sun Microsystems.\n\nWhat's difftool? What's so great about it?\n\nForgive my ignorance but it has been many years since I last used\nBitKeeper and even when I did use it I didn't get into many of the\nfeatures it offered. Its entirely possible I never learned about\ndifftool.\n\nI've never found that I cannot get the information I need out of Git\nwhen I need it. Actually I've found it to be the easiest VCS to get\ndata out of, beating CVS, Perforce, BitKeeper, SVN, etc. hands down.\nOf course I also know Git better than I know those tools...\n\n-- \nShawn.\n"},{"id":"55926","messageId":"471408B8.8080509@bluelane.com","threadId":"8948","inReplyTo":"20071016000359.GT27899@spearce.org","subject":"Re: How to Import a bitkeeper repo into git","fromName":"Pete/Piet Delaney","fromEmail":"pete@bluelane.com","sentAt":"2007-10-16T00:41:28Z","receivedAt":"2007-10-16T00:41:28Z","isPatch":false,"sender":{"key":"pete@bluelane.com","avatar":null},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nShawn O. Pearce wrote:\n> Pete/Piet Delaney wrote:\n>> I imported the CVS repository to git and it worked great. Since all\n>> of our other repository are in bitkeeper the management would like to\n>> stick with CVS. With git apparently still being weak in the area of\n>> supporting difftool on different version that seems somewhat reasonable\n>> for the time being.\n> ...\n>> I was curious why the difftool paradigm hasn't been integrated into\n>> the git GUIs. It's very comfortable and I think it has been used in\n>> other source code control systems, for example Sun Microsystems.\n> \n> What's difftool? What's so great about it?\n\nIt's a side by side graphical diff. So instead of showing the difference\nlike diff does it takes the output from diff and shows the originals\nwith the diffs highlighted.\n\ntkdiff is a good example that's easy to down load and see. So\njust imagine allowing git-gui to run tkdiff of revisions you select\nwith the mouse.\n\n\n> \n> Forgive my ignorance but it has been many years since I last used\n> BitKeeper and even when I did use it I didn't get into many of the\n> features it offered. Its entirely possible I never learned about\n> difftool.\n\nTry downloading tkdiff. There also a X implementation,\nI think it's xdiff.\n\n> \n> I've never found that I cannot get the information I need out of Git\n> when I need it. Actually I've found it to be the easiest VCS to get\n> data out of, beating CVS, Perforce, BitKeeper, SVN, etc. hands down.\n> Of course I also know Git better than I know those tools...\n\nTry tkdiff and then tell me you don't find it easier to read that\nthe straight output from diff.\n\n- -piet\n\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.7 (GNU/Linux)\nComment: Using GnuPG with Mozilla - http://enigmail.mozdev.org\n\niD8DBQFHFAi4JICwm/rv3hoRAluCAJ9jFrA9G8aKQi1rtM2CSiNnmhlo4wCeJjk7\nLONAM+lzvin021HAhQ8jKoE=\n=QsE/\n-----END PGP SIGNATURE-----\n"},{"id":"55928","messageId":"alpine.LFD.0.999.0710151711280.6887@woody.linux-foundation.org","threadId":"8948","inReplyTo":"4713FA4A.5090501@bluelane.com","subject":"Re: How to Import a bitkeeper repo into git","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-10-16T00:45:44Z","receivedAt":"2007-10-16T00:45:44Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 15 Oct 2007, Pete/Piet Delaney wrote:\n> \n> I imported the CVS repository to git and it worked great. Since all\n> of our other repository are in bitkeeper the management would like to\n> stick with CVS. With git apparently still being weak in the area of\n> supporting difftool on different version that seems somewhat reasonable\n> for the time being.\n\nI can't see how bk's difftool could possibly have any relevance to the \n\"reasonable to stick with CVS\" decision, but hey, I'm always surprised by \npeoples inventiveness in rationalizing their decisions ;)\n\nI don't know what difftool does that a simple\n\n\tgit diff -U99 | viewdiff -\n\nwouldn't do, but in all honesty, I don't think I ever used difftool (I \nfound the other tools in bk much more useful - eg mergetool, renametool)\n\nI don't actually know of any sane programs to view unified diffs, but you \ncan script one with little trouble. Here's a really hacky one I just came \nup with:\n\n\t#!/bin/sh\n\tcat \"$@\" > /tmp/diff\n\tgrep '^[ -]' /tmp/diff > /tmp/orig\n\tgrep '^[ +]' /tmp/diff > /tmp/result\n\tmeld /tmp/orig /tmp/result\n\nwhich fools 'meld' into showing a unified diff in a nice graphical manner.\n\n[ Quite frankly, I don't understand why tools like meld and kdiff3 can't \n just take the unified diff directly - they have *all* the logic, it \n should be trivial to do, and very useful to view diffs for those people \n who like that graphical bling. ]\n\n> The folks at bitmover are converting you kernels to bk and it's\n> maintaining the branch history and I'd like to do the same. So far\n> they haven't help us convert the git repository to bk. Do you happen\n> to know of someone else that might now how to do this in case the\n> folks at bitmover can't provide the scripts to convert this git\n> repository to bk?\n\nHmm. Converting from git to bk should not be that hard at least \nconceptually, but no, I have no idea how to script it sanely and \nefficiently. The obvious solutions all would want to have multiple active \nheads of development open at the same time (Larry calls them \"LOD's\" not \nbranches), and would also require some way to set the result of a merge. \nNeither of which I would know how to do in BK (I created a lot of merges \nin BK, but I always let BK do the merging - I wouldn't know how to specify \nthe merge result by hand).\n\n\t\tLinus\n"},{"id":"55929","messageId":"20071016011212.GA609@old.davidb.org","threadId":"8948","inReplyTo":"alpine.LFD.0.999.0710151711280.6887@woody.linux-foundation.org","subject":"Re: How to Import a bitkeeper repo into git","fromName":"David Brown","fromEmail":"git@davidb.org","sentAt":"2007-10-16T01:12:12Z","receivedAt":"2007-10-16T01:12:12Z","isPatch":false,"sender":{"key":"git@davidb.org","avatar":"https://gravatar.com/avatar/94c86a2938470a74c2eac5e2b69afc0871f79a660295c02219597aba8cb101c1?d=mp&s=160"},"body":"On Mon, Oct 15, 2007 at 05:45:44PM -0700, Linus Torvalds wrote:\n\n>\tgit diff -U99 | viewdiff -\n\nDo you have reference for viewdiff. I can't seem to locate it.\n\n>[ Quite frankly, I don't understand why tools like meld and kdiff3 can't \n> just take the unified diff directly - they have *all* the logic, it \n> should be trivial to do, and very useful to view diffs for those people \n> who like that graphical bling. ]\n\nkompare can read the unified diffs. If you add enough context, the result\nis no different than the full files.\n\nDavid\n"},{"id":"55930","messageId":"20071016011325.GB609@old.davidb.org","threadId":"8948","inReplyTo":"471408B8.8080509@bluelane.com","subject":"Re: How to Import a bitkeeper repo into git","fromName":"David Brown","fromEmail":"git@davidb.org","sentAt":"2007-10-16T01:13:25Z","receivedAt":"2007-10-16T01:13:25Z","isPatch":false,"sender":{"key":"git@davidb.org","avatar":"https://gravatar.com/avatar/94c86a2938470a74c2eac5e2b69afc0871f79a660295c02219597aba8cb101c1?d=mp&s=160"},"body":"On Mon, Oct 15, 2007 at 05:41:28PM -0700, Pete/Piet Delaney wrote:\n\n>Try tkdiff and then tell me you don't find it easier to read that\n>the straight output from diff.\n\nBoth. Most of the time, I find the diff output easier to read. Only when\na change modifies a whole bunch of lines sprinkled around do I find the\nside-by-side format easier. Even then, it is only marginal.\n\nHowever, asking for a side-by-side diff viewer is probably the most common\nrequest I've gotten from people I work with starting to use git.\n\nDavid\n"},{"id":"55931","messageId":"alpine.LFD.0.999.0710151815230.6887@woody.linux-foundation.org","threadId":"8948","inReplyTo":"20071016011212.GA609@old.davidb.org","subject":"Re: How to Import a bitkeeper repo into git","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-10-16T01:22:59Z","receivedAt":"2007-10-16T01:22:59Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 15 Oct 2007, David Brown wrote:\n>\n> On Mon, Oct 15, 2007 at 05:45:44PM -0700, Linus Torvalds wrote:\n> \n> > \tgit diff -U99 | viewdiff -\n> \n> Do you have reference for viewdiff. I can't seem to locate it.\n\nThat was the stupid script I just posted ;)\n\n> > [ Quite frankly, I don't understand why tools like meld and kdiff3 can't\n> > just take the unified diff directly - they have *all* the logic, it should\n> > be trivial to do, and very useful to view diffs for those people who like\n> > that graphical bling. ]\n> \n> kompare can read the unified diffs. If you add enough context, the result\n> is no different than the full files.\n\nAhh, good pointer. I had to google for it to find that it's part of the \nkdesdk package, which I hadn't installed. But a simple \"yum install \nkdesdk\" worked fine.\n\nMuch better than my stupid script ;)\n\n\t\tLinus\n"},{"id":"55938","messageId":"471433F3.40606@bluelane.com","threadId":"8948","inReplyTo":"alpine.LFD.0.999.0710151711280.6887@woody.linux-foundation.org","subject":"Re: How to Import a bitkeeper repo into git","fromName":"Pete/Piet Delaney","fromEmail":"pete@bluelane.com","sentAt":"2007-10-16T03:45:55Z","receivedAt":"2007-10-16T03:45:55Z","isPatch":false,"sender":{"key":"pete@bluelane.com","avatar":null},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nLinus Torvalds wrote:\n> \n> On Mon, 15 Oct 2007, Pete/Piet Delaney wrote:\n>> I imported the CVS repository to git and it worked great. Since all\n>> of our other repository are in bitkeeper the management would like to\n>> stick with CVS. With git apparently still being weak in the area of\n>> supporting difftool on different version that seems somewhat reasonable\n>> for the time being.\n> \n> I can't see how bk's difftool could possibly have any relevance to the \n> \"reasonable to stick with CVS\" decision, but hey, I'm always surprised by \n> peoples inventiveness in rationalizing their decisions ;)\n> \n> I don't know what difftool does that a simple\n> \n> \tgit diff -U99 | viewdiff -\n\nSigh, no help for git diff.\n\n> \n> wouldn't do, but in all honesty, I don't think I ever used difftool (I \n> found the other tools in bk much more useful - eg mergetool, renametool)\n\nWondering if adding a file dimension to gitk might help and adding the\nability to diff different version of a file git gitk by doing something\nlike holding down the shift key and/or adding a new view pull down.\n\n\n> \n> I don't actually know of any sane programs to view unified diffs, but you \n> can script one with little trouble. Here's a really hacky one I just came \n> up with:\n> \n> \t#!/bin/sh\n> \tcat \"$@\" > /tmp/diff\n> \tgrep '^[ -]' /tmp/diff > /tmp/orig\n> \tgrep '^[ +]' /tmp/diff > /tmp/result\n> \tmeld /tmp/orig /tmp/result\n> \n> which fools 'meld' into showing a unified diff in a nice graphical manner.\n\nI just download 'meld', looks interesting, I didn't know about it or\n'kompare'. Linking either one into gitk would be a pleasant graphical\n'bling'.\n\n> \n> [ Quite frankly, I don't understand why tools like meld and kdiff3 can't \n> just take the unified diff directly - they have *all* the logic, it \n> should be trivial to do, and very useful to view diffs for those people \n> who like that graphical bling. ]\n> \n>> The folks at bitmover are converting you kernels to bk and it's\n>> maintaining the branch history and I'd like to do the same. So far\n>> they haven't help us convert the git repository to bk. Do you happen\n>> to know of someone else that might now how to do this in case the\n>> folks at bitmover can't provide the scripts to convert this git\n>> repository to bk?\n> \n> Hmm. Converting from git to bk should not be that hard at least \n> conceptually, but no, I have no idea how to script it sanely and \n> efficiently. The obvious solutions all would want to have multiple active \n> heads of development open at the same time (Larry calls them \"LOD's\" not \n> branches), and would also require some way to set the result of a merge. \n> Neither of which I would know how to do in BK (I created a lot of merges \n> in BK, but I always let BK do the merging - I wouldn't know how to specify \n> the merge result by hand).\n\nHmm, actually I'm only seeing rev topology up to 2.6.13,\nlater version seem to be linear and when I try to use a larger\ntime window something seems to crashing, the gui goes away,\nand 'bk revtool' returns. Sigh.\n\nI'll try keeping it real simple and just import our release branch\nand hope for the best. Hopefully Johnannes, or perhaps folks more\ninvolved with gitk can add a bit more graphical bling soon to the\ncheetah release. BTW, is this the right mailing list for discussing\ngitk as well as git?\n\n- -piet\n\n> \n> \t\tLinus\n> -\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n> \n\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.7 (GNU/Linux)\nComment: Using GnuPG with Mozilla - http://enigmail.mozdev.org\n\niD8DBQFHFDPyJICwm/rv3hoRAsU0AJ9o6rHtu5rkiUeNlheRNUpwd4bfagCdHEK8\nhDeVvRCyD8Xf8INbdMpuDDU=\n=XB2c\n-----END PGP SIGNATURE-----\n"},{"id":"55945","messageId":"e5bfff550710152156t33ba10dam6171e3210c18d3ac@mail.gmail.com","threadId":"8948","inReplyTo":"471433F3.40606@bluelane.com","subject":"Re: How to Import a bitkeeper repo into git","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-10-16T04:56:16Z","receivedAt":"2007-10-16T04:56:16Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 10/16/07, Pete/Piet Delaney wrote:\n>\n> I just download 'meld', looks interesting, I didn't know about it or\n> 'kompare'. Linking either one into gitk would be a pleasant graphical\n> 'bling'.\n>\n\nIn case you are interested a git GUI viewer called qgit can spawn\n'Kompare' , 'Meld' or any other diff tool that support 'two files'\ncommand line interface:\n\n$my_preferred_diff_tool file1.txt file2.txt\n\nAnd they will show what you are looking for. The input files are\nprepared by qgit that also handles the housekeeping at the end.\n\nAnother feature you asked, i.e. CTRL + right click to select a\nrevision (different from the parent) to diff against the current one\nis also already implemented.\n\nAnd of course the two above features can be integrated: you select two\nrandom revisions and then call the external diff viewer to check at\nthe differences in the way you prefer.\n\nIt is possible to download qgit from\n\nhttp://sourceforge.net/project/showfiles.php?group_id=139897\n\n\nTwo versions:\n\nqgit-1.5.7 is Qt3 based\n\nqgit-2.0 is Qt4 based (works also under Windows)\n\n\n\nregards\nMarco\n"},{"id":"55953","messageId":"471454B5.7040802@bluelane.com","threadId":"8948","inReplyTo":"e5bfff550710152156t33ba10dam6171e3210c18d3ac@mail.gmail.com","subject":"Re: How to Import a bitkeeper repo into git","fromName":"Pete/Piet Delaney","fromEmail":"pete@bluelane.com","sentAt":"2007-10-16T06:05:41Z","receivedAt":"2007-10-16T06:05:41Z","isPatch":false,"sender":{"key":"pete@bluelane.com","avatar":null},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nMarco Costalba wrote:\n\nHi Marco:\n\n> On 10/16/07, Pete/Piet Delaney wrote:\n>> I just download 'meld', looks interesting, I didn't know about it or\n>> 'kompare'. Linking either one into gitk would be a pleasant graphical\n>> 'bling'.\n>>\n> \n> In case you are interested a git GUI viewer called qgit can spawn\n> 'Kompare' , 'Meld' or any other diff tool that support 'two files'\n> command line interface:\n> \n> $my_preferred_diff_tool file1.txt file2.txt\n> \n> And they will show what you are looking for. The input files are\n> prepared by qgit that also handles the housekeeping at the end.\n\nGreat, I installed Qgit version 1.5.3 a while ago, I didn't\nnotice these advantages over gitq.\n\nYea, I just noticed, if I pull down External Diff in the files\nwindow it tosses the diffs to Kompare. Super!\n\n\n> Another feature you asked, i.e. CTRL + right click to select a\n> revision (different from the parent) to diff against the current one\n> is also already implemented.\n\nIt's not quite a intuitive/familiar as with bitkeeper. I suspect I just\nneed some practice. I selected a huge list if files that we use to\nfilter the release with and double clicked on the file I thought showing\nto focus on that file. The I pulled down External Diff and it took for\never; like it's confused.\n\nOften we/I want to see the rev history for a particular file.\nHow would you do that with Qgit?\n\n> \n> And of course the two above features can be integrated: you select two\n> random revisions and then call the external diff viewer to check at\n> the differences in the way you prefer.\n\nCan I see just the revs for a particular file?\n\n> \n> It is possible to download qgit from\n> \n> http://sourceforge.net/project/showfiles.php?group_id=139897\n\nI'll get the latest and greatest. Thinks. Often the problem is\nhaving the current version of Qt3. My workstation is Mandrake\n1005 Limited Edition (X11 Xinerama works on this release).\nLooks like I have Qt3 on my workstation. Would it be worthwhile\nto install Qt4 from src and try to use qgit-2.0?\n\n\n> \n> Two versions:\n> \n> qgit-1.5.7 is Qt3 based\n> \n> qgit-2.0 is Qt4 based (works also under Windows)\n\nWhat new features are in 2.0 over 1.5.7?\n\nThanks Marco,\n\n- -piet\n\n> \n> \n> \n> regards\n> Marco\n\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.7 (GNU/Linux)\nComment: Using GnuPG with Mozilla - http://enigmail.mozdev.org\n\niD8DBQFHFFS0JICwm/rv3hoRAlFIAJsEbp22Fs1fGVlt+RIXOOjJ3ZiqIQCeIQ1/\nnG/JJUfuNNyoIL2MUJppId4=\n=JQWE\n-----END PGP SIGNATURE-----\n"},{"id":"55994","messageId":"e5bfff550710160211g5dbfa7fai95386b173edc45c3@mail.gmail.com","threadId":"8948","inReplyTo":"471454B5.7040802@bluelane.com","subject":"Re: How to Import a bitkeeper repo into git","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-10-16T09:11:17Z","receivedAt":"2007-10-16T09:11:17Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 10/16/07, Pete/Piet Delaney wrote:\n>\n> It's not quite a intuitive/familiar as with bitkeeper. I suspect I just\n> need some practice. I selected a huge list if files that we use to\n> filter the release with and double clicked on the file I thought showing\n> to focus on that file. The I pulled down External Diff and it took for\n> ever; like it's confused.\n>\n\nYou shoudl select only _one_ additional revision.\n\nThe currenlty selected revision is the base + select another one\n(only) with CTRL + *RIGHT* click (the file list change background\ncolor) , then call external diff tool.\n\n> Often we/I want to see the rev history for a particular file.\n> How would you do that with Qgit?\n>\n\nSelect the file from the file list (right bottom pane) or from the\ntree view (use key 't' to toggle treev view) double click on it or use\ncontext menu (right click on the file name) and that's all.\n\n>\n> Can I see just the revs for a particular file?\n>\n\nSee above.\n\n\nI know I'm going to tell you a very _unpopular_ thing, but, in case\nyou have 5 minutes of spare time (yes, it doesn't take longer), open\nqgit then please press a nice key called 'F1', a nice handbook will\nappear...\n\nI really suggest to look at it. To keep UI 'clean' a lot of features\nare not immediatly visible, so reading the handbook (at least the\nchapter's titiles) would give you a better idea of what qgit could do\nfor you.\n\n>\n> I'll get the latest and greatest. Thinks. Often the problem is\n> having the current version of Qt3. My workstation is Mandrake\n> 1005 Limited Edition (X11 Xinerama works on this release).\n> Looks like I have Qt3 on my workstation. Would it be worthwhile\n> to install Qt4 from src and try to use qgit-2.0?\n>\n\nYes it is. There are a lot of new featrures, is almost as stable as\nthe previous and if you are interested in file history (annotations)\nin qgit-2.0 this feature has been greatly speeded up.\n\n\nHave fun\nMarco\n"},{"id":"56085","messageId":"4714EF53.8090707@op5.se","threadId":"8948","inReplyTo":"e5bfff550710160211g5dbfa7fai95386b173edc45c3@mail.gmail.com","subject":"Re: How to Import a bitkeeper repo into git","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-10-16T17:05:23Z","receivedAt":"2007-10-16T17:05:23Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Marco Costalba wrote:\n> On 10/16/07, Pete/Piet Delaney wrote:\n> \n>> Would it be worthwhile\n>> to install Qt4 from src and try to use qgit-2.0?\n>>\n> \n> Yes it is. There are a lot of new featrures, is almost as stable as\n> the previous and if you are interested in file history (annotations)\n> in qgit-2.0 this feature has been greatly speeded up.\n> \n\nThe only thing I really, really, really don't like about qgit4 is the\nfact that it fudges up the commit-message. I've been trying for two\ndays to get rid of the HTML output, but I just can't get it done\nwithout the signed-off-by email being enclosed in <> tags.\n\nMarco, is there any chance you could make the old commit-message view\nan option? Especially, the subject line should really, really be at the\nbottom, with the rest of the message-text (although I liked the other\nview without the colored box a lot more). The little arrows in the\ncommit window are also fairly annoying, as one quite quickly understands\nthat up-/down-arrows work much better for that sort of stuff anyway.\n\nI'm at my wits end wrt c++ and qt, and can't for the life of me think of\nhow to make it an option :(\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"56108","messageId":"20071016191549.GG26127@efreet.light.src","threadId":"8948","inReplyTo":"alpine.LFD.0.999.0710151711280.6887@woody.linux-foundation.org","subject":"Re: How to Import a bitkeeper repo into git","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2007-10-16T19:15:49Z","receivedAt":"2007-10-16T19:15:49Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Mon, Oct 15, 2007 at 17:45:44 -0700, Linus Torvalds wrote:\n> I don't actually know of any sane programs to view unified diffs, but you \n> can script one with little trouble. Here's a really hacky one I just came \n> up with:\n> \n> \t#!/bin/sh\n> \tcat \"$@\" > /tmp/diff\n> \tgrep '^[ -]' /tmp/diff > /tmp/orig\n> \tgrep '^[ +]' /tmp/diff > /tmp/result\n> \tmeld /tmp/orig /tmp/result\n> \n> which fools 'meld' into showing a unified diff in a nice graphical manner.\n> \n> [ Quite frankly, I don't understand why tools like meld and kdiff3 can't \n> just take the unified diff directly - they have *all* the logic, it \n> should be trivial to do, and very useful to view diffs for those people \n> who like that graphical bling. ]\n\nKompare (KDE analog of meld) can. It is even bound to text/x-diff in\nkonqueror, so opening patches with konqueror yields side-by-side diff view.\nOn the other hand it still keeps a unixy behaviour:\n git diff | kompare -\nworks.\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"},{"id":"56110","messageId":"alpine.LFD.0.999.0710161221590.6887@woody.linux-foundation.org","threadId":"8948","inReplyTo":"20071016191549.GG26127@efreet.light.src","subject":"Re: How to Import a bitkeeper repo into git","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-10-16T19:28:17Z","receivedAt":"2007-10-16T19:28:17Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 16 Oct 2007, Jan Hudec wrote:\n> \n> Kompare (KDE analog of meld) can. It is even bound to text/x-diff in\n> konqueror, so opening patches with konqueror yields side-by-side diff view.\n> On the other hand it still keeps a unixy behaviour:\n> git diff | kompare -\n> works.\n\nSide note: I think kompare is beautiful, but kompare does one thing \ntotally wrong: it seems to think that you only want to look at the diff \nfragments one file at a time.\n\nThat's totally bogus. My trivial four-liner shell script does this better \nthan kompare does - as does \"gitk\" in the diff view window.\n\nThe fact is, quite often you have diffs that are lots of small changes to \ntons of files, and the kompare interface is totally ludicrous and useless. \nIt would be *much* nicer to literally show them as one long flowing diff.\n\nAnd yes, it will depend on circumstances, but I can't seem to even find \nthe config option to not do that. As a result, you have to click through \nall the files manually (even the \"Next file\" thing is grayed out when I do \nthe \"git diff | kompare -\", so I can't even use the keyboard shortcut to \ngo to the next file).\n\nSo I have to say, after playing with it, my shell-script \"viewdiff\" is \nactually infinitely better than \"kompare -\" is, at least for my workflow.\n\n\t\tLinus\n"},{"id":"56200","messageId":"47159779.6010502@bluelane.com","threadId":"8948","inReplyTo":"e5bfff550710152156t33ba10dam6171e3210c18d3ac@mail.gmail.com","subject":"Re: How to Import a bitkeeper repo into git - Had a few questions on Qgit; I like the GUI.","fromName":"Pete/Piet Delaney","fromEmail":"pete@bluelane.com","sentAt":"2007-10-17T05:02:49Z","receivedAt":"2007-10-17T05:02:49Z","isPatch":false,"sender":{"key":"pete@bluelane.com","avatar":null},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nMarco Costalba wrote:\n\nHi Marco:\n\nI've gone back and tried my old Qgit 1.5.3 and it was\nmuch closer in functionality to Bitkeeper.\n\n> On 10/16/07, Pete/Piet Delaney wrote:\n>> I just download 'meld', looks interesting, I didn't know about it or\n>> 'kompare'. Linking either one into gitk would be a pleasant graphical\n>> 'bling'.\n>>\n> \n> In case you are interested a git GUI viewer called qgit can spawn\n> 'Kompare' , 'Meld' or any other diff tool that support 'two files'\n> command line interface:\n> \n> $my_preferred_diff_tool file1.txt file2.txt\n> \n> And they will show what you are looking for. The input files are\n> prepared by qgit that also handles the housekeeping at the end.\n\nWhile I'm looking at the diffs for a file if I pull down External Diff\nit launches 'kcompare' but for a file with a large change it seems\nto be running extremely slow. We have a file with 13,000 files in it\nand I have two changes in the file, each is an addition and deletion\nof about 100 lines in one contiguous block. If I click between them\nit's fine but since the 100 lines is more than one page I try to\nscroll thru the diff. At this point of time 'kompare' seems to be\nusing 95% of the CPU time and it takes about 10 seconds for it to\nscroll. It scrolls fine in the qgit diff window. It;s not a problem\nfor small files. Know of what can me done so that 'kcompare' works\nfast on large files; something like pointing it's tmp files to a\nnot NFS partition.\n\n\nAnother problem I've noticed is that sometime while running git\nit seems to spend a large amount of time switching from one\nchange-set to the next; seems to be due to all of the tagged\nfiles.\n\n> Another feature you asked, i.e. CTRL + right click to select a\n> revision (different from the parent) to diff against the current one\n> is also already implemented.\n\nIt seems that while I'm in \"Rev List\" mode I can select the the\ntwo versions to compare a selected file with View->External diff...\n\nNow, if I pull down \"View File\" or go to the file context were\nyou see the change-set for a file then I can't get the CTRL + right\nclick to allow me to diff two revisions of the file.\n\nWhile messing around in this area of trying to diff two revision\nof the file from the file context I got:\n- ------------------------------------------------------------------\n/nethome/piet/src/blux$ qgit\nSaving cache. Please wait...\nCompressing data...\nDone.\nSaving cache. Please wait...\nCompressing data...\nDone.\nASSERT in getAncestor: empty file from\ne86306878efb575be80d070ac3dec49f8d358cd1\nASSERT in lookupAnnotation: no annotation for cli/quagga-0.96/lib/bluelane.c\nASSERT in remove: 8 is not the first in list\nThrown exception 'Canceling annotation'\nException 'Canceling annotation' not handled in init...re-throw\nterminate called after throwing an instance of 'i'\nAborted\n/nethome/piet/src/blux$\n- ------------------------------------------------------------------\n\nMY guess is that I should install a newer version of qgit,\nI'm using 1.5.3.\n\nHow difficult is it to upgrade to the Qt4. Can I just\ninstall it to /usr/local and not interfere with Qt3?\nLast I recall messing with installing ethereal from src\nI needed a graphics lib and as I recall installing it in\n/usr/local/ confused some build crap. It would be interesting\nto try out your new qgit-2.0.\n\n> \n> And of course the two above features can be integrated: you select two\n> random revisions and then call the external diff viewer to check at\n> the differences in the way you prefer.\n\nRight, but how do I do this from the file context?\n\n> \n> It is possible to download qgit from\n> \n> http://sourceforge.net/project/showfiles.php?group_id=139897\n> \n> \n> Two versions:\n> \n> qgit-1.5.7 is Qt3 based\n> \n> qgit-2.0 is Qt4 based (works also under Windows)\n\nPicked up both, I'll start with qgit-1.5.7.\n\nInstalling qt4 might not be so easy; looking at:\n\n\thttp://packages.qa.debian.org/q/qt4-x11.html\n\nit seems to be pretty big. The date on 1.5.7 was very\nclose to 2.0 so I thought they might be very close in\nfunctionality and you maintaining the same code for\nboth the common Qt3 and the new Qt4 to make it easy\nfor users to install.\n\nRegards,\nPiet\n\n> \n> \n> \n> regards\n> Marco\n\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.7 (GNU/Linux)\nComment: Using GnuPG with Mozilla - http://enigmail.mozdev.org\n\niD8DBQFHFZd4JICwm/rv3hoRAgMVAJ0d49Sbbuppt8o5F1U7tbkaQjSQzwCfV0nn\nmnFXyUWIKGhoxz7pqulJeVk=\n=Jq+Y\n-----END PGP SIGNATURE-----\n"},{"id":"56201","messageId":"47159BF9.9040400@bluelane.com","threadId":"8948","inReplyTo":"e5bfff550710160211g5dbfa7fai95386b173edc45c3@mail.gmail.com","subject":"Re: How to Import a bitkeeper repo into git","fromName":"Pete/Piet Delaney","fromEmail":"pete@bluelane.com","sentAt":"2007-10-17T05:22:01Z","receivedAt":"2007-10-17T05:22:01Z","isPatch":false,"sender":{"key":"pete@bluelane.com","avatar":null},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nMarco Costalba wrote:\n> On 10/16/07, Pete/Piet Delaney wrote:\n>> It's not quite a intuitive/familiar as with bitkeeper. I suspect I just\n>> need some practice. I selected a huge list if files that we use to\n>> filter the release with and double clicked on the file I thought showing\n>> to focus on that file. The I pulled down External Diff and it took for\n>> ever; like it's confused.\n>>\n> \n> You shoudl select only _one_ additional revision.\n> \n> The currenlty selected revision is the base + select another one\n> (only) with CTRL + *RIGHT* click (the file list change background\n> color) , then call external diff tool.\n> \n>> Often we/I want to see the rev history for a particular file.\n>> How would you do that with Qgit?\n>>\n> \n> Select the file from the file list (right bottom pane) or from the\n> tree view (use key 't' to toggle treev view) double click on it or use\n> context menu (right click on the file name) and that's all.\n\n't' worked fine but still can see how to diff do of the list of\nchanges for a file. Viewing diffs of files based on change sets\nworked fine but I think with BitKeeper I found it helpful to be\nable to do a full 'kompare' type diff the file only; often I'm\nnot interested in which change set it went into.\n\nSomething for a future version or am I lucky and you have\nit covered already?\n\n> \n>> Can I see just the revs for a particular file?\n>>\n> \n> See above.\n> \n> \n> I know I'm going to tell you a very _unpopular_ thing, but, in case\n> you have 5 minutes of spare time (yes, it doesn't take longer), open\n> qgit then please press a nice key called 'F1', a nice handbook will\n> appear...\n\nGood Idea, thought it's brought up a few questions:\n\n\t1. When I do the to Decrease the font size\n\t I can't undo it with the . Also \n\t doesn't seem to do anything.\n\n\t2. When displaying the \"Lane info\" why can't I see the\n branch names?\n\n>\n> I really suggest to look at it. To keep UI 'clean' a lot of features\n> are not immediatly visible, so reading the handbook (at least the\n> chapter's titiles) would give you a better idea of what qgit could do\n> for you.\n\nI'll read it a few more times. I seem to sometimes get into a state\nwhere I'm locked onto the current change set and can't get back to\nthe other change sets without starting another qgit.\n\n> \n>> I'll get the latest and greatest. Thinks. Often the problem is\n>> having the current version of Qt3. My workstation is Mandrake\n>> 1005 Limited Edition (X11 Xinerama works on this release).\n>> Looks like I have Qt3 on my workstation. Would it be worthwhile\n>> to install Qt4 from src and try to use qgit-2.0?\n>>\n> \n> Yes it is. There are a lot of new featrures, is almost as stable as\n> the previous and if you are interested in file history (annotations)\n> in qgit-2.0 this feature has been greatly speeded up.\n\nDo you know if it's a lot of work to install Qt4?\n\n- -piet\n\n> \n> \n> Have fun\n> Marco\n\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.7 (GNU/Linux)\nComment: Using GnuPG with Mozilla - http://enigmail.mozdev.org\n\niD8DBQFHFZv5JICwm/rv3hoRAky6AJ47DFL/pWa8CCHv0ezw0wdkLLmbIQCeJqZN\ncNHuMINv2/7fmnwczWcowhs=\n=VSZN\n-----END PGP SIGNATURE-----\n"},{"id":"56209","messageId":"e5bfff550710162357r2c3744b1me5138edf24a56090@mail.gmail.com","threadId":"8948","inReplyTo":"4714EF53.8090707@op5.se","subject":"Re: How to Import a bitkeeper repo into git","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-10-17T06:57:35Z","receivedAt":"2007-10-17T06:57:35Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 10/16/07, Andreas Ericsson wrote:\n> Marco Costalba wrote:\n> > On 10/16/07, Pete/Piet Delaney wrote:\n> >\n> >> Would it be worthwhile\n> >> to install Qt4 from src and try to use qgit-2.0?\n> >>\n> >\n> > Yes it is. There are a lot of new featrures, is almost as stable as\n> > the previous and if you are interested in file history (annotations)\n> > in qgit-2.0 this feature has been greatly speeded up.\n> >\n>\n> The only thing I really, really, really don't like about qgit4 is the\n> fact that it fudges up the commit-message. I've been trying for two\n> days to get rid of the HTML output, but I just can't get it done\n> without the signed-off-by email being enclosed in <> tags.\n>\n\nYou mean when you commit some changes or when you brows the revisions?\n\nIf it is the highlighted title that annoy you I can try to remove the\nbackground color, or set as plain text as an option.\n\n> view without the colored box a lot more). The little arrows in the\n> commit window are also fairly annoying, as one quite quickly understands\n> that up-/down-arrows work much better for that sort of stuff anyway.\n>\n\nLittle arrows should already be removable from settings->browse->'Show\nsmart labels' , you can also add lateral tabs with\nsettings->browse->'Show tabbed revisions' if you like.\n\n\nMarco\n"},{"id":"56211","messageId":"e5bfff550710170014m395d5b8cld87a5c2c9f7d71a@mail.gmail.com","threadId":"8948","inReplyTo":"47159BF9.9040400@bluelane.com","subject":"Re: How to Import a bitkeeper repo into git","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-10-17T07:14:45Z","receivedAt":"2007-10-17T07:14:45Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 10/17/07, Pete/Piet Delaney wrote:\n>\n> 't' worked fine but still can see how to diff do of the list of\n> changes for a file. Viewing diffs of files based on change sets\n> worked fine but I think with BitKeeper I found it helpful to be\n> able to do a full 'kompare' type diff the file only; often I'm\n> not interested in which change set it went into.\n>\n\nWell, open tree view ('t'), select the file you are interested of,\nthen click the magic wand button on the tool bar, now revisions you\nsee are filtered by that file, if you browse the revisions the\npatch/diff you see will always point to your file (also if you can see\nthe whole patch).\n\n> Something for a future version or am I lucky and you have\n> it covered already?\n>\n\nDon't know, depends on how you answer to the above point ;-)\n\n>\n> Good Idea, thought it's brought up a few questions:\n>\n> 1. When I do the to Decrease the font size\n> I can't undo it with the . Also \n> doesn't seem to do anything.\n>\n> 2. When displaying the \"Lane info\" why can't I see the\n> branch names?\n>\n\nThanks for the reports, I will investigate as soon as I have a bit of\nspare time.\n\n>\n> I'll read it a few more times. I seem to sometimes get into a state\n> where I'm locked onto the current change set and can't get back to\n> the other change sets without starting another qgit.\n>\n\nPlease, could you be so kind to better explain me the above point.\nSeems interesting, but I didn't get how to reproduce.\n\n\n> >\n> > Yes it is. There are a lot of new featrures, is almost as stable as\n> > the previous and if you are interested in file history (annotations)\n> > in qgit-2.0 this feature has been greatly speeded up.\n>\n> Do you know if it's a lot of work to install Qt4?\n>\n\nWith Mandriva you are just at an uprmi away.\n\nTry something like\n\nurpmi libqt4-devel\n\nIt worked for me ;-)\n\nMarco\n"},{"id":"56215","messageId":"e5bfff550710170030y7778e96ax146acea7a0e57a67@mail.gmail.com","threadId":"8948","inReplyTo":"47159779.6010502@bluelane.com","subject":"Re: How to Import a bitkeeper repo into git - Had a few questions on Qgit; I like the GUI.","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-10-17T07:30:48Z","receivedAt":"2007-10-17T07:30:48Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 10/17/07, Pete/Piet Delaney wrote:\n>\n> While I'm looking at the diffs for a file if I pull down External Diff\n> it launches 'kcompare' but for a file with a large change it seems\n> to be running extremely slow.\n\nqgit does not intergarte Kompare functionality, it just prepares the\nfiles and spawns a Kompare process.\n\nSo there's seem nothing qgit can do about Kompare speed. You can try\nwith different diff viewers, meld,...etc..\n\n\n> for small files. Know of what can me done so that 'kcompare' works\n> fast on large files; something like pointing it's tmp files to a\n> not NFS partition.\n>\n\nWell temporary file sfor Kompare are created in the repository working\ndirectory. If this is a problem for you you can save manually the\nfiles corresponding to the two revisions you want to diff (open tree\nview, select the file, right click to open context menu, save as...)\n\nYou need to repeat the above 'save as...' the first time selecting the\nfirst revision you want to compare, then selecting the other revision\nin main view, so that tree view is updated and you end-up saving the\ncorrect files.\n\nYou can save the files where you want then run Kompare manually, at\nleast you test your assumption about slowness of NFS partition.\n\n>\n> Another problem I've noticed is that sometime while running git\n> it seems to spend a large amount of time switching from one\n> change-set to the next; seems to be due to all of the tagged\n> files.\n>\n\nIf you can post a repository where this occurs and the step to\nreproduce I can investigate further.\n\n> > Another feature you asked, i.e. CTRL + right click to select a\n> > revision (different from the parent) to diff against the current one\n> > is also already implemented.\n>\n> It seems that while I'm in \"Rev List\" mode I can select the the\n> two versions to compare a selected file with View->External diff...\n>\n> Now, if I pull down \"View File\" or go to the file context were\n> you see the change-set for a file then I can't get the CTRL + right\n> click to allow me to diff two revisions of the file.\n>\n\n\nYes. This is true, is not supported this feature. Maybe could be added ;-)\n\n\n>\n> MY guess is that I should install a newer version of qgit,\n> I'm using 1.5.3.\n>\n\nPlease install 1.5.7, it has several bugs fixed.\n\n> How difficult is it to upgrade to the Qt4. Can I just\n> install it to /usr/local and not interfere with Qt3?\n\nIt does not interfere wuth Qt3 also if you install with urpmi,\ndirectories are kept separated. I have installed both with no\nproblems.\n\n> Last I recall messing with installing ethereal from src\n> I needed a graphics lib and as I recall installing it in\n> /usr/local/ confused some build crap. It would be interesting\n> to try out your new qgit-2.0.\n>\n\nQt4 is big and complex, I would really suggest avoid experimenting\nwith that library, stay safe and use urpmi.\n\n> >\n> > And of course the two above features can be integrated: you select two\n> > random revisions and then call the external diff viewer to check at\n> > the differences in the way you prefer.\n>\n> Right, but how do I do this from the file context?\n>\n\nIn this case (and also in the above case of external viewer) you need\nthe magic wand ;-)\n\nSelect a file from tree view, go with the magic wand and you can do\neverithing from main view.\n\n>\n> it seems to be pretty big. The date on 1.5.7 was very\n> close to 2.0 so I thought they might be very close in\n> functionality and you maintaining the same code for\n> both the common Qt3 and the new Qt4 to make it easy\n> for users to install.\n>\n\nYes it is. qgit-1.5.7 should be very similar to qgit-2.0 regarding the\nfeatures you listed above.\n\n\nMarco\n"},{"id":"56254","messageId":"47162F28.4040908@op5.se","threadId":"8948","inReplyTo":"e5bfff550710162357r2c3744b1me5138edf24a56090@mail.gmail.com","subject":"Re: How to Import a bitkeeper repo into git","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-10-17T15:50:00Z","receivedAt":"2007-10-17T15:50:00Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Marco Costalba wrote:\n> On 10/16/07, Andreas Ericsson wrote:\n>> Marco Costalba wrote:\n>>> On 10/16/07, Pete/Piet Delaney wrote:\n>>>\n>>>> Would it be worthwhile\n>>>> to install Qt4 from src and try to use qgit-2.0?\n>>>>\n>>> Yes it is. There are a lot of new featrures, is almost as stable as\n>>> the previous and if you are interested in file history (annotations)\n>>> in qgit-2.0 this feature has been greatly speeded up.\n>>>\n>> The only thing I really, really, really don't like about qgit4 is the\n>> fact that it fudges up the commit-message. I've been trying for two\n>> days to get rid of the HTML output, but I just can't get it done\n>> without the signed-off-by email being enclosed in <> tags.\n>>\n> \n> You mean when you commit some changes or when you brows the revisions?\n> \n\nWhen I browse the revisions. \n\n> If it is the highlighted title that annoy you I can try to remove the\n> background color, or set as plain text as an option.\n> \n\nThat does annoy me indeed, but the primary annoyance is the fact that\nthe subject is no longer listed with the rest of the commit message, but\nrather above the ancestry links.\n\n\n>> view without the colored box a lot more). The little arrows in the\n>> commit window are also fairly annoying, as one quite quickly understands\n>> that up-/down-arrows work much better for that sort of stuff anyway.\n>>\n> \n> Little arrows should already be removable from settings->browse->'Show\n> smart labels' , you can also add lateral tabs with\n> settings->browse->'Show tabbed revisions' if you like.\n> \n\nSweet. I'll have to look into it. Thanks for your gentle instruction, and\na great product :)\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"56256","messageId":"200710171800.37345.robin.rosenberg.lists@dewire.com","threadId":"8948","inReplyTo":"e5bfff550710170030y7778e96ax146acea7a0e57a67@mail.gmail.com","subject":"Re: How to Import a bitkeeper repo into git - Had a few questions on Qgit; I like the GUI.","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2007-10-17T16:00:36Z","receivedAt":"2007-10-17T16:00:36Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"onsdag 17 oktober 2007 skrev Marco Costalba:\n> On 10/17/07, Pete/Piet Delaney wrote:\n> >\n> > While I'm looking at the diffs for a file if I pull down External Diff\n> > it launches 'kcompare' but for a file with a large change it seems\n> > to be running extremely slow.\n> \n> qgit does not intergarte Kompare functionality, it just prepares the\n> files and spawns a Kompare process.\n> \n> So there's seem nothing qgit can do about Kompare speed. You can try\n> with different diff viewers, meld,...etc..\n\nYou could avoid the temporary files if you just pipe the diff to kompare. That\nwould require an option to tell qgit that the external viewer can read a git diff.\n\nAt the time qgit 1.5 was written, kompare could not handle git diffs.\n\n-- robin\n"},{"id":"56298","messageId":"471682E2.1070202@bluelane.com","threadId":"8948","inReplyTo":"e5bfff550710170014m395d5b8cld87a5c2c9f7d71a@mail.gmail.com","subject":"Re: How to Import a bitkeeper repo into git","fromName":"Pete/Piet Delaney","fromEmail":"pete@bluelane.com","sentAt":"2007-10-17T21:47:14Z","receivedAt":"2007-10-17T21:47:14Z","isPatch":false,"sender":{"key":"pete@bluelane.com","avatar":null},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nMarco Costalba wrote:\n> On 10/17/07, Pete/Piet Delaney wrote:\n>> 't' worked fine but still can see how to diff do of the list of\n>> changes for a file. Viewing diffs of files based on change sets\n>> worked fine but I think with BitKeeper I found it helpful to be\n>> able to do a full 'kompare' type diff the file only; often I'm\n>> not interested in which change set it went into.\n>>\n> \n> Well, open tree view ('t'), select the file you are interested of,\n> then click the magic wand button on the tool bar, now revisions you\n> see are filtered by that file, if you browse the revisions the\n> patch/diff you see will always point to your file (also if you can see\n> the whole patch).\n\nI take it the \"magic wand button\" is the check mark on the upper right\nthat says \"Pin View (Alt-V)\". When I pin the view the view of the file\nin Qgit locks to the selected file but the External diff seems to stay\nthe same. The External diff appears to show my last change to the file;\nchanging the change-set selection doesn't seem to change anything with\nthe view pinned.\n\n\n> \n>> Something for a future version or am I lucky and you have\n>> it covered already?\n>>\n> \n> Don't know, depends on how you answer to the above point ;-)\n\nHow'd I do?\n\n> \n>> Good Idea, thought it's brought up a few questions:\n>>\n>> 1. When I do the to Decrease the font size\n>> I can't undo it with the . Also \n>> doesn't seem to do anything.\n>>\n>> 2. When displaying the \"Lane info\" why can't I see the\n>> branch names?\n>>\n> \n> Thanks for the reports, I will investigate as soon as I have a bit of\n> spare time.\n\nok, I suspect that's an easy one.\n\n> \n>> I'll read it a few more times. I seem to sometimes get into a state\n>> where I'm locked onto the current change set and can't get back to\n>> the other change sets without starting another qgit.\n>>\n> \n> Please, could you be so kind to better explain me the above point.\n> Seems interesting, but I didn't get how to reproduce.\n\nI'm not sure how I get into this state either, I'll try to recall\nhow I get into this state the next time it occurs.\n\n\n\n> \n>>> Yes it is. There are a lot of new featrures, is almost as stable as\n>>> the previous and if you are interested in file history (annotations)\n>>> in qgit-2.0 this feature has been greatly speeded up.\n>> Do you know if it's a lot of work to install Qt4?\n>>\n> \n> With Mandriva you are just at an uprmi away.\n> \n> Try something like\n> \n> urpmi libqt4-devel\n\n /nethome/piet$ su\n /nethome/piet$ /usr/sbin/urpmi libqt4-devel\n no package named libqt4-devel\n /nethome/piet$\n\n/urpmi libqt4 also didn't work.\n\n> \n> It worked for me ;-)\n\nI'm running 2005 Limited Edition; I wonder if QT4 even existed then.\nThink it's worth messing with QT4 just to upgrade to you latest version?\nSome of these graphics libs can be bear to install from src.\n\n- -piet\n\n> \n> Marco\n\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.7 (GNU/Linux)\nComment: Using GnuPG with Mozilla - http://enigmail.mozdev.org\n\niD8DBQFHFoLhJICwm/rv3hoRAt73AJ9kWv8EhuaAH/69HqG0+FZOAD8LlgCdH6uU\n2PJDFOuZENrKJBA66MOdANc=\n=yd6t\n-----END PGP SIGNATURE-----\n"},{"id":"56307","messageId":"e5bfff550710171626h733228aw7a251746d2b43c63@mail.gmail.com","threadId":"8948","inReplyTo":"200710171800.37345.robin.rosenberg.lists@dewire.com","subject":"Re: How to Import a bitkeeper repo into git - Had a few questions on Qgit; I like the GUI.","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-10-17T23:26:21Z","receivedAt":"2007-10-17T23:26:21Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 10/17/07, Robin Rosenberg wrote:\n>\n> You could avoid the temporary files if you just pipe the diff to kompare. That\n> would require an option to tell qgit that the external viewer can read a git diff.\n>\n> At the time qgit 1.5 was written, kompare could not handle git diffs.\n>\n\nSo does the other tools I have checked at that time.\n\nBut I don't know if this fixes the problem of slowness reported. A\nlittle test Pete may do is just as I have written in the former email:\ntry to save the big files that cause troubles where he prefers and run\nKompare on them directly from the command line.\n\nIs kompare faster? If no probably the 'pipe' technique will not solve\nthe problem and shrinks the applicability of the external diff\nlauncher to tools that handle diffs directly.\n\nMarco\n"},{"id":"56428","messageId":"200710182312.23616.robin.rosenberg.lists@dewire.com","threadId":"8948","inReplyTo":"e5bfff550710171626h733228aw7a251746d2b43c63@mail.gmail.com","subject":"Re: How to Import a bitkeeper repo into git - Had a few questions on Qgit; I like the GUI.","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2007-10-18T21:12:22Z","receivedAt":"2007-10-18T21:12:22Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"torsdag 18 oktober 2007 skrev Marco Costalba:\n> On 10/17/07, Robin Rosenberg wrote:\n> >\n> > You could avoid the temporary files if you just pipe the diff to kompare. That\n> > would require an option to tell qgit that the external viewer can read a git diff.\n> >\n> > At the time qgit 1.5 was written, kompare could not handle git diffs.\n> >\n> \n> So does the other tools I have checked at that time.\n> \n> But I don't know if this fixes the problem of slowness reported. A\n> little test Pete may do is just as I have written in the former email:\n> try to save the big files that cause troubles where he prefers and run\n> Kompare on them directly from the command line.\n> \n> Is kompare faster? If no probably the 'pipe' technique will not solve\n> the problem and shrinks the applicability of the external diff\n> launcher to tools that handle diffs directly.\n\nkompare is pretty fast. Obviously not as fast as less.\n\n\"git diff HEAD HEAD~1000|kompare -\" takes less than two seconds (hot cache)\non my machine. With small diffs it is almost instantaneous.\n\n-- robin\n"},{"id":"56445","messageId":"4717EF40.6000509@bluelane.com","threadId":"8948","inReplyTo":"e5bfff550710171626h733228aw7a251746d2b43c63@mail.gmail.com","subject":"Re: Qgit performance and maintain CVS environment with GIT repository","fromName":"Pete/Piet Delaney","fromEmail":"pete@bluelane.com","sentAt":"2007-10-18T23:41:52Z","receivedAt":"2007-10-18T23:41:52Z","isPatch":false,"sender":{"key":"pete@bluelane.com","avatar":null},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nMarco Costalba wrote:\n> On 10/17/07, Robin Rosenberg wrote:\n>> You could avoid the temporary files if you just pipe the diff to kompare. That\n>> would require an option to tell qgit that the external viewer can read a git diff.\n>>\n>> At the time qgit 1.5 was written, kompare could not handle git diffs.\n>>\n> \n> So does the other tools I have checked at that time.\n> \n> But I don't know if this fixes the problem of slowness reported. A\n> little test Pete may do is just as I have written in the former email:\n> try to save the big files that cause troubles where he prefers and run\n> Kompare on them directly from the command line.\n> \n> Is kompare faster? If no probably the 'pipe' technique will not solve\n> the problem and shrinks the applicability of the external diff\n> launcher to tools that handle diffs directly.\n\nMarco:\n I'll try kcompare on the huge files both on and off the NFS\n file system to see if it has a noticeable impact.\n\nJohannes:\n I read somewhere in the past week that it was possible to maintain\n our existing CVS environment with git. I though it was a separate\n package to export git back to cvs but I just noticed a git-cvsserver\n and as a std part of git and was wondering about using that.\n\n We have a number of build machines with flamebox perl scripts pulling\n out CVS branches for builds. I was wondering what is the best way to\n use git and it's nicer pull/push model and merge facility and possibly\n maintain CVS exports for scripts doing builds if possible the cvsweb\n and bonsai (CVS Query Form) that a number of engineers are currently\n using. I started looking over out flamebox scripts with the intent\n up converting them over to git but I mentioned the git to cvs\n coexistence and we are wondering if that's a better route than\n upgrading the flamebox scripts. Having our existing cvsweb, bonsai,\n and gitweb along with the git utilities seems at least desirable.\n Any thoughts or suggestions?\n\n- -piet\n\n> \n> Marco\n\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.7 (GNU/Linux)\nComment: Using GnuPG with Mozilla - http://enigmail.mozdev.org\n\niD8DBQFHF+8/JICwm/rv3hoRApKnAJ4suTVrULHeVnU2HrS3TDo+eTzxVQCbBH7x\nNzKdc6wRc1VdAOWgXOXBJ4U=\n=RuQc\n-----END PGP SIGNATURE-----\n"},{"id":"56446","messageId":"Pine.LNX.4.64.0710190054570.25221@racer.site","threadId":"8948","inReplyTo":"4717EF40.6000509@bluelane.com","subject":"Re: Qgit performance and maintain CVS environment with GIT repository","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-19T00:00:08Z","receivedAt":"2007-10-19T00:00:08Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 18 Oct 2007, Pete/Piet Delaney wrote:\n\n> Johannes:\n> I read somewhere in the past week that it was possible to maintain\n> our existing CVS environment with git. I though it was a separate\n> package to export git back to cvs but I just noticed a git-cvsserver\n> and as a std part of git and was wondering about using that.\n\nWhere did you read that? AFAIK git-cvsserver is one option. The other is \ncvsexportcommit. The former is more appropriate if you want to switch the \ndevelopers over to git, and want to provide a smooth path for the devs (or \ncannot convert a few hardcore CVS \"fans\").\n\nThe latter is appropriate if you cannot control the server side, or are \nnot allowed to switch to CVS.\n\n> We have a number of build machines with flamebox perl scripts pulling \n> out CVS branches for builds. I was wondering what is the best way to use \n> git and it's nicer pull/push model and merge facility and possibly \n> maintain CVS exports for scripts doing builds if possible the cvsweb and \n> bonsai (CVS Query Form) that a number of engineers are currently using. \n\nI don't know how cvsweb copes with git-cvsserver, but I guess that there \nwill be no problem.\n\n> I started looking over out flamebox scripts with the intent up \n> converting them over to git but I mentioned the git to cvs coexistence \n> and we are wondering if that's a better route than upgrading the \n> flamebox scripts. Having our existing cvsweb, bonsai, and gitweb along \n> with the git utilities seems at least desirable. Any thoughts or \n> suggestions?\n\nMy suggestion: if you're fine with CVS, stick with it. Really. I am not \nhere to teach the whole world about the advantages of git, so by all \nmeans, if you yourself do not find any advantage to using git, don't use \nit. Stick with what works for you.\n\nCiao,\nDscho\n"},{"id":"56450","messageId":"4717F8CF.9060103@bluelane.com","threadId":"8948","inReplyTo":"Pine.LNX.4.64.0710190054570.25221@racer.site","subject":"Re: Qgit performance and maintain CVS environment with GIT repository","fromName":"Pete/Piet Delaney","fromEmail":"pete@bluelane.com","sentAt":"2007-10-19T00:22:39Z","receivedAt":"2007-10-19T00:22:39Z","isPatch":false,"sender":{"key":"pete@bluelane.com","avatar":null},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nJohannes Schindelin wrote:\n> Hi,\n> \n> On Thu, 18 Oct 2007, Pete/Piet Delaney wrote:\n> \n>> Johannes:\n>> I read somewhere in the past week that it was possible to maintain\n>> our existing CVS environment with git. I though it was a separate\n>> package to export git back to cvs but I just noticed a git-cvsserver\n>> and as a std part of git and was wondering about using that.\n> \n> Where did you read that?\nDon't recall exactly, I thought it was a page like the one showing\ngit Related tools but didn't find it today when looking for it.\n\n\n\n> AFAIK git-cvsserver is one option. The other is \n> cvsexportcommit. The former is more appropriate if you want to switch the \n> developers over to git, and want to provide a smooth path for the devs (or \n> cannot convert a few hardcore CVS \"fans\").\n> \n> The latter is appropriate if you cannot control the server side, or are \n> not allowed to switch to CVS.\n\nI've got root access on the CVS server and want to switch to git without\ndisturbing the environment more than is necessary to make the switch.\nI think developers will want to us git and git-cvsserver looks like\nthe more likely desirable path.\n\n> \n>> We have a number of build machines with flamebox perl scripts pulling \n>> out CVS branches for builds. I was wondering what is the best way to use \n>> git and it's nicer pull/push model and merge facility and possibly \n>> maintain CVS exports for scripts doing builds if possible the cvsweb and \n>> bonsai (CVS Query Form) that a number of engineers are currently using. \n> \n> I don't know how cvsweb copes with git-cvsserver, but I guess that there \n> will be no problem.\ngreat.\n\n> \n>> I started looking over out flamebox scripts with the intent up \n>> converting them over to git but I mentioned the git to cvs coexistence \n>> and we are wondering if that's a better route than upgrading the \n>> flamebox scripts. Having our existing cvsweb, bonsai, and gitweb along \n>> with the git utilities seems at least desirable. Any thoughts or \n>> suggestions?\n> \n> My suggestion: if you're fine with CVS, stick with it. Really. I am not \n> here to teach the whole world about the advantages of git, so by all \n> means, if you yourself do not find any advantage to using git, don't use \n> it. Stick with what works for you.\n\nWe are definitely not fine with CVS, the branch merging isn't\ncomfortable. I'm just wondering about maintaining the existing\nCVS browsers and the build scripts if it's not a big deal. I'll\ntry the git-cvsserver path. If anyone has any war stories to share\non the path this would be an ideal time to share them.\n\n- -piet\n\n\n> \n> Ciao,\n> Dscho\n> \n\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.7 (GNU/Linux)\nComment: Using GnuPG with Mozilla - http://enigmail.mozdev.org\n\niD8DBQFHF/jPJICwm/rv3hoRAkXgAJ9pa/DHxka926i3FHqYTsxCb5kzcQCeKiSk\nj/Paxc6tJemOPK0TV8MhFGs=\n=ut2Q\n-----END PGP SIGNATURE-----\n"},{"id":"56453","messageId":"20071019004159.GB3290@coredump.intra.peff.net","threadId":"8948","inReplyTo":"4717F8CF.9060103@bluelane.com","subject":"Re: Qgit performance and maintain CVS environment with GIT repository","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-10-19T00:41:59Z","receivedAt":"2007-10-19T00:41:59Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Oct 18, 2007 at 05:22:39PM -0700, Pete/Piet Delaney wrote:\n\n> I've got root access on the CVS server and want to switch to git without\n> disturbing the environment more than is necessary to make the switch.\n> I think developers will want to us git and git-cvsserver looks like\n> the more likely desirable path.\n\nDepending on the environment and the willingness of people to change to\ngit, it might be worth moving slowly and keeping the backend as CVS at\nfirst. I.e., keep the \"official\" repository as CVS, and let some devs\nstart moving to access through git-cvsimport and git-cvsexportcommit\n(and maybe even provide an official git repo which is backed by the CVS\nrepo, so that all of the import/export happens in one place). That will\ngive them time to get used to git, give those who are resistant to the\nchange their original interface, and if anything goes wrong, you can\nalways fall back to the \"old\" way.\n\nAnd then when everything seems to be going well, swap it. Make git the\nofficial repo, but provide a \"legacy\" CVS access for the die-hards\n(using git-cvsserver).\n\nAnd then eventually just shut off CVS access entirely (when everyone is\nhappier using git).\n\nOf course none of that is necessary, but one of the nice things about\ngit is how it can integrate with existing setups, so you can really ease\ninto a transition without investing a lot of resources.\n\n-Peff\n"},{"id":"56456","messageId":"Pine.LNX.4.64.0710190125230.25221@racer.site","threadId":"8948","inReplyTo":"4717F8CF.9060103@bluelane.com","subject":"Re: Qgit performance and maintain CVS environment with GIT repository","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-19T00:50:25Z","receivedAt":"2007-10-19T00:50:25Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 18 Oct 2007, Pete/Piet Delaney wrote:\n\n> I'll try the git-cvsserver path. If anyone has any war stories to share \n> on the path this would be an ideal time to share them.\n\nI was responsible for a medium long running CVS repository, and I wanted \nto switch to git. For a long time, I just ran tests and tried to flesh \nout things, and eventually went for it.\n\nA few of the patches to git-cvsserver from me were direct results of \nproblems we ran to. But mind you, that was almost over a year ago.\n\nIn the meantime, many of my developers switched. Some because it was \neasier than waiting for me to fix the bugs with the cvs server.\n\nSome because they saw me working with git.\n\nI still do not know why the third group switched.\n\nNow I have exactly one dev left, who refuses to use anything else than \ncvs. Fine with me. I can live with other people using inferiour programs \nthan myself.\n\nI even patched cvsserver not to print the \"committed using git-cvsserver\" \nmessage locally.\n\nBut then, I was never a cvs \"power\" user. Only a git power user.\n\nCiao,\nDscho\n"},{"id":"56529","messageId":"4718594A.2070407@op5.se","threadId":"8948","inReplyTo":"4717EF40.6000509@bluelane.com","subject":"Re: Qgit performance and maintain CVS environment with GIT repository","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-10-19T07:14:18Z","receivedAt":"2007-10-19T07:14:18Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Pete/Piet Delaney wrote:\n> Johannes:\n> I read somewhere in the past week that it was possible to maintain\n> our existing CVS environment with git. I though it was a separate\n> package to export git back to cvs but I just noticed a git-cvsserver\n> and as a std part of git and was wondering about using that.\n> \n> We have a number of build machines with flamebox perl scripts pulling\n> out CVS branches for builds. I was wondering what is the best way to\n> use git and it's nicer pull/push model and merge facility and possibly\n> maintain CVS exports for scripts doing builds if possible the cvsweb\n> and bonsai (CVS Query Form) that a number of engineers are currently\n> using. I started looking over out flamebox scripts with the intent\n> up converting them over to git but I mentioned the git to cvs\n> coexistence and we are wondering if that's a better route than\n> upgrading the flamebox scripts. Having our existing cvsweb, bonsai,\n> and gitweb along with the git utilities seems at least desirable.\n> Any thoughts or suggestions?\n> \n\nIf you do convert them to git, you can fairly easily do an automatic\nbisect on build-errors, and the developer can (after some time) get\nan email of what machines they broke the code on and what the bad\ncommit was.\n\nBesides that, it's not a black-and-white scenario. If I were you I'd set\nup git-cvsserver and make sure that works for all the scripts, and then\npick one or two auto-build things to convert to git. Preferrably on a\nseparate machine, so everything keeps working the same as always while\nyou're fiddling with the auto-build stuff.\n\nJust my two cents.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"56534","messageId":"200710190943.45201.wielemak@science.uva.nl","threadId":"8948","inReplyTo":"4717F8CF.9060103@bluelane.com","subject":"Re: Qgit performance and maintain CVS environment with GIT repository","fromName":"Jan Wielemaker","fromEmail":"wielemak@science.uva.nl","sentAt":"2007-10-19T07:43:44Z","receivedAt":"2007-10-19T07:43:44Z","isPatch":false,"sender":{"key":"wielemak@science.uva.nl","avatar":null},"body":"On Friday 19 October 2007 02:22, Pete/Piet Delaney wrote:\n> We are definitely not fine with CVS, the branch merging isn't\n> comfortable. I'm just wondering about maintaining the existing\n> CVS browsers and the build scripts if it's not a big deal. I'll\n> try the git-cvsserver path. If anyone has any war stories to share\n> on the path this would be an ideal time to share them.\n\nAs for web browsing the history, our project was quickly convinced\ngitweb is a lot better than cvsweb. We are starting to get use to\nbasic git. One developer works on CVS. This is a bit handicapped,\nbut workable after a few patches to git-shell and git-cvsserver.\n\nIn another project I use git-cvsserver to do the Windows builds.\nAll development except for minor typos and compatibility things is\ndone on linux and cvs <-> git works just fine for that model.\n\n\t--- Jan\n"},{"id":"56547","messageId":"471871BD.7030608@bluelane.com","threadId":"8948","inReplyTo":"200710190943.45201.wielemak@science.uva.nl","subject":"Re: Qgit performance and maintain CVS environment with GIT repository","fromName":"Pete/Piet Delaney","fromEmail":"pete@bluelane.com","sentAt":"2007-10-19T08:58:37Z","receivedAt":"2007-10-19T08:58:37Z","isPatch":false,"sender":{"key":"pete@bluelane.com","avatar":null},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nJan Wielemaker wrote:\n> On Friday 19 October 2007 02:22, Pete/Piet Delaney wrote:\n>> We are definitely not fine with CVS, the branch merging isn't\n>> comfortable. I'm just wondering about maintaining the existing\n>> CVS browsers and the build scripts if it's not a big deal. I'll\n>> try the git-cvsserver path. If anyone has any war stories to share\n>> on the path this would be an ideal time to share them.\n> \n> As for web browsing the history, our project was quickly convinced\n> gitweb is a lot better than cvsweb. We are starting to get use to\n> basic git. One developer works on CVS. This is a bit handicapped,\n> but workable after a few patches to git-shell and git-cvsserver.\n\nCould you tell me a bit more about those patches and the need for using\ngit-shell (haven't even messed with that yet).\n\nThink I can set things up so the CVS updates, checkouts, and the\nlike that are being used on our build machines can remain untouched\nand have the git-cvsserver exactly acting like the current CVS server.\nIt would be nice if branches and tags work without touching all of the\nbuild machines and their scripts.\n\nI don't think we need to have any developers continuing to use CVS;\nbut I may be wrong. I think I read that there's a limitation to being\non the main branch and unfortunately most of out tags are on a release\nbranch.\n\n- -piet\n\n> \n> In another project I use git-cvsserver to do the Windows builds.\n> All development except for minor typos and compatibility things is\n> done on linux and cvs <-> git works just fine for that model.\n> \n> \t--- Jan\n> \n\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.7 (GNU/Linux)\nComment: Using GnuPG with Mozilla - http://enigmail.mozdev.org\n\niD8DBQFHGHG9JICwm/rv3hoRApQIAJ0Ys6QwxnBAu9tNWrGLU9svwtYXZwCeIFlq\nYr8snPT8TW/nBxFygFr95Ik=\n=MtJS\n-----END PGP SIGNATURE-----\n"},{"id":"56550","messageId":"47187518.1090007@bluelane.com","threadId":"8948","inReplyTo":"4718594A.2070407@op5.se","subject":"Re: Qgit performance and maintain CVS environment with GIT repository","fromName":"Pete/Piet Delaney","fromEmail":"pete@bluelane.com","sentAt":"2007-10-19T09:12:56Z","receivedAt":"2007-10-19T09:12:56Z","isPatch":false,"sender":{"key":"pete@bluelane.com","avatar":null},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nAndreas Ericsson wrote:\n> Pete/Piet Delaney wrote:\n>> Johannes:\n>> I read somewhere in the past week that it was possible to maintain\n>> our existing CVS environment with git. I though it was a separate\n>> package to export git back to cvs but I just noticed a git-cvsserver\n>> and as a std part of git and was wondering about using that.\n>>\n>> We have a number of build machines with flamebox perl scripts pulling\n>> out CVS branches for builds. I was wondering what is the best way to\n>> use git and it's nicer pull/push model and merge facility and possibly\n>> maintain CVS exports for scripts doing builds if possible the cvsweb\n>> and bonsai (CVS Query Form) that a number of engineers are currently\n>> using. I started looking over out flamebox scripts with the intent\n>> up converting them over to git but I mentioned the git to cvs\n>> coexistence and we are wondering if that's a better route than\n>> upgrading the flamebox scripts. Having our existing cvsweb, bonsai,\n>> and gitweb along with the git utilities seems at least desirable.\n>> Any thoughts or suggestions?\n>>\n> \n> If you do convert them to git, you can fairly easily do an automatic\n> bisect on build-errors, and the developer can (after some time) get\n> an email of what machines they broke the code on and what the bad\n> commit was.\n\nCould you explain that a bit more. Sounds like you saying it's worth\nmessing with the flamebox scripts to use git instead of using the git\ncvserver and letting them pull the cvs branches as they do now. Is the\nexisting flamebox email of build log effected buy switching form cvs\nto git? I hadn't expect it to change.\n\n\n> Besides that, it's not a black-and-white scenario. If I were you I'd set\n> up git-cvsserver and make sure that works for all the scripts, and then\n> pick one or two auto-build things to convert to git. Preferrably on a\n> separate machine, so everything keeps working the same as always while\n> you're fiddling with the auto-build stuff.\n\nI get the impression your suggestion to first get git-cvsserver serving\nthe repo so that the build machines works without any change and then to\ngo to each build machine and update the scripts to use git instead of cvs.\n\nAre there any tricks I need to so on the repo to make the branches pull\nout with exactly the same commands that we are currently using. My guess\nis that the branch checkouts should work without any messing around.\n> \n> Just my two cents.\n\nHey, you two cents could easily save me hours of messing getting this\nconversion done.\n\nBTW, I don't think anyone is checking into the repo, but if they do\ncan I do another git-cvsimport to just update the one I already did?\n\n- -piet\n\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.7 (GNU/Linux)\nComment: Using GnuPG with Mozilla - http://enigmail.mozdev.org\n\niD8DBQFHGHUUJICwm/rv3hoRArHsAJ9GQMjpLc5CzpBXnHkxLfBgfwEo/QCdGNfj\nDiivgfDDSbIB+9YBZvj/5Z0=\n=SBSg\n-----END PGP SIGNATURE-----\n"},{"id":"56551","messageId":"47187E4E.50006@op5.se","threadId":"8948","inReplyTo":"47187518.1090007@bluelane.com","subject":"Re: Qgit performance and maintain CVS environment with GIT repository","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-10-19T09:52:14Z","receivedAt":"2007-10-19T09:52:14Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Pete/Piet Delaney wrote:\n> -----BEGIN PGP SIGNED MESSAGE-----\n> Hash: SHA1\n> \n> Andreas Ericsson wrote:\n>> Pete/Piet Delaney wrote:\n>>> Johannes:\n>>> I read somewhere in the past week that it was possible to maintain\n>>> our existing CVS environment with git. I though it was a separate\n>>> package to export git back to cvs but I just noticed a git-cvsserver\n>>> and as a std part of git and was wondering about using that.\n>>>\n>>> We have a number of build machines with flamebox perl scripts pulling\n>>> out CVS branches for builds. I was wondering what is the best way to\n>>> use git and it's nicer pull/push model and merge facility and possibly\n>>> maintain CVS exports for scripts doing builds if possible the cvsweb\n>>> and bonsai (CVS Query Form) that a number of engineers are currently\n>>> using. I started looking over out flamebox scripts with the intent\n>>> up converting them over to git but I mentioned the git to cvs\n>>> coexistence and we are wondering if that's a better route than\n>>> upgrading the flamebox scripts. Having our existing cvsweb, bonsai,\n>>> and gitweb along with the git utilities seems at least desirable.\n>>> Any thoughts or suggestions?\n>>>\n>> If you do convert them to git, you can fairly easily do an automatic\n>> bisect on build-errors, and the developer can (after some time) get\n>> an email of what machines they broke the code on and what the bad\n>> commit was.\n> \n> Could you explain that a bit more. Sounds like you saying it's worth\n> messing with the flamebox scripts to use git instead of using the git\n> cvserver and letting them pull the cvs branches as they do now. Is the\n> existing flamebox email of build log effected buy switching form cvs\n> to git? I hadn't expect it to change.\n> \n\ngit has quite a wonderful tool named git-bisect. In short, it helps track\ndown what particular commit introduced a bug. Let's say your builds fail\nfor some reason, and the build-scripts send out the build-log to the\ndeveloper. The script can then continue to check the repo by running git\nbisect on it and finding the commit that introduced the build-error, and\nemail that too to the developer. In short, when you check things in at\n5 o'clock that doesn't build, you don't have to sit there and wrestle with\nit. You can go home, have dinner, tuck the kids into bed, and then open\nyour mailbox and have an email with the exact commit that introduced the\nregression.\n\nNow, if you can also convince your developers to make small and isolated\ncommits, and your build-system is such that it doesn't rebuild *everything*,\nbut has proper dependency tracking and suchlike (a properly written Makefile\nfor example), the developer will get pointed to a commit that affects perhaps\n10-20 lines of code within a reasonable time, and it should be so trivial to\nfix that anyone can do it.\n\n> \n>> Besides that, it's not a black-and-white scenario. If I were you I'd set\n>> up git-cvsserver and make sure that works for all the scripts, and then\n>> pick one or two auto-build things to convert to git. Preferrably on a\n>> separate machine, so everything keeps working the same as always while\n>> you're fiddling with the auto-build stuff.\n> \n> I get the impression your suggestion to first get git-cvsserver serving\n> the repo so that the build machines works without any change and then to\n> go to each build machine and update the scripts to use git instead of cvs.\n> \n\nThat's the idea, yes.\n\n> Are there any tricks I need to so on the repo to make the branches pull\n> out with exactly the same commands that we are currently using. My guess\n> is that the branch checkouts should work without any messing around.\n\nI'm not sure what you mean by that. You can tell git to automatically fetch\nany new branches (that's the default, I think), but you'll ofcourse have to\nswitch to using git-pull instead of cvs co (or whatever you're using now),\nunless you use git-cvsserver. AFAIK, git-cvsserver mimics a cvs server well\nenough that it accepts all commands and the two are interchangeable (assuming\nthe background repo conversion has been done, ofcourse).\n\n>> Just my two cents.\n> \n> Hey, you two cents could easily save me hours of messing getting this\n> conversion done.\n> \n\nThat's well-invested money then ;-)\n\n> BTW, I don't think anyone is checking into the repo, but if they do\n> can I do another git-cvsimport to just update the one I already did?\n\nYes. It works incrementally, but since cvs commits aren't atomic, you\nhave to wait 10 minutes after the cvs commit *starts* to be able to\nuse cvsimport to move it over to git.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"56555","messageId":"200710191234.47944.wielemak@science.uva.nl","threadId":"8948","inReplyTo":"471871BD.7030608@bluelane.com","subject":"Re: Qgit performance and maintain CVS environment with GIT repository","fromName":"Jan Wielemaker","fromEmail":"wielemak@science.uva.nl","sentAt":"2007-10-19T10:34:47Z","receivedAt":"2007-10-19T10:34:47Z","isPatch":false,"sender":{"key":"wielemak@science.uva.nl","avatar":null},"body":"On Friday 19 October 2007 10:58, Pete/Piet Delaney wrote:\n> Jan Wielemaker wrote:\n> > On Friday 19 October 2007 02:22, Pete/Piet Delaney wrote:\n> >> We are definitely not fine with CVS, the branch merging isn't\n> >> comfortable. I'm just wondering about maintaining the existing\n> >> CVS browsers and the build scripts if it's not a big deal. I'll\n> >> try the git-cvsserver path. If anyone has any war stories to share\n> >> on the path this would be an ideal time to share them.\n> >\n> > As for web browsing the history, our project was quickly convinced\n> > gitweb is a lot better than cvsweb. We are starting to get use to\n> > basic git. One developer works on CVS. This is a bit handicapped,\n> > but workable after a few patches to git-shell and git-cvsserver.\n>\n> Could you tell me a bit more about those patches and the need for using\n> git-shell (haven't even messed with that yet).\n\nOne patch concerned handling \"cvs update -p\", which was accepted and I\nguess will end up in the stable version someday. One concerned handling\n\"cvs diff -c\", which I never submitted. I first tried a more general\napproach to get diff option processing complete, but I had to backtrack\non that. Now I have a quite simple hack, but more complete coverage of\ndiff option processing requires a bit more perl knowledge than I have.\n\nI submitted a patch for shell.c to make it call \"git cvsserver server\"\nif a commandline \"cvs server\" was passed to it, so you can do CVS+SSH\ncompatible to normal CVS. I got so many comments I decided to keep it\nfor myself for now.\n\n> I don't think we need to have any developers continuing to use CVS;\n> but I may be wrong. I think I read that there's a limitation to being\n> on the main branch and unfortunately most of out tags are on a release\n> branch.\n\nNo, you can checkout any GIT branch as it it were a CVS module.\n\n\t--- Jan\n"},{"id":"58520","messageId":"Pine.LNX.4.64.0711061050060.4362@racer.site","threadId":"8948","inReplyTo":"47303826.1000506@bluelane.com","subject":"Re: git push problem - unpack unpacker exited with error code; ng refs/heads/rel2_branch n/a (unpacker error)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-06T10:51:49Z","receivedAt":"2007-11-06T10:51:49Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 6 Nov 2007, Piet Delaney wrote:\n\n> I'm getting an error when I try to push back a git repository\n> that I just pulled and made a slight change to:\n> -------------------------------------------------------------------------------------\n> -bash-3.00$ git push\n> [...]\n> error: failed to push to 'git://cvs.bluelane.com/home/git/blux'\n\nFor security reasons, you cannot push to git://, by default. git:// does \nnot have any form of authentication or encryption.\n\nYou need to use the ssh protocol (probably something like \ncvs.bluelane.com:/home/git/blux in your case).\n\nCiao,\nDscho\n"}]}