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.
best regards,
Luc
>
>
> Thanks,
> Gilles
>
> [1] Describing one and only one fail-safe way.
>
>>
>> http://git-scm.com/book
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
