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.
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"?
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?
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.]
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.
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.
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
