Re: Patch pinging

[Chiheng Xu <chiheng.xu@gmail.com>]

On Tue, Jun 8, 2010 at 11:55 PM, Tobias Burnus <burnus@net-b.de> wrote:
> On 06/08/2010 05:42 PM, H.J. Lu wrote:
>>> Think about mercurial or git.  Every one can commit on his/her own
>>> local repository, and "publish" his/her repository.  [...]
>>
>> git is an excellent tool to create and share patches. Maybe we should
>> have an open gcc git mirror with gitweb and every contributor can create
>> his/her own branches and publish them.
>
> Well, we do: Goto http://repo.or.cz/w/official-gcc.git and click on "fork".
>
> I do like Git, but Git seems to make mostly sense if you have a small
> project on which you are working. If you have only a small patch (or a
> collection of small and unrelated patches), it won't help much.
>
> Additionally, I do not think that pulling from a branch will happen -
> rather that one creates patches from an (published or unpublished) git
> repository and submits them like normal.
>
> Thus, I do not think it helps with patch reviewing/tracking, though I
> believe it helps with developing patches.
>
> Tobias,
> who happily uses his private GCC git repository, which does not diverge
> much from the git master.
>

The philosophy behind DVCS(mercurial or git) is that,  any software
project is an evolution tree, like the one of the lives of Planet
Earth.  This evolution tree has a root, which is the UCA(Ultimate
Common Ancestor) of all lives. For the lives of Planet Earth, UCA may
be some kind of ancient micro-organism. For a software, UCA would be
the revision zero.

Everyone can make change to any revision, do some minor improvement,
to let the evolution tree to branch and grow.  Everyone can merge
other people's valuable branch/change in his/her own branch, this is
like bi-sex reproduction. Everyone can make his/her branch more
perfect to gain some survival advantage. The changes that will be in
the final releases is those whose branches have been merged into
trunk.  Everyone strive to let his/her branch be merged, otherwise
his/her branch will die. If someone's branch are rejected, he/she can
try to redo his change, maybe from an newer trunk revision. When
his/her changes meet some criteria, he/she can ask someone to review
his branches and selectively merge.

The died branch are never lost, it is stored in the repositories
persistently, and can revive at any time.

If someone's branch diverge far from the trunk, it may be very hard to
merge. So branches from a relatively newer trunk revision and have not
too many changes will be desirable.

In this method, you only need to note the branch(and its URL) to
review, instead of attach the patches.



By the way, I found mercurial are easier to learn and use.





-- 
Chiheng Xu
Wuhan,China