GIT mirror

[Aleksey Bragin]

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.

[Colin Finck]

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?
:-)

Best regards,

Colin

[Alexander Potashev]

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(a)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

[Alex Ionescu]

Hg.
Best regards,
Alex Ionescu


On Thu, Jan 8, 2009 at 12:12 PM, Alexander Potashev <aspotashev(a)gmail.com>wrote;wrote:

>   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(a)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(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[Alexander Potashev]

On 14:36 Thu 08 Jan     , Alex Ionescu wrote:
>   Hg.
>  Best regards,
>  Alex Ionescu 
What does "Hg" mean? "Hot Girl", "High Grade" (marijuana),
"Highly
gifted" or after all Mercurial?

[Pierre SCHWEITZER]

Mercurial, indeed
>   Date: Thu, 8 Jan 2009 22:54:50 +0300
>  From: aspotashev(a)gmail.com
>  To: ros-dev(a)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(a)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

[Alex Ionescu]

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(a)hotmail.com>

>    Mercurial, indeed
>
>
> >   Date: Thu, 8 Jan 2009 22:54:50 +0300
> >  From: aspotashev(a)gmail.com
> >  To: ros-dev(a)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(a)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(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>
>

[Alexander Potashev]

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
>

[Aleksey Bragin]

> >   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.

[Steven Noonan]

On Thu, Jan 8, 2009 at 1:54 PM, Aleksey Bragin <aleksey(a)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).

[Aleksey Bragin]

On Jan 9, 2009, at 1:00 AM, Steven Noonan wrote:

>   On Thu, Jan 8, 2009 at 1:54 PM, Aleksey Bragin  
>  <aleksey(a)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)

[Steven Noonan]

On Thu, Jan 8, 2009 at 12:46 PM, Alexander Potashev
<aspotashev(a)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

[Alex Ionescu]

Inline...
Best regards,
Alex Ionescu


On Thu, Jan 8, 2009 at 4:59 PM, Steven Noonan <steven(a)uplinklabs.net> wrote:

>   On Thu, Jan 8, 2009 at 12:46 PM, Alexander Potashev
>  <aspotashev(a)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(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[Aleksey Bragin]

>   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).

[Ged]

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(a)reactos.org [mailto:[e-mail]] 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(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

[Timo Kreuzer]

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?

[Alex Ionescu]

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(a)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(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>
>

[Alex Ionescu]

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(a)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(a)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(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-dev
> >
> >  
>

[Alex Ionescu]

More git "features":

The rebase command will take a branch and rewrite its
history<http://www.kernel.org/pub/software/scm/git/docs/user-manual.html…
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#reb…
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 &lt;ionucu(a)videotron.ca&gt; 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 &lt;ionucu(a)videotron.ca&gt; 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 &lt;timo.kreuzer(a)web.de&gt;
> >
> > >    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(a)reactos.org
> > >  http://www.reactos.org/mailman/listinfo/ros-dev
> > >
> > >  
> >  
>

[Alex Ionescu]

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(a)videotron.ca> wrote:

>   More git "features":
>
>  The rebase command will take a branch and rewrite its
> history<http://www.kernel.org/pub/software/scm/git/docs/user-manual.html…
> 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#reb…
> 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 &lt;ionucu(a)videotron.ca&gt; 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 &lt;ionucu(a)videotron.ca&gt; 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 &lt;timo.kreuzer(a)web.de&gt;
> > >
> > > >    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(a)reactos.org
> > > >  http://www.reactos.org/mailman/listinfo/ros-dev
> > > >
> > > >  
> > >  
> >  
>

[Steven Edwards]

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.

-- 
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

[Samuel serapion]

On Thu, Jan 8, 2009 at 11:47 PM, Steven Edwards <winehacker(a)gmail.com>wrote;wrote:



>   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(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>  


-- 
encoded
Samuel Serapión Vega
Computer Science, Polytechnic University of Puerto Rico.

[Alexander Potashev]

On 02:49 Fri 09 Jan     , Samuel serapion wrote:
>   On Thu, Jan 8, 2009 at 11:47 PM, Steven Edwards
> <winehacker(a)gmail.com>wrote;wrote:
> >   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.

[Aleksey Bragin]

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
>

[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 &lt;aleksey(a)reactos.org&gt; 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(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[Aleksey Bragin]

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:
>
>  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 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

[Alex Ionescu]

http://www.selenic.com/mercurial/wiki/index.cgi/WorkingWithSubversion
Best regards,
Alex Ionescu


2009/1/9 Aleksey Bragin <aleksey(a)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:
>
>  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
>
>
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>
>

[Pierre SCHWEITZER]

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(a)reactos.org
>  From: aleksey(a)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(a)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

[James Tabor]

Hi!

On Thu, Jan 8, 2009 at 8:09 AM, Aleksey Bragin <aleksey(a)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