Hi Raul, So if I understand your posting correctly you use a git-server in your own development environment and perhaps a plugin in eclipse?
Regards, Pierre 2009/10/23 Raul Sieberath <of...@sieberath.com> > Jacques, > > 1 - Everyone has the whole history of development, what also is good > for backup. > 2 - It is distributed. > This means there is no central repository. No central > repository means that we do not need commiters as we need with SVN. > However, the community still have the people they trust. For example, > I fix something and I tell people that I fixed and it is available in > my branch (branch is fast. I mean really fast). Now, how this fix get > to the community. I will need to do the same as I do today. I will > tell someone that has the respect of the community to merge my fix > into his branch. In this case, I could tell you to test my fix. You > would decide when to do it, and when you have time you go ahead and > merge my fix into your development branch (remember branch is fast), > and if you like my fix, then you merge into your stable branch. You > push your branch to a server point where people can pull from. The > community gets my fix because they trust you and you have my fix in > your stable branch. > I think the main difference is that we do not work with diff anymore. > Each developer has a branch, and people get the patch directly in > the repository. > The file format is also very efficient and small. Even if everyone in > this list had one or more branches the system keep the tree very > small. > > About bigger commits, it is actually the contrary. You commit several > times in your local machine. Then you push. When I pull after your > push, I get all history commits you have done. Not one big change. I > actually get everything. > > Well, I tried to explain from a perspective of someone that use svn. > In the same way it is done today. People can try the fix pull from my > branch and comment in the list that my fix is good or not. > > I hope it helped instead of confusing people more. But there are other > people here using git and they can point out any mistakes I made or > other scenarios. > > Raul > > On Thu, 22 Oct 2009 19:01:23 +0200 > "Jacques Le Roux" <jacques.le.r...@les7arts.com> wrote: > > > Thanks for comment Raul, > > > > How does it change the workflow, what does it changes ? Could you > > elaborate a bit more please ? I have read on Apache MLs that some > > persons are against using Git because, they say, it's not good for > > collaboration. Their arguments is to say that, contrary as Subversion > > general usage, with Git the tendency is to have bigger commit because > > people work more isolated and then commit whole blocks of changes > > > > Jacques > > > > From: "Raul Sieberath" <of...@sieberath.com> > > > GIT is really a very good tool. I use it locally and for other > > > projects. However, it does change the work flow of development. > > > > > > My 2 cents > > > > > > Raul > > > > > > On Thu, 22 Oct 2009 01:14:57 -0500 > > > Ean Schuessler <e...@brainfood.com> wrote: > > > > > >> Adrian Crum wrote: > > >> > I share some of the frustration Tim expressed, but at the same > > >> > time I really appreciate the valuable contributions your company > > >> > has made to the project. > > >> > > > >> > All I would ask is that you spend a little more time reviewing > > >> > code and testing it before committing it. > > >> Which brings up back to the value of the GIT-based pull-oriented > > >> workflow. In the Linux kernel when someone has a feature they say > > >> "people come checkout my repo for the cool thing I did" and people > > >> go examine the work. The code doesn't go into someone's tree until > > >> they already approve of it. If they have a complain they might say > > >> "fix X, Y and Z and I will merge in your code". > > >> > > >> This way, if someone finds a "sloppier" workflow productive... so > > >> be it. It may not get merged until they fix it up or someone works > > >> with them to fix it up and it finally meets approval. The value > > >> is, people who are not bothered by the sloppy workflow might work > > >> fast and loose to prototype up some new feature. > > > > > > > > >
