Pierre, actually git does not have a server installation. It does not have server daemon, and it is not necessary.
Git in a collection of programs and scripts. They implemented in c what need to me fast and the rest is perl or python. I do not remember right now. Anyway, to understand the reason that a server software is not necessary, I need to explain a bit about the file format used to keep the data. Every piece of information has a SHA signature, and this signature depends on everything is under it. So, if you clone a git branch and you want to push it back (it is actually just a folder share). Git will compare your top most sha signature with the top most signature on the share. They will be the same and it decides thera are no deltas to be transmitted. But than you go ahead and change one character in the deepest folder, commit (this will recalculate the sha of from top to bottom) when you push, git will compared the top most sha signature and find it is different. Then it has the full history, so it calculates the delta locally and push it to the copy in the share. The file structure is very clever, I think any programmer should read it for the fun of it. So, there are Git plug-ins for eclipse. They can use the git executables and scripts or it can implement in java. Any question let me know. Raul On Fri, 23 Oct 2009 10:07:16 +0200 Pierre Smits <pierre.sm...@gmail.com> wrote: > 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. > > > > > > > > > > > > > >
