Cheers, Ruppert
On Oct 22, 2009, at 4:05 PM, Raul Sieberath wrote:
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.
smime.p7s
Description: S/MIME cryptographic signature
