Since Arty just mentioned GIT, I think it's about time to uncover a ReactOS GIT mirror I've been setting up recent couple of weeks.
It works pretty good so far, autoupdates every 10 minutes, so it stays quite up-to-date.
URLs: git://git.reactos.org/ - for git cloning. http://git.reactos.org - for web viewing.
As for branches, it was actually my main intention in using a DVCS, because SVN branches are greatly uncomfortable to develop anything because of the need to keep the branch up-to-date.
But, to prevent any gossips, SVN stays as our main repository, and GIT mirror is just for exploration of new possibilities, and for comfortability of working with branches - if someone wants to try that out. Usual SVN branches are still permitted.
WBR, Aleksey Bragin.
Hi, All!
On 16:34 Thu 08 Jan , Colin Finck wrote:
Aleksey Bragin wrote:
Since Arty just mentioned GIT, I think it's about time to uncover a ReactOS GIT mirror I've been setting up recent couple of weeks.
The SVN branches are still missing there. Any way to readd them properly? :-)
I have just realized that it's possible! The problem is that the branches in the repository at git://git.reactos.org/ are 'remote branches', i.e. the are situated in .git/refs/remotes/ (even in the "main" repository!). That's a big problem for gitweb, because it only shows the branches in '.git/refs/heads/'.
Solution 1: Make Aleksey tidy up the repo so that it would have the svn branches as its local branches: (in the repo at git://git.reactos.org/) git checkout origin/<branch> git checkout -b local-<branch> # this creates a local branch But there are some issues regarding this solution: 1. it needs 'git pull ...' (frankly, a bit more complex command...) in crontab 2. there could be some problems with ambiguous branch names if you want to exactly keep the names of branches in svn. However, there's a ugly hack: to copy refs from .git/refs/remotes/ to .git/refs/heads (they should be also updated after every svn update)
Solution 2: (to not annoy Aleksey ;) ) This is not a bad solution, it just won't fix gitweb (althought, Aleksey says that branches in gitweb are redundant).
The solution is to fetch branches from .git/refs/remotes/ in the "main" repository too (not only from .git/refs/heads/): add the following line to .git/config in your local repo under "[remote "origin"]" section: fetch = +refs/remotes/*:refs/remotes/origin/* (now there should be two "fetch" lines)
Now, to switch to a branch: (say, "xen") git checkout origin/xen Please note, that origin/xen is a remote branch, you can't do some operations on it (you can't commit AFAIK, ...). So, if you want to start working from the origin/xen branch, you firstly need to create a local branch (Git reminds about that): git checkout -b xen Now you can say 'git branch' to see you brand new branch.
(especially to Aleksey) I really don't know whether it's possible to push the changes back to the svn repo through our Git mirror, but I'm affraid, the answer is "NO!!!". It seems that you should import the svn repo directly to push back into it.
'git checkout' is really painful to write every time, so you can add an alias (to ~/.gitconfig for user-wide alias), I have the following aliases: [alias] br = branch co = checkout ci = commit --verbose # --verbose shows the commit diff when commiting st = status -uall di = diff # I have no idea why is it in my .gitconfig, I don't use it ;)
Best regards,
Colin
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
I really hate this Ros-dev ML ;), there even no information on how to unsubscribe (which may be necessary on LKML ;))
Alexander
Hg. Best regards, Alex Ionescu
On Thu, Jan 8, 2009 at 12:12 PM, Alexander Potashev aspotashev@gmail.comwrote:
Hi, All!
On 16:34 Thu 08 Jan , Colin Finck wrote:
Aleksey Bragin wrote:
Since Arty just mentioned GIT, I think it's about time to uncover a ReactOS GIT mirror I've been setting up recent couple of weeks.
The SVN branches are still missing there. Any way to readd them properly? :-)
I have just realized that it's possible! The problem is that the branches in the repository at git://git.reactos.org/ are 'remote branches', i.e. the are situated in .git/refs/remotes/ (even in the "main" repository!). That's a big problem for gitweb, because it only shows the branches in '.git/refs/heads/'.
Solution 1: Make Aleksey tidy up the repo so that it would have the svn branches as its local branches: (in the repo at git://git.reactos.org/) git checkout origin/<branch> git checkout -b local-<branch> # this creates a local branch But there are some issues regarding this solution: 1. it needs 'git pull ...' (frankly, a bit more complex command...) in crontab 2. there could be some problems with ambiguous branch names if you want to exactly keep the names of branches in svn. However, there's a ugly hack: to copy refs from .git/refs/remotes/ to .git/refs/heads (they should be also updated after every svn update)
Solution 2: (to not annoy Aleksey ;) ) This is not a bad solution, it just won't fix gitweb (althought, Aleksey says that branches in gitweb are redundant).
The solution is to fetch branches from .git/refs/remotes/ in the "main" repository too (not only from .git/refs/heads/): add the following line to .git/config in your local repo under "[remote "origin"]" section: fetch = +refs/remotes/*:refs/remotes/origin/* (now there should be two "fetch" lines) Now, to switch to a branch: (say, "xen") git checkout origin/xen Please note, that origin/xen is a remote branch, you can't do some operations on it (you can't commit AFAIK, ...). So, if you want to start working from the origin/xen branch, you firstly need to create a local branch (Git reminds about that): git checkout -b xen Now you can say 'git branch' to see you brand new branch.(especially to Aleksey) I really don't know whether it's possible to push the changes back to the svn repo through our Git mirror, but I'm affraid, the answer is "NO!!!". It seems that you should import the svn repo directly to push back into it.
'git checkout' is really painful to write every time, so you can add an alias (to ~/.gitconfig for user-wide alias), I have the following aliases: [alias] br = branch co = checkout ci = commit --verbose # --verbose shows the commit diff when commiting st = status -uall di = diff # I have no idea why is it in my .gitconfig, I don't use it ;)
Best regards,
Colin
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
I really hate this Ros-dev ML ;), there even no information on how to unsubscribe (which may be necessary on LKML ;))
Alexander
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Mercurial, indeed
Date: Thu, 8 Jan 2009 22:54:50 +0300 From: aspotashev@gmail.com To: ros-dev@reactos.org Subject: Re: [ros-dev] GIT mirror
What does "Hg" mean? "Hot Girl", "High Grade" (marijuana), "Highly gifted" or after all Mercurial?
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
_________________________________________________________________ Téléphonez gratuitement à tous vos proches avec Windows Live Messenger ! Téléchargez-le maintenant ! http://www.windowslive.fr/messenger/1.asp
This is a good article that covers many of my feelings about git: http://texagon.blogspot.com/2008/02/use-mercurial-you-git.html
Poor Windows support, VS2008 integration, crappy GUIs, shitload of binaries being installed, and confusing, complex commands which encourage messing with history, doing "ammends" to commits and other weird actions make git a totally bad choice for ReactOS development.
Best regards, Alex Ionescu
2009/1/8 Pierre SCHWEITZER heis_spiter@hotmail.com
Mercurial, indeed
Date: Thu, 8 Jan 2009 22:54:50 +0300 From: aspotashev@gmail.com To: ros-dev@reactos.org Subject: Re: [ros-dev] GIT mirror
What does "Hg" mean? "Hot Girl", "High Grade" (marijuana), "Highly gifted" or after all Mercurial?
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Discutez sur Messenger où que vous soyez ! Mettez Messenger sur votre mobile ! http://www.messengersurvotremobile.com/
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
On 15:20 Thu 08 Jan , Alex Ionescu wrote:
This is a good article that covers many of my feelings about git: http://texagon.blogspot.com/2008/02/use-mercurial-you-git.html
Have you read the comments to that post? ;) There are a lot of tutorials on Git
Poor Windows support, VS2008 integration, crappy GUIs,
Yes, that might be true (partly :)). But it works fine on cygwin.
shitload of binaries
Did you mean "goddamn idiotic truckload of sh*t"?
You can use only one binary, the dashed commands are deprecated and one day Git will get rid of them (just use 'git log' instead of 'git-log'). You can probably remove the dashed binaries at all (although, I haven't tested it).
being installed, and confusing, complex commands which encourage messing with history, doing "ammends" to commits and other weird actions make git a totally bad choice for ReactOS development.
Best regards, Alex Ionescu
On Thu, Jan 8, 2009 at 1:54 PM, Aleksey Bragin aleksey@reactos.org wrote:
Poor Windows support, VS2008 integration, crappy GUIs,
Yes, that might be true (partly :)). But it works fine on cygwin.
cygwin is not an acceptable solution at all.
Why not? Too kludgy?
There -is- an experimental version of Git for MinGW, but it was less stable when I tried it last (about a year ago).
On Jan 9, 2009, at 1:00 AM, Steven Noonan wrote:
On Thu, Jan 8, 2009 at 1:54 PM, Aleksey Bragin aleksey@reactos.org wrote:
Poor Windows support, VS2008 integration, crappy GUIs,
Yes, that might be true (partly :)). But it works fine on cygwin.
cygwin is not an acceptable solution at all.
Why not? Too kludgy?
Oral is a preferred method to do small throat surgery, not anal :)
There -is- an experimental version of Git for MinGW, but it was less stable when I tried it last (about a year ago).
I'm trying to use this one now - seems to work, however a problem with cr/lf seems to still exist, need to experiment more with autocrlf setting. Default setting to "true" didn't seem to work very well (there is some modified files in my freshly cloned repo)
On Thu, Jan 8, 2009 at 12:46 PM, Alexander Potashev aspotashev@gmail.com wrote:
On 15:20 Thu 08 Jan , Alex Ionescu wrote:
This is a good article that covers many of my feelings about git: http://texagon.blogspot.com/2008/02/use-mercurial-you-git.html
Have you read the comments to that post? ;) There are a lot of tutorials on Git
Poor Windows support, VS2008 integration, crappy GUIs,
Yes, that might be true (partly :)). But it works fine on cygwin.
The Cygwin version works great, indeed.
As for IDE integration, there is a Git integration module for NetBeans. It's true there's nothing for Visual Studio yet, but I'm sure if someone wants it, they'll write it. Even so, I have never found use for IDE integration of any revision control solution.
shitload of binaries
Did you mean "goddamn idiotic truckload of sh*t"?
You can use only one binary, the dashed commands are deprecated and one day Git will get rid of them (just use 'git log' instead of 'git-log'). You can probably remove the dashed binaries at all (although, I haven't tested it).
Most of the dashed versions are already gone as of v1.6. The remaining ones are shell scripts. I suspect a lot of them can be removed later on, once more of it is implemented purely in C.
being installed, and confusing, complex commands which encourage messing with history, doing "ammends" to commits and other weird actions make git a totally bad choice for ReactOS development.
Pfft. Amended commits aren't something you're forced into. It's just a handy feature that allows you to add to or modify the comment of a commit. A lot of your complaints sound to me like they're coming from someone who hasn't really -used- git all that much.
Worth noting that mercurial's performance is horrendous compared to Git. I've been using Git for all my projects lately (ranging from games to libraries, to scripts and other utilities). It works great.
- Steven
Inline... Best regards, Alex Ionescu
On Thu, Jan 8, 2009 at 4:59 PM, Steven Noonan steven@uplinklabs.net wrote:
On Thu, Jan 8, 2009 at 12:46 PM, Alexander Potashev aspotashev@gmail.com wrote:
On 15:20 Thu 08 Jan , Alex Ionescu wrote:
This is a good article that covers many of my feelings about git: http://texagon.blogspot.com/2008/02/use-mercurial-you-git.html
Have you read the comments to that post? ;) There are a lot of tutorials on Git
Poor Windows support, VS2008 integration, crappy GUIs,
Yes, that might be true (partly :)). But it works fine on cygwin.
The Cygwin version works great, indeed.
Using Cygwin isn't acceptable, as Aleksey pointed out.
As for IDE integration, there is a Git integration module for NetBeans. It's true there's nothing for Visual Studio yet, but I'm sure if someone wants it, they'll write it. Even so, I have never found use for IDE integration of any revision control solution.
Most of the developers use Windows and Visual Studio, so this is important for them.
shitload of binaries
Did you mean "goddamn idiotic truckload of sh*t"?
You can use only one binary, the dashed commands are deprecated and one day Git will get rid of them (just use 'git log' instead of 'git-log'). You can probably remove the dashed binaries at all (although, I haven't tested it).
Most of the dashed versions are already gone as of v1.6. The remaining ones are shell scripts. I suspect a lot of them can be removed later on, once more of it is implemented purely in C.
This is one of the many times your email used "one day"... Hg works *today*.
being installed, and confusing, complex commands which encourage messing with history, doing "ammends" to commits and other weird actions make
git a
totally bad choice for ReactOS development.
Pfft. Amended commits aren't something you're forced into. It's just a handy feature that allows you to add to or modify the comment of a commit. A lot of your complaints sound to me like they're coming from someone who hasn't really -used- git all that much.
I've used git and if all you're doing is committing and checking out it's simple enough. But the fact its architecture is so sloppy (imo) is what bothers me -- it nearly encourages you to mess with things like history and the source directory, which is very much against svn/hg's immutability.
Worth noting that mercurial's performance is horrendous compared to Git. I've been using Git for all my projects lately (ranging from games to libraries, to scripts and other utilities). It works great.
I've yet to see actual numbers on that, especially on Windows systems.
The main problem with Hg is the same problem I have with GCC, Cygwin, etc -- it's a Linux tool built for Linux-based projects, with a fanatic Linux-based fanbase that won't care much about Windows support, stability and performance..
There is nothing wrong with that *in principle*, and I use git for Linux-based school projects, but it makes it the wrong tool for a project like ReactOS.
- Steven
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
I've used git and if all you're doing is committing and checking out it's simple enough. But the fact its architecture is so sloppy (imo) is what bothers me -- it nearly encourages you to mess with things like history and the source directory, which is very much against svn/hg's immutability.
Typical linux-way, they even acknowledge it :(. Also, if it was clear from the beginning that a collection of scripts starting with git- blah won't work, why do them? And now conversion to "git dosomething", though "git-daemon" still exists, and "gitweb" is without any dash at all (which is not a command), and config files are spread on the gentoo box in /etc/conf.d and just in /etc. My portion of a rant.
Worth noting that mercurial's performance is horrendous compared to Git. I've been using Git for all my projects lately (ranging from games to libraries, to scripts and other utilities). It works great.
I've yet to see actual numbers on that, especially on Windows systems.
Native Git's performance in Windows doesn't really set records. I just compared a log operation, it seems to take equal amount of time doing a local git status and doing a remote svn status on my 256kbit/ s radiochannel.
I started that mirror because I couldn't get Hg to import our repository. Most of the importing scripts I tried (why not do one official? Migration from other VCS is a HUGELY important thing: look, even GIT, with all fanatism involved, made a really working interoperability tools!) didn't work, caused exceptions, and a couple of other scripts we tried estimated the needed time to import our repo as about several months.
The main problem with Hg is the same problem I have with GCC, Cygwin, etc -- it's a Linux tool built for Linux-based projects, with a fanatic Linux-based fanbase that won't care much about Windows support, stability and performance..
So true... I'm sick of those fanatics, though recently I see a decrease of their count, and a fresh view on FOSS world by people (here in Russia).
Rather than messing about with all this GIT / HG stuff, would it not be easier to look at the solution suggested by Timo. To re-quote: "You create an intermediate branch (either locally or on a remote server) then checkout a local copy. Your commits go to that intermediate branch, but commits to trunk do also go there. If there's a conflict, you need to resolve it as normally when working directly with trunk"
Would it be possible to use the post-svn scripts to keep intermediate branches up to date with trunk? Failing that, perhaps we can ask the SVN guys about what would be involved in implementing this directly. They might even have something like this underway.
Sticking with SVN is preferable, and if we can get this feature, it's perfect.
Ged.
-----Original Message----- From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of Aleksey Bragin Sent: 08 January 2009 22:43 To: ReactOS Development List Subject: Re: [ros-dev] GIT mirror
I've used git and if all you're doing is committing and checking out it's simple enough. But the fact its architecture is so sloppy (imo) is what bothers me -- it nearly encourages you to mess with things like history and the source directory, which is very much against svn/hg's immutability.
Typical linux-way, they even acknowledge it :(. Also, if it was clear from the beginning that a collection of scripts starting with git- blah won't work, why do them? And now conversion to "git dosomething", though "git-daemon" still exists, and "gitweb" is without any dash at all (which is not a command), and config files are spread on the gentoo box in /etc/conf.d and just in /etc. My portion of a rant.
Worth noting that mercurial's performance is horrendous compared to Git. I've been using Git for all my projects lately (ranging from games to libraries, to scripts and other utilities). It works great.
I've yet to see actual numbers on that, especially on Windows systems.
Native Git's performance in Windows doesn't really set records. I just compared a log operation, it seems to take equal amount of time doing a local git status and doing a remote svn status on my 256kbit/ s radiochannel.
I started that mirror because I couldn't get Hg to import our repository. Most of the importing scripts I tried (why not do one official? Migration from other VCS is a HUGELY important thing: look, even GIT, with all fanatism involved, made a really working interoperability tools!) didn't work, caused exceptions, and a couple of other scripts we tried estimated the needed time to import our repo as about several months.
The main problem with Hg is the same problem I have with GCC, Cygwin, etc -- it's a Linux tool built for Linux-based projects, with a fanatic Linux-based fanbase that won't care much about Windows support, stability and performance..
So true... I'm sick of those fanatics, though recently I see a decrease of their count, and a fresh view on FOSS world by people (here in Russia). _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Aleksey Bragin wrote:
The main problem with Hg is the same problem I have with GCC, Cygwin, etc -- it's a Linux tool built for Linux-based projects, with a fanatic Linux-based fanbase that won't care much about Windows support, stability and performance..
So true... I'm sick of those fanatics, though recently I see a decrease of their count, and a fresh view on FOSS world by people (here in Russia).
Are you talking about Git or Hg now?
Sorry, I meant to say git -- and I think Aleksey understood it as "git" too. I'm surprised you had import problems -- Hg is widely recognized as having an excellent built-in "converter" for most other repositories.
Best regards, Alex Ionescu
2009/1/8 Timo Kreuzer timo.kreuzer@web.de
Aleksey Bragin wrote:
The main problem with Hg is the same problem I have with GCC, Cygwin, etc -- it's a Linux tool built for Linux-based projects, with a fanatic Linux-based fanbase that won't care much about Windows support, stability and performance..
So true... I'm sick of those fanatics, though recently I see a decrease of their count, and a fresh view on FOSS world by people (here in Russia).
Are you talking about Git or Hg now?
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
git scares the hell out of me -- git-filter-branch is a tool explicitly created to allow you to *destroy* (not revert) all commits by a single author. I'm not saying ReactOS is a minefield of bad attitude, but I'm sure we can all think of at least a half-dozen of instances where such a tool would've been used (even by a committer against himself, as was actually done).
With SVN, when the author did that, we were able to undo the damage immediately -- that's the point. Being able to destroy history data like this is just horrible.
Best regards, Alex Ionescu
On Thu, Jan 8, 2009 at 8:14 PM, Alex Ionescu ionucu@videotron.ca wrote:
Sorry, I meant to say git -- and I think Aleksey understood it as "git" too. I'm surprised you had import problems -- Hg is widely recognized as having an excellent built-in "converter" for most other repositories.
Best regards, Alex Ionescu
2009/1/8 Timo Kreuzer timo.kreuzer@web.de
Aleksey Bragin wrote:
The main problem with Hg is the same problem I have with GCC, Cygwin, etc -- it's a Linux tool built for Linux-based projects, with a fanatic Linux-based fanbase that won't care much about Windows support, stability and performance..
So true... I'm sick of those fanatics, though recently I see a decrease of their count, and a fresh view on FOSS world by people (here in Russia).
Are you talking about Git or Hg now?
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
More git "features":
The rebase command will take a branch and rewrite its historyhttp://www.kernel.org/pub/software/scm/git/docs/user-manual.html#using-git-rebase so that it is as if the branch had been based off a different branch or revision than the one it actually was.
Rebasing throws away¹http://andrew.puzzling.org/diary/2008/July/29/rebase-criticism#rebase-criticism-footnote-1 the history of a branch. Unfortunately, throwing away that history hampers collaboration on that branch: if someone has branched off your branch, you now have two branches that appear unrelated to your VCS but make nearly identical changes to the same code. In other words, you now have two branches that are basically guaranteed to conflict when merged: for instance, if both branches are merged to a common trunk, almost certainly all the changes in the second branch that were present in the first will conflict. Ouch!
Seriously guys, those of you that have been around here for 3-4 years+... do these "features" look like they match our development style? We have plenty of noobs (nothing wrong with that) and plenty of people with bombastic attitudes (nothing wrong with that either). An immutable trunk is the only thing keeping things sane. Best regards, Alex Ionescu
On Thu, Jan 8, 2009 at 8:21 PM, Alex Ionescu ionucu@videotron.ca wrote:
git scares the hell out of me -- git-filter-branch is a tool explicitly created to allow you to *destroy* (not revert) all commits by a single author. I'm not saying ReactOS is a minefield of bad attitude, but I'm sure we can all think of at least a half-dozen of instances where such a tool would've been used (even by a committer against himself, as was actually done).
With SVN, when the author did that, we were able to undo the damage immediately -- that's the point. Being able to destroy history data like this is just horrible.
Best regards, Alex Ionescu
On Thu, Jan 8, 2009 at 8:14 PM, Alex Ionescu ionucu@videotron.ca wrote:
Sorry, I meant to say git -- and I think Aleksey understood it as "git" too. I'm surprised you had import problems -- Hg is widely recognized as having an excellent built-in "converter" for most other repositories.
Best regards, Alex Ionescu
2009/1/8 Timo Kreuzer timo.kreuzer@web.de
Aleksey Bragin wrote:
The main problem with Hg is the same problem I have with GCC, Cygwin, etc -- it's a Linux tool built for Linux-based projects, with a fanatic Linux-based fanbase that won't care much about Windows support, stability and performance..
So true... I'm sick of those fanatics, though recently I see a decrease of their count, and a fresh view on FOSS world by people (here in Russia).
Are you talking about Git or Hg now?
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Another good article: http://importantshock.wordpress.com/2008/08/07/git-vs-mercurial/ One thing I forgot to mention -- git also sucks on OS X, while Hg works out of the box and is much faster.
Also, because it's Python, integrating it with complex tools such as Wine Autosync, RosBuild and RosRegressionTest would be a piece of cake. You could do complex things like making all commits into Hg Patch Queues and having certain patches taken out and/or modified based on the results of the build or regression test.
Git provides no such modularity.
Best regards, Alex Ionescu
On Thu, Jan 8, 2009 at 8:28 PM, Alex Ionescu ionucu@videotron.ca wrote:
More git "features":
The rebase command will take a branch and rewrite its historyhttp://www.kernel.org/pub/software/scm/git/docs/user-manual.html#using-git-rebase so that it is as if the branch had been based off a different branch or revision than the one it actually was.
Rebasing throws away¹http://andrew.puzzling.org/diary/2008/July/29/rebase-criticism#rebase-criticism-footnote-1 the history of a branch. Unfortunately, throwing away that history hampers collaboration on that branch: if someone has branched off your branch, you now have two branches that appear unrelated to your VCS but make nearly identical changes to the same code. In other words, you now have two branches that are basically guaranteed to conflict when merged: for instance, if both branches are merged to a common trunk, almost certainly all the changes in the second branch that were present in the first will conflict. Ouch!
Seriously guys, those of you that have been around here for 3-4 years+... do these "features" look like they match our development style? We have plenty of noobs (nothing wrong with that) and plenty of people with bombastic attitudes (nothing wrong with that either). An immutable trunk is the only thing keeping things sane. Best regards, Alex Ionescu
On Thu, Jan 8, 2009 at 8:21 PM, Alex Ionescu ionucu@videotron.ca wrote:
git scares the hell out of me -- git-filter-branch is a tool explicitly created to allow you to *destroy* (not revert) all commits by a single author. I'm not saying ReactOS is a minefield of bad attitude, but I'm sure we can all think of at least a half-dozen of instances where such a tool would've been used (even by a committer against himself, as was actually done).
With SVN, when the author did that, we were able to undo the damage immediately -- that's the point. Being able to destroy history data like this is just horrible.
Best regards, Alex Ionescu
On Thu, Jan 8, 2009 at 8:14 PM, Alex Ionescu ionucu@videotron.ca wrote:
Sorry, I meant to say git -- and I think Aleksey understood it as "git" too. I'm surprised you had import problems -- Hg is widely recognized as having an excellent built-in "converter" for most other repositories.
Best regards, Alex Ionescu
2009/1/8 Timo Kreuzer timo.kreuzer@web.de
Aleksey Bragin wrote:
The main problem with Hg is the same problem I have with GCC, Cygwin, etc -- it's a Linux tool built for Linux-based projects, with a fanatic Linux-based fanbase that won't care much about Windows support, stability and performance..
So true... I'm sick of those fanatics, though recently I see a decrease of their count, and a fresh view on FOSS world by people (here in Russia).
Are you talking about Git or Hg now?
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Hi, Rather than reply inline to the inline to the inline replies I figured I would just reply with no quoting. I agree with all of Alex's statements about the limitations of git and the problems with it. Amazing I would say that being a Wine nut right?
That being said as a (sometime) developer on Wine and a (even less active) ReactOS developer, I think that having a git gateway is a good idea. I like git, I most likely will use the git mirror for my stuff. Even the Linux kernel has CVS and SVN gateways and everyone knows how much Linus hates them. If nothing else a git gateway will enable those developers that wont to take advantage of the branching support and are comfortable with git to develop in the way that works best for them. If others want to setup an Hg mirror then more power to them too! I am all for the Hg and Git mirrors but...
The VCS is not the big bottleneck! I mean don't get me wrong, private branches and every commit being a branch is cool as hell but that feature alone is not what will really bring massive ROI to this project.
I think Alex does not mind the idea of these gateways either, its just that he like I don't wish to see the finite amount of energy we have at our disposal spent on projects bringing little return. This is why I gave up when I was attempting to import to git a few months back. I managed to get trunk imported but then it was taking days to import the branches and didn't want to waste the few precious seconds I had to devote to ReactOS spent on a futile effort (for me anyway). I am glad someone else has a mirror up though. Like I said, I will use it!
That being said, I believe the ReactOS team needs to focus fixing other things like the build system and support for MSVC. I believe a concerted effort to fix rbuild and msvc support will yield an exponential return on investment in terms of bringing in new developers.
On Thu, Jan 8, 2009 at 11:47 PM, Steven Edwards winehacker@gmail.comwrote:
That being said as a (sometime) developer on Wine and a (even less active) ReactOS developer, I think that having a git gateway is a good idea. I like git, I most likely will use the git mirror for my stuff. Even the Linux kernel has CVS and SVN gateways and everyone knows how much Linus hates them. If nothing else a git gateway will enable those developers that wont to take advantage of the branching support and are comfortable with git to develop in the way that works best for them. If others want to setup an Hg mirror then more power to them too! I am all for the Hg and Git mirrors but...
Yeah, lets try to spin this little debate into a new direction. We could find a way to convert commits from git to svn or have some simple diff mechanism that would sync git-tree into the main svn tree. Dunno... sounds messy, maybe a bad idea. How do the linux kernel nuts maintain these gateways consistent ?
The VCS is not the big bottleneck! I mean don't get me wrong, private branches and every commit being a branch is cool as hell but that feature alone is not what will really bring massive ROI to this project.
I think Alex does not mind the idea of these gateways either, its just that he like I don't wish to see the finite amount of energy we have at our disposal spent on projects bringing little return. This is why I gave up when I was attempting to import to git a few months back. I managed to get trunk imported but then it was taking days to import the branches and didn't want to waste the few precious seconds I had to devote to ReactOS spent on a futile effort (for me anyway). I am glad someone else has a mirror up though. Like I said, I will use it!
I'm glad people understand this point, there are many people willing to spend *some* time debugging, fixing bugs, testing and generally dicking around for ros... unfornunetly a lot, if not most, of this time is wasted fighting with the build system, and/or having to repeatedly install, restart or copy crap. If it feels like an extra burden people are not going to accept it. The last thing people want is to be forced to learn a new system (which also takes time). So for now I think we should keep the git mirror and let people experiment with it...
That being said, I believe the ReactOS team needs to focus fixing other things like the build system and support for MSVC. I believe a concerted effort to fix rbuild and msvc support will yield an exponential return on investment in terms of bringing in new developers.
Can I have some fries with that?
-- Steven Edwards
"There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
On 02:49 Fri 09 Jan , Samuel serapion wrote:
On Thu, Jan 8, 2009 at 11:47 PM, Steven Edwards winehacker@gmail.comwrote:
That being said as a (sometime) developer on Wine and a (even less active) ReactOS developer, I think that having a git gateway is a good idea. I like git, I most likely will use the git mirror for my stuff. Even the Linux kernel has CVS and SVN gateways and everyone knows how much Linus hates them. If nothing else a git gateway will enable those developers that wont to take advantage of the branching support and are comfortable with git to develop in the way that works best for them. If others want to setup an Hg mirror then more power to them too! I am all for the Hg and Git mirrors but...
Yeah, lets try to spin this little debate into a new direction. We could find a way to convert commits from git to svn or have some simple diff mechanism that would sync git-tree into the main svn tree. Dunno... sounds messy, maybe a bad idea. How do the linux kernel nuts maintain these gateways consistent ?
I've never heard about cvs and svn gateways for the Linux kernel sources, those gateways are probably used to just grab the sources but not to send changes upstream. In the Linux kernel development 'git pull' is used only between the Git tree of "high-level" maintainers. Ordinary developers just send patches to LKML (or to another mailing list).
Yes, we should probably setup a backward gateway to svn. Usually (without a Git mirror) people imports an svn repo to their local Git repo a then 'git svn dcommit' back to svn repo. This won't work if you clone the mirror at git://git.reactos.org/reactos.git , because now you're dealing with a normal Git repo. But we can configure (somehow) the mirror to dcommit the changes somebody has pushed.
-- encoded Samuel Serapión Vega Computer Science, Polytechnic University of Puerto Rico.
Yeah.
Well, obviously *converting reactos to git* is crazy. Maybe I announced git mirror too soon, because I wanted to experiment more with it before actually offering it to people.
Speaking of that, git access url is moved to git://git.reactos.org/ reactos.git/ Don't forget to update your configs...
Also, I made an assumption that git starts getting decent Windows support. If it's not going to happen (like, if msysgit and tortoisegit projects are going to be abandoned), I'm afraid I may not be so glad about usability of this mirror.
I haven't investigated possibilities about commiting back to SVN, but it's listed as a feature, so might be something can work out here.
WBR, Aleksey Bragin.
On Jan 9, 2009, at 4:14 AM, Alex Ionescu wrote:
Sorry, I meant to say git -- and I think Aleksey understood it as "git" too.
I'm surprised you had import problems -- Hg is widely recognized as having an excellent built-in "converter" for most other repositories.
Best regards, Alex Ionescu
I agree with Steven -- I don't mind a git mirror (but I would appreciate an Hg mirror as well -- since you already have git set up, just run git->hg conversion, it should work flawlessly. Converting svn->hg is usually not the way to go).
My arguments were against using git as the primary DVCS -- it's just not the right tool *FOR REACTOS*.
As the old adage says:
1) Analyze your requirements 2) Pick the best tool for your project 3) Shut up about the tool and write code instead
FYI, HgSvn is what I use:
hgsvn http://cheeseshop.python.org/pypi/hgsvn allows you to work on SVN checkouts using Mercurial (mirroring all SVN history in a local Mercurial repository on which you can also do local development). It is useful for managing private branches, submitting patches to project maintainers, have fast local operations instead of slow remote "svn up/log/blame"
Best regards, Alex Ionescu
On Fri, Jan 9, 2009 at 4:08 AM, Aleksey Bragin aleksey@reactos.org wrote:
Yeah.
Well, obviously *converting reactos to git* is crazy. Maybe I announced git mirror too soon, because I wanted to experiment more with it before actually offering it to people.
Speaking of that, git access url is moved to git://git.reactos.org/ reactos.git/ Don't forget to update your configs...
Also, I made an assumption that git starts getting decent Windows support. If it's not going to happen (like, if msysgit and tortoisegit projects are going to be abandoned), I'm afraid I may not be so glad about usability of this mirror.
I haven't investigated possibilities about commiting back to SVN, but it's listed as a feature, so might be something can work out here.
WBR, Aleksey Bragin.
On Jan 9, 2009, at 4:14 AM, Alex Ionescu wrote:
Sorry, I meant to say git -- and I think Aleksey understood it as "git" too.
I'm surprised you had import problems -- Hg is widely recognized as having an excellent built-in "converter" for most other repositories.
Best regards, Alex Ionescu
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
What I would really want for our main repository (in addition to a better solution for branches) is ANY way to have patch queues, patch management. Working with plaintext diff files is not convenient.
WBR, Aleksey Bragin.
On Jan 9, 2009, at 5:17 PM, Alex Ionescu wrote:
I agree with Steven -- I don't mind a git mirror (but I would appreciate an Hg mirror as well -- since you already have git set up, just run git->hg conversion, it should work flawlessly. Converting svn->hg is usually not the way to go).
My arguments were against using git as the primary DVCS -- it's just not the right tool *FOR REACTOS*.
As the old adage says:
- Analyze your requirements
- Pick the best tool for your project
- Shut up about the tool and write code instead
FYI, HgSvn is what I use:
hgsvn allows you to work on SVN checkouts using Mercurial (mirroring all SVN history in a local Mercurial repository on which you can also do local development). It is useful for managing private branches, submitting patches to project maintainers, have fast local operations instead of slow remote "svn up/log/blame"
Best regards, Alex Ionescu
http://www.selenic.com/mercurial/wiki/index.cgi/WorkingWithSubversion Best regards, Alex Ionescu
2009/1/9 Aleksey Bragin aleksey@reactos.org
What I would really want for our main repository (in addition to a better solution for branches) is ANY way to have patch queues, patch management. Working with plaintext diff files is not convenient.
WBR, Aleksey Bragin. On Jan 9, 2009, at 5:17 PM, Alex Ionescu wrote:
I agree with Steven -- I don't mind a git mirror (but I would appreciate an Hg mirror as well -- since you already have git set up, just run git->hg conversion, it should work flawlessly. Converting svn->hg is usually not the way to go).
My arguments were against using git as the primary DVCS -- it's just not the right tool *FOR REACTOS*.
As the old adage says:
- Analyze your requirements
- Pick the best tool for your project
- Shut up about the tool and write code instead
FYI, HgSvn is what I use:
hgsvn http://cheeseshop.python.org/pypi/hgsvn allows you to work on SVN checkouts using Mercurial (mirroring all SVN history in a local Mercurial repository on which you can also do local development). It is useful for managing private branches, submitting patches to project maintainers, have fast local operations instead of slow remote "svn up/log/blame"
Best regards, Alex Ionescu
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Hi! If there are some people ready to help me with GIT (thing which is totally new for me), I would be glad to switch "my" branch. Inconsistent line endings start pissing me off! P. Schweitzer
To: ros-dev@reactos.org From: aleksey@reactos.org Date: Thu, 8 Jan 2009 17:09:35 +0300 Subject: [ros-dev] GIT mirror
Since Arty just mentioned GIT, I think it's about time to uncover a ReactOS GIT mirror I've been setting up recent couple of weeks.
It works pretty good so far, autoupdates every 10 minutes, so it stays quite up-to-date.
URLs: git://git.reactos.org/ - for git cloning. http://git.reactos.org - for web viewing.
As for branches, it was actually my main intention in using a DVCS, because SVN branches are greatly uncomfortable to develop anything because of the need to keep the branch up-to-date.
But, to prevent any gossips, SVN stays as our main repository, and GIT mirror is just for exploration of new possibilities, and for comfortability of working with branches - if someone wants to try that out. Usual SVN branches are still permitted.
WBR, Aleksey Bragin. _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
_________________________________________________________________ Inédit ! Des Emoticônes Déjantées! Installez les dans votre Messenger ! http://www.ilovemessenger.fr/Emoticones/EmoticonesDejantees.aspx
Hi!
On Thu, Jan 8, 2009 at 8:09 AM, Aleksey Bragin aleksey@reactos.org wrote:
Since Arty just mentioned GIT, I think it's about time to uncover a ReactOS GIT mirror I've been setting up recent couple of weeks.
It works pretty good so far, autoupdates every 10 minutes, so it stays quite up-to-date.
URLs: git://git.reactos.org/ - for git cloning. http://git.reactos.org - for web viewing.
As for branches, it was actually my main intention in using a DVCS, because SVN branches are greatly uncomfortable to develop anything because of the need to keep the branch up-to-date.
But, to prevent any gossips, SVN stays as our main repository, and GIT mirror is just for exploration of new possibilities, and for comfortability of working with branches - if someone wants to try that out. Usual SVN branches are still permitted.
WBR, Aleksey Bragin.
That is good, now we can get newbies from Linux and wine or any other small project to come over and start working on ReactOS. Get the newbies up to speed and start using a more integrated repository system like svn.
Thanks, James
-
Aleksey Bragin -
Alex Ionescu -
Alexander Potashev -
Colin Finck -
Ged -
James Tabor -
Pierre SCHWEITZER -
Samuel serapion -
Steven Edwards -
Steven Noonan -
Timo Kreuzer