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.
