commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <gil...@harfang.homelinux.org>
Subject Re: [Math] Controlled and and assisted switch to "Git"
Date Thu, 28 Nov 2013 12:19:21 GMT
On Wed, 27 Nov 2013 13:50:08 +0000, sebb wrote:
> On 27 November 2013 13:37, Luc Maisonobe <luc@spaceroots.org> wrote:
>> Le 27/11/2013 13:47, Gilles a écrit :
>>> On Wed, 27 Nov 2013 12:44:27 +0100, Emmanuel Bourg wrote:
>>>> Le 27/11/2013 12:13, Gilles a écrit :
>>>>
>>>>> I'm only a bit worried about the timing, and whether 
>>>>> knowledgeable
>>>>> people will be willing to detail the move and explain what to do 
>>>>> to
>>>>> so that the total ignorant can indeed continue contributing "à la
>>>>> svn"[1]
>>>>> until he finds the time to study the more advanced features.
>>
>> In addition to the commands Emmanual wrote down below, I confirm I 
>> am OK
>> to help people on the list with Git.
>>
>>>>
>>>> If you don't apply a fancy branch model Git can be used just like
>>>> Subversion
>>>>
>>>> Checkout:
>>>>
>>>>    git clone <url>
>>>>
>>>> Commit all changes:
>>>>
>>>>    git commit -a
>>>>    git push
>>>>
>>>> Update from the repository:
>>>>
>>>>    git pull
>>>
>>> Quite clear up to here.
>>>
>>>>
>>>> The one thing Git doesn't do as well as Subversion is merging the 
>>>> local
>>>> changes with the remote changes when updating the local copy. He 
>>>> will
>>>> refuse to update the local copy if there are conflicting changes. 
>>>> In
>>>> this case you either have to commit your local modifications, or 
>>>> stash
>>>> them before updating. You can then resolve the conflicts as usual.
>>>>
>>>>    git stash
>>>>    git pull
>>>>    git stash pop
>>>
>>> What is "stash", what is "stash pop"?
>>
>> Stashing is a feature that allows to temporarily save the current 
>> work
>> without commiting it. Suppose you have started to work on files a, b 
>> and
>> c and then want to update your workspace from the reference remote
>> repository. If another developer did change something on file b, it 
>> will
>> be easier for future work to do "as if" the remote change was done
>> first, and then your own work was done on top of it. So in order to 
>> do
>> this, you would like to first put aside your change, then get in 
>> sync
>> with the remote repo, then replay your changes. This is what the 
>> "git
>> stash" and "git stash pop" will do.
>>
>> In fact, the stash can contain any number of temporary changes, and 
>> you
>> can push them on the list or replay them in any order, or replay 
>> only
>> some of them and not the other ones if they are not ready. I would 
>> not
>> recommend this practice, though. If you work on several things at 
>> the
>> same time, using local branches is much easier.
>>
>>>
>>> You see, from my zero knowledge, I infer from a previous post that 
>>> some
>>> non-committer contributor can provide an "outdated" patch, and I, 
>>> as a
>>> committer, should still be able to commit it (i.e. without asking 
>>> him
>>> to update the patch with the newer trunk). How? On what condition 
>>> is it
>>> possible, and when does that approach become impossible?
>>
>> In git, each commit holds a reference to the previous state.
>>
>> Consider the commit history on a reference Apache repository, it may
>> look like (old version on top, recent versions on bottom):
>>
>>   Aapache
>>      |
>>   Bapache
>>      |
>>   Capache
>>      |
>>   Dapache
>>
>> At this point, a contributor clones the reference repository, does 
>> some
>> local commits. His own repository will contains this history:
>>
>>   Aapache
>>      |
>>   Bapache
>>      |
>>   Capache
>>      |
>>   Dapache
>>      |
>>   Econtrib
>>      |
>>   Fcontrib
>>      |
>>   Gcontrib
>>
>> Then he proposes his contribution to the project, for example using 
>> a
>> "pull request" in public services like github. At this point, the
>> history of the reference Apache repository will have already changed 
>> and
>> looked as follows:
>>
>>   Aapache
>>      |
>>   Bapache
>>      |
>>   Capache
>>      |
>>   Dapache
>>      |
>>   Hapache
>>      |
>>   Iapache
>>
>> The Apache committers locates the contributor repository on github 
>> or
>> elsewhere, and runs "git pull" in his own workspace. He will then 
>> grab
>> the full history of the contributor work and will get this history 
>> in
>> his local repository
>>
>>   Aapache
>>      |
>>   Bapache
>>      |
>>   Capache
>>      |
>>   Dapache
>>      |---------------|
>>   Hapache         Econtrib
>>      |               |
>>   Iapache         Fcontrib
>>                      |
>>                   Gcontrib
>>
>> All intermediates state are redily accessible and the committer can
>> decide what to do. He can merge everything, merge only parts, rely 
>> on
>> git diff to show up the differences even between commits that do not
>> belong to the same path. If there is no conflict, it is possible 
>> from
>> this state to do a single "git merge" and push it to the reference
>> repository. In this case, the reference repository history will 
>> become:
>>
>>   Aapache
>>      |
>>   Bapache
>>      |
>>   Capache
>>      |
>>   Dapache
>>      |---------------|
>>   Hapache         Econtrib
>>      |               |
>>   Iapache         Fcontrib
>>      |               |
>>      |            Gcontrib
>>      |---------------|
>>              |
>>            Jmerged
>>
>>>
>>> So I could say that the "limitations" of the current system have 
>>> the
>>> good consequence that contributors and committers are _obliged_ to 
>>> work
>>> together. [E.g. the contributor of an old patch must stick around 
>>> or,
>>> if he didn't, that could hint that it could be "risky" to commit a
>>> (non-trivial) code with nobody to maintain it.]
>>
>> If the committer prefers, of course in this case he can ask the
>> contributor to do the merge by himself. This is however also simpler 
>> for
>> the contributer as he does not have to fiddle with loose file. He 
>> will
>> be able to do the exact same command the developer would have run 
>> (i.e.
>> git merge in this case), resolve the conflicts, and then ask again 
>> for
>> the pull request, but this time providinf Jmerged and not Gcontrib 
>> to
>> the project.
>>
>>> Thus, IIUC, in the new system the committers will somehow be 
>>> expected to do
>>> more work, since Git makes it possible to "easily" integrate/merge 
>>> (?)
>>> individual repositories.
>>
>> No, they can ask contributors to do it. All repositories are equal, 
>> so
>> running the git merge can be run by the committer or the 
>> contributor.
>> The important thing is that at the end only the committer as the 
>> write
>> access that allow him to "git push" to the Apache reference 
>> repository.
>>
>>>
>>>> This is enough to get started. You can then learn gradually how to 
>>>> play
>>>> with branches, tags, remotes.
>>>
>>> Gradually?
>>> That's my fear (and problem). I should be able to prepare a release 
>>> by
>>> simply following the (updated) recipe in 
>>> "doc/release/release.howto.txt",
>>> i.e. without any assumption which a seasoned Git-user would 
>>> consider
>>> trivial.
>>
>> If we adopt git, of course the seasoned Git-user (read luc) would 
>> update
>> the necessary parts in this howto.
>
> Would it be possible to create a generic Git doc that could be used 
> by
> any component?
> That would be best done in advance of starting to use Git.
>
>> best regards,
>> Luc

Thanks for all the explanations.

If the "reference" repository is controlled by Git, could it be 
possible
to use svn commands too?  Or would it be too complicated to install the
translation tools?

If the repository is moved to Git, what about the change history?

Best regards,
Gilles


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message