Thanks Raul,
It helped me to understand the process, and yes this seems like an interesting
process indeed
Jacques
From: "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.
>
