Le 27/11/2013 13:47, Gilles a écrit : > What is "stash", what is "stash pop"?
This is equivalent to the shelving feature on the Subversion 1.10 roadmap. This allows you to put aside the local modifications and pull them back later. This is done without committing anything. > 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? I don't have much practical experience on this but I'll try to explain: - pull request vs .patch: if the .patch doesn't apply to your tree you are out of luck (this is true for any VCS). A pull request being a chain of commits branched on your development history, Git is able to figure out what to change. Subversion has a similar merge tracking feature, but that's not available to external contributions. - rebasing: it's possible to 'rebase' a branch on the current tree, that's, Git replays the modifications on the branch starting from the trunk and stops when a conflicts occurs. Once the conflict is resolved you can resume the process. This allows you to refresh step by step the pull request. If the contributor has taken care to make small commits it's much easier than refreshing one big patch. > 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. Not necessarily. I tend to asks the contributors to refresh their pull requests if they don't apply cleanly. It's up to you. > 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. Well, that's an objective of the [cli] migration to Git, it will enables us to prepare a recipe to walk though the process easily. Emmanuel Bourg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
