A Git Repository for Code::Blocks (ONLY trunk)

[Loaden]

Hi, All, I am created a git repository for Code::Blocks.
Until now It's only include trunk, from rev1~rev7094 :
https://www.gitorious.org/codeblocks/

Step 1:
git clone git://gitorious.org/codeblocks/codeblocks.git CodeBlocks

Step 2:
git config svn-remote.svn.url http://svn.berlios.de/svnroot/repos/codeblocks
git config svn-remote.svn.fetch trunk:refs/remotes/trunk
You can change the url as you want. ^_^

Step 3:
Unzip the svn.7z, and put it on CodeBlocks/.git directory.
http://portablecb.googlecode.com/files/svn.7z

Step 4:
git svn fetch
git svn rebase

Enjoy!

If somebody has better way, please let's me know, thanks!!

[killerbot]

what's the purpose ?

[Loaden]

what's the purpose ?

http://www.whygitisbetterthanx.com/

[oBFusCATed]

Does it work OK/reliably on windows?

[killerbot]

what's the purpose ?

http://www.whygitisbetterthanx.com/

well we can also come up with reasons why it is not better ;-)

Main thing to think about : what is currently blocking us with svn, and as such needs to be solved asap.

[Loaden]

Does it work OK/reliably on windows?

Yes, It's works well.
http://code.google.com/p/msysgit/

[Loaden]

Main thing to think about : what is currently blocking us with svn, and as such needs to be solved asap.

SVN for CB works well until now.
I created this repository, just because I like Git.
Especially:
1. Cheap Local Branching
2. Everything is Local

[killerbot]

Does it work OK/reliably on windows?

Yes, It's works well.
http://code.google.com/p/msysgit/

From what I remember a year ago the GUI tools were really awful and ugly (old tcl/tk stuff look and feel from in the early 90's) [and they were not stable].

Personally I really missed the version tree. The spaghetti tree of git is just too confusing to me. Nothing like a real nice version tree per file. But maybe this exists in the meantime ?

[oBFusCATed]

Git is made to be used from the console and it is way better then svn+console.

I've tried git-svn when I started work on the debugger's branch and it was good until the point where I've to generate the patches.
I should try it again to see if committing works

What is version tree?

[killerbot]

a version tree, is a graphical tree *per element (file/directory)* that shows you the revisions in a tree model. You can click on the node for comparison, to see the chane commit messages.
basically a nice graphical overview on what has happened to a certain file. branching is also visible in the tree (a tree has native support for branches ;-) ), and so on

[Loaden]

I've tried git-svn when I started work on the debugger's branch and it was good until the point where I've to generate the patches.

You can use gitk to make a patch. In first, you need commit in a branch.

[oBFusCATed]

I can make patches with the cmd line tools and I've done so.
The problem was that the generated patch was broken (not applicable), because of the $rev/$author variables used in C::B sources.


p.s. This are pretty useless by the way (probably only for the SDK headers), svn blame is way better...

[Biplab]

Does it work OK/reliably on windows?

Yes, It's works well.
http://code.google.com/p/msysgit/

From what I remember a year ago the GUI tools were really awful and ugly (old tcl/tk stuff look and feel from in the early 90's) [and they were not stable].

You can use TortoiseGIT+msys-git combination. They are as good as TortoiseSVN.

[killerbot]

is there also something similar like kdesvn ?

[Biplab]

is there also something similar like kdesvn ?

Not sure which feature you are looking for.

[billyonthemountain]

is there also something similar like kdesvn ?

I'd suggest qgit... based on QT4

[ollydbg]

Are there any update git repos I can use?
Is it possible to setup a read-only git repo in the berliOS?
I'm working on Windows, and TortoiseGit + msysgit combination works quite well. (I use git to handle GDB source, it works quite well)
The only thing I hate svn is that when I try to find the code changes between some old revisions, I need to wait the svn to fetch those revisions files from the internet, that was extremely slow, it always take several seconds or event more seconds.

[daniloz]

Sorry to hijack an old thread, but I really think this belongs here and not somewhere else... ;-)

I started yesterday using GIT here and I'm already loving it... Local branching is so cool...

I have "imported" the SVN from codeblocks into a local GIT repo. I have made some changes and committed them to my local GIT.

My question is now: How can I see the differences between my local copy and codeblocks' SVN HEAD?

Thx,

[oBFusCATed]

I guess it depends on the method you use to get the svn repo in git.
Depending on this you should read the correct manual, I guess there you'll find something about this.
As far as I know you should do rebase if you want to get the changes in the svn repo.
And if you do rebase I guess the changes from the first commit to the last are your changes.
But I may be wrong. I've used git-svn once long time ago and I didn't import the whole repo in git.

How long does it take to import the whole repo with the history?

[daniloz]

I guess it depends on the method you use to get the svn repo in git.
Depending on this you should read the correct manual, I guess there you'll find something about this.

What I did was

Code

git svn clone -s http://svn.berlios.de/svnroot/repos/codeblocks local_dir

and yes, I got the complete history. I can got back to the "big bang" of codeblocks... 
But I haven't found anything in the git-svn manual about this...

How long does it take to import the whole repo with the history?

Hmmm.... I was in a meeting, so quite not sure, but in the range of one to two hours.

As far as I know you should do rebase if you want to get the changes in the svn repo.

Yes, I read that as well, I can rebase to get the svn updated (like an svn update). Haven't tried yet, because there are no new changes on the svn, but will report on that as soon as possible.

And if you do rebase I guess the changes from the first commit to the last are your changes.

Sorry, I couldn't follow you here. You mean from my first commit to the local GIT repo to my last commit?

[oBFusCATed]

Sorry, I couldn't follow you here. You mean from my first commit to the local GIT repo to my last commit?

Yes, something like that. As far as I know rebasing means that all your commits are reverted the commits from svn are applied and then your commits are applied again.
So, I guess this are the steps needed. Btw it is possible to convert all commits to patches with a single command.

[daniloz]

So, I guess this are the steps needed. Btw it is possible to convert all commits to patches with a single command.

And the command would be? :-)

[oBFusCATed]

RTFM, I don't remember... 

[Jenna]

I just started to use git-svn since some weeks and it works fine for me.

To create a diff on the commandline, you can use:

Code

git diff-tree -m -p --pretty <commit>

where <commit> is the id of the commit, you can get it with git log .

There are many other options, look into git help diff-tree .

The diffs are not usable by tortoise svn, but there is a a python-script, that can convert it on https://www.seegrid.csiro.au/wiki/Infosrvices/GeoserverGit

On linux I suggest using gitk or gitg and of course git gui .

[zabzonk]

If you want to play with git-svn, but can't face downloading the whole CB history, you can just clone a particular SVN revision, which will give you something you can work on inside a few minutes as opposed to a few hours for the whole shebang. For example:

Code

git svn clone -r7548 svn://svn.berlios.de/codeblocks/trunk

creates a local git repository containing the code for SVN revision 7548.

[thomas]

You can use TortoiseGIT+msys-git combination. They are as good as TortoiseSVN.

That, Sir, is the biggest lie of the century. Nice try, though     (I can't believe I only saw that one today, hehehe.)

TortoiseSVN installs in around 10 seconds and works perfectly well even if you don't know a single thing about version control. If you can read English, and know how to hold a mouse, you're good to go.

With TortoiseGit, I run into annoyances and problems doing trivial things like committing or reverting almost every single time.

Furthermore, msys-git takes almost an hour to install and requires a truly ridiculous amount of harddisk space. Someone who distributes a "little commandline tool" that weights on the order of hundreds of megabytes got something seriously wrong.

[zabzonk]

@thomas I agree about tortoise-git - not a patch on  TortoiseSVN, and rather buggy. However:

> Furthermore, msys-git takes almost an hour to install

Say what? I've installed it a couple of times, and I'd say 10 minutes at the very, very outside. However, the bash shell that comes with it is  extremely slow unless you run it as administrator. But I've found its more or less impossible to do development work on Win7 unless you run as admin, so its not a big deal for me.

[daniloz]

@thomas Also agree that tortoiseGit + msysGit is quite buggy and not really ready for show time. I think that the whole git thing was developed for command line and it's rather difficult to put it in a GUI. I still think that using git gui & gitk in addition to command line git is way better than tortoiseGit, IMHO.

Even though I'm using git for not less than a week now, I'm already in love with its capabilities, mainly cheap local branching and local/distributed repositories.

Just my 2 cents... ;-)

[MortenMacFly]

Furthermore, msys-git takes almost an hour to install and requires a truly ridiculous amount of harddisk space. Someone who distributes a "little commandline tool" that weights on the order of hundreds of megabytes got something seriously wrong.

I am using portable GIT (http://code.google.com/p/msysgit/downloads/detail?name=PortableGit-1.7.7.1-preview20111027.7z&can=2&q=) which you only need to decompress and then it works. In combination with SmartGIT (you guys know meanwhile I love their tools ;-)) it's quite powerful, even the SVN/GIT integration. It offers a very easy way to get a GIT repo out of a SVN repo.

But I have to agree with Thomas: I was really surprised how big GIT is - I was hoping to find at least a UI tool like the one shipping with Mercurial, but no luck.

[zabzonk]

> I was hoping to find at least a UI tool like the one shipping with Mercurial,

Mercurial does not ship with a GUI - TortoiseHg is a separate project. And in fact msys-git does ship with a (not very good) GUI try:

Code

git help gui

for details.

[reckless]

Hmm true git's gui is tcl and while not the most advanced it does what it needs to but needs a bash shell to work, qgit might be a better alternative though it lacks some documentation.
Git can be build with mingw as a true win32 application but there are some downfalls like getting svn integration to work.
I got a win32 build you can test if you want ? (it uses qgit gui svn support is not in yet) it works with standard git repositories though.
Its also a lot smaller than msys-git.

[zabzonk]

>Git can be build with mingw as a true win32 application but there are some downfalls like getting svn integration to work.

msys-git is a "true win32 application", and svn integration via "git svn" works perfectly.

[MortenMacFly]

Mercurial does not ship with a GUI - TortoiseHg is a separate project.

Oh, mine does - it's a TCL/TK based UI and shows the revision tree, differences and stuff like that.Though it's really hidden in the sub-folders of the Windows installation.  I don't mean TortoiseXXX. Such things are of no help for me as I never use the explorer.

[reckless]

msys-git is a "true win32 application", and svn integration via "git svn" works perfectly.

I mean it relies on a posix layer (msys-1.0.dll) the mingw one only needs what dll's are allready on windows + a few things like curl.
Im working on getting the tcl gui to use the windows tclsh directly instead of through bash.
Msys-git works fine no argument there its just a little large so im trying to cut some fat.

[daniloz]

Another question here...

How do I use a patch generated by SVN on my local git svn ?

[oBFusCATed]

Apply it with the patch command and then commit it in your local branch with patches.

[daniloz]

Apply it with the patch command and then commit it in your local branch with patches.

That's what I was trying to do, but I got the following error message

Code

can't find file to patch at input line 5
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|Index: src/sdk/editorconfigurationdlg.cpp
|===================================================================
|--- src/sdk/editorconfigurationdlg.cpp (revision 7595)
|+++ src/sdk/editorconfigurationdlg.cpp (working copy)
--------------------------
File to patch:

That's my command

Code

$ patch -i /...path.../BraceCompletionSelectedText.patch

[Jenna]

Apply it with the patch command and then commit it in your local branch with patches.

That's what I was trying to do, but I got the following error message

Code

can't find file to patch at input line 5
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|Index: src/sdk/editorconfigurationdlg.cpp
|===================================================================
|--- src/sdk/editorconfigurationdlg.cpp (revision 7595)
|+++ src/sdk/editorconfigurationdlg.cpp (working copy)
--------------------------
File to patch:

That's my command

Code

$ patch -i /...path.../BraceCompletionSelectedText.patch

If you are inside the git's root level, you need most likely the -p0 (or -p1) parameter, and I suggest to always use --dry-run as first to test what would happen, without breaking anything.

[daniloz]

If you are inside the git's root level, you need most likely the -p0 (or -p1) parameter, and I suggest to always use --dry-run as first to test what would happen, without breaking anything.

Thanks jens, the switch -p0 did the trick and I could apply the patch...

[ollydbg]

There is some new discussion of git. see:
Re: Integrate the nativeparser_base to our parsertest project

Said by Morten:

I have nothing against GIT itself. Just the combination we do here between SVN and GIT. If we all agree we should consider moving towards GIT completely if most of the devs use it anyways. I recall we were discussing this already, just not why we didn't do it (was it the lack of support from BerliOS?!).

I wonder if some of you already did a migration from SVN to GIT. I mean in terms of keep existing branches and (of course) the whole history...?!

I recall the time when I personally migrated from CVS to SVN. It wasn't easy, but doable if you had the right tools at hand.

So, we can discuss this issue here.

[oBFusCATed]

That is true. I have nothing against GIT itself. Just the combination we do here between SVN and GIT. If we all agree we should consider moving towards GIT completely if most of the devs use it anyways. I recall we were discussing this already, just not why we didn't do it (was it the lack of support from BerliOS?!).

I wonder if some of you already did a migration from SVN to GIT. I mean in terms of keep existing branches and (of course) the whole history...?!

I recall the time when I personally migrated from CVS to SVN. It wasn't easy, but doable if you had the right tools at hand.

If there is a voting now, I'd vote for switching to git as it makes open source development a lot easier. (I've only used git-svn, but I'm sure it does).
Switching to git will make it easier to test things and to follow other developers, as everybody can publish their work-in-progress in separate branches.

I'm not sure for the hosting, but github sounds like something useful. There is UI to fork projects, request pulls, social stuff...

[MortenMacFly]

I'm not sure for the hosting, but github sounds like something useful. There is UI to fork projects, request pulls, social stuff...

I think we all now the advantages we could take from GIT. However, I would rather not use a third platform if it isn't really necessary. We don't now how well it will be accessible world-wide and would need to connect this repo to our project pages "somehow".

If BerliOS or SourceForge offer similar functionality (or less, if that is still enough) I clearly vote for those platforms. Also - still most important to me:

I wonder if some of you already did a migration from SVN to GIT. I mean in terms of keep existing branches and (of course) the whole history...?!

[Jenna]

I wonder if some of you already did a migration from SVN to GIT. I mean in terms of keep existing branches and (of course) the whole history...?!

I cloned the whole svn repo with git-svn.
It holds the whole history since commit 1 to HEAD.


It still uses git-svn, so it is not a real git repo, but there exist scripts and many, many guides that help to really switch to git.
I will try it this weekend.

By the way, if I understand it correctly, berlios also offers git since some time:
http://developer.berlios.de/docman/display_doc.php?docid=1812&group_id=2

[oBFusCATed]

I cloned the whole svn repo with git-svn.
It holds the whole history since commit 1 to HEAD.

I think, I've cloned only trunk, but I have the whole history. It took 30-60 minutes.

[MortenMacFly]

By the way, if I understand it correctly, berlios also offers git since some time:

Yes, I know - it just does not have such a "nice" interface like GitHub or alike. But I don't know if we would miss too much.

Concerning the GIT conversion: I would be mostly interested if your branch switching is reflected properly. For example: The last switch between trunk and the CC branch is important as only in the (backed-up) trunk branch the history is until "day 1".

An if conversion is OK - how would we proceed? Convert locally and upload the a whole converted repo via SSH to BerliOS, or does BerliOS / SourceForge itself offer a migration service? Maybe it wise to setup a dummy project and try before...

[Jenna]

By the way, if I understand it correctly, berlios also offers git since some time:

Yes, I know - it just does not have such a "nice" interface like GitHub or alike. But I don't know if we would miss too much.

Concerning the GIT conversion: I would be mostly interested if your branch switching is reflected properly. For example: The last switch between trunk and the CC branch is important as only in the (backed-up) trunk branch the history is until "day 1".

An if conversion is OK - how would we proceed? Convert locally and upload the a whole converted repo via SSH to BerliOS, or does BerliOS / SourceForge itself offer a migration service? Maybe it wise to setup a dummy project and try before...

I guess it is possible to have both repos parrallel, that means switch locally to git, upload and test it, while the svn repo is still available.

I uploaded the history of trunk created with git log --graph --date-order --format=medium to my server : http://apt.jenslody.de/downloads/master_history.7z
The cc-branch merge into trunk is in line 8642.

[oBFusCATed]

As far as I know, there is no way to pull from somebody's git-svn repo and then even if you have svn rights to commit in svn.
There are some remote-repo-tags, which are not preserved after the pull (I'm not 100% sure about this).
And I guess having two repos will be non-productive (if we force a single user to do the git svn dcommit the history will be badly broken).