On 27 November 2013 13:37, Luc Maisonobe <l...@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, >> 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
