Issue 46120044: CG: basic cleanup
|
Created:
11 years, 3 months ago by janek Modified:
11 years, 2 months ago CC:
lilypond-devel_gnu.org Visibility:
Public. |
DescriptionCG: rename 'commit access' to 'push access'
'commit access' is svn terminology. We're using git,
and in git everyone can commit but not everyone can *push*.
CG merge duplicated sections about conflicts and branches
* merge 'resolving conflicts' with 'merging conflicts'
* merge 'Organization of remote branches' with 'Other branches'
CG: remove obsolete git info
...most of these istructions were valid for git version ~1.5;
nowadays working with git is much simpler (also on Windows).
Patch Set 1 #
Total comments: 14
MessagesTotal messages: 9
looks fine https://codereview.appspot.com/46120044/diff/1/Documentation/contributor/sour... File Documentation/contributor/source-code.itexi (left): https://codereview.appspot.com/46120044/diff/1/Documentation/contributor/sour... Documentation/contributor/source-code.itexi:729: @end example I have often looked in "Downloading Individual Branches" hoping to find the command to download a new branch (such as dev/janek/spacing or release/2.18) that has appeared on the repository. This seems to be the only such example of that command, so maybe keep just this example in this section. https://codereview.appspot.com/46120044/diff/1/Documentation/contributor/sour... Documentation/contributor/source-code.itexi:2162: Git works under Windows (I used it successfully for some documentation patches before getting around to installing Linux). You might want to keep the text down to here, as a pointer for one option that new contributors might want to consider.
Sign in to reply to this message.
LGTM https://codereview.appspot.com/46120044/diff/1/Documentation/contributor/sour... File Documentation/contributor/source-code.itexi (left): https://codereview.appspot.com/46120044/diff/1/Documentation/contributor/sour... Documentation/contributor/source-code.itexi:729: @end example On 2014/01/01 05:44:44, Keith wrote: > I have often looked in "Downloading Individual Branches" hoping to find the > command to download a new branch (such as dev/janek/spacing or release/2.18) > that has appeared on the repository. As far as I understand, as long as you began with a git clone (which we started recommending 1 or 2 years ago, for this reason), you automatically download the branches. To see the actual files on your computer, you just need to checkout the new branch. (the whole "downloading individual branches" thing arose because in 2005 or so, I wasn't familiar with git and was paranoid about "wasting" my bandwidth. No joke, I read slashdot using lynx back then to avoid loading images) If that info is correct, the CG should be changed so that it contains and is easy to find that info. https://codereview.appspot.com/46120044/diff/1/Documentation/contributor/sour... File Documentation/contributor/source-code.itexi (right): https://codereview.appspot.com/46120044/diff/1/Documentation/contributor/sour... Documentation/contributor/source-code.itexi:123: command-line version of Git 1.7 or higher.} just curious, what changed in git 1.5 vs. 1.7 that's important to these instructions? https://codereview.appspot.com/46120044/diff/1/Documentation/contributor/sour... Documentation/contributor/source-code.itexi:1390: @emph{How to resolve conflicts} in @command{git merge} man page. I think this is likely to confuse / discourage most new contributors, but it's certainly an improvement on the previous "this is a stub" material.
Sign in to reply to this message.
Fine, apart from throwing away the Windows section. https://codereview.appspot.com/46120044/diff/1/Documentation/contributor/sour... File Documentation/contributor/source-code.itexi (left): https://codereview.appspot.com/46120044/diff/1/Documentation/contributor/sour... Documentation/contributor/source-code.itexi:2120: @section Git on Windows If you remove this section there are no instructions left for new developers on Windows, no instructions for using git gui and no instructions for using gitk, facilities I use all the time. All my documentation work has been done under Windows, and potential doc writers using Windows could do the same. Why delete it? Trevor
Sign in to reply to this message.
https://codereview.appspot.com/46120044/diff/1/Documentation/contributor/sour... File Documentation/contributor/source-code.itexi (left): https://codereview.appspot.com/46120044/diff/1/Documentation/contributor/sour... Documentation/contributor/source-code.itexi:729: @end example On 2014/01/01 06:08:09, Graham Percival wrote: > as long as you began with a git clone ... Okay. I am still set up the old way, fetching branches individually (which is rather inconvenient) and did not realize that `git clone` sets up a wild-card pattern for fetching, so that even branches newly-created after the clone get fetched. The new way sounds better. Janek, when people start with `git clone` do they also get a staging branch that tracks the one on savannah? I think we still want at least one mention of how to set up a 'staging' branch to track origin/staging, git checkout --track -b staging origin/staging
Sign in to reply to this message.
2014/1/1 <k-ohara5a5a@oco.net>: > > Janek, when people start with `git clone` do they also get a staging > branch that tracks the one on savannah? > I think we still want at least one mention of how to set up a 'staging' > branch to track origin/staging, > git checkout --track -b staging origin/staging you can set up any branch to track origin/staging (or origin/master or origin/dev/janek/fancy-feature or whatever) directly. I always set up my topic branches so. p
Sign in to reply to this message.
Benkő Pál <benko.pal@gmail.com> writes: > 2014/1/1 <k-ohara5a5a@oco.net>: >> >> Janek, when people start with `git clone` do they also get a staging >> branch that tracks the one on savannah? >> I think we still want at least one mention of how to set up a 'staging' >> branch to track origin/staging, >> git checkout --track -b staging origin/staging > > you can set up any branch to track origin/staging (or origin/master > or origin/dev/janek/fancy-feature or whatever) directly. I always set > up my topic branches so. Don't track staging, or you'll end up pushing bad staging commits back into staging whenever staging has to be reset. -- David Kastrup
Sign in to reply to this message.
Good, except we want to keep the information that Git works usefully on Windows. https://codereview.appspot.com/46120044/diff/1/Documentation/contributor/sour... File Documentation/contributor/source-code.itexi (left): https://codereview.appspot.com/46120044/diff/1/Documentation/contributor/sour... Documentation/contributor/source-code.itexi:729: @end example > Don't track staging, or .. Okay. Then when we don't need to keep any of these example commands above.
Sign in to reply to this message.
On 01/01/14 21:35, David Kastrup wrote: > Benkő Pál <benko.pal@gmail.com> writes: > >> 2014/1/1 <k-ohara5a5a@oco.net>: >>> Janek, when people start with `git clone` do they also get a staging >>> branch that tracks the one on savannah? >>> I think we still want at least one mention of how to set up a 'staging' >>> branch to track origin/staging, >>> git checkout --track -b staging origin/staging >> you can set up any branch to track origin/staging (or origin/master >> or origin/dev/janek/fancy-feature or whatever) directly. I always set >> up my topic branches so. > Don't track staging, or you'll end up pushing bad staging commits back > into staging whenever staging has to be reset. > And this should go into the CG too :) James
Sign in to reply to this message.
https://codereview.appspot.com/46120044/diff/1/Documentation/contributor/admi... File Documentation/contributor/administration.itexi (right): https://codereview.appspot.com/46120044/diff/1/Documentation/contributor/admi... Documentation/contributor/administration.itexi:219: instructions in the CG at @ref{Push access}. Do not set It's not just about pushing. The Savannah terminology on the general Git pages and the project specific pages is "project member access" or "member access" in contrast to "anonymous access". https://codereview.appspot.com/46120044/diff/1/Documentation/contributor/admi... Documentation/contributor/administration.itexi:1574: @subsubheading Push git access This would seem to warrant changing as well. https://codereview.appspot.com/46120044/diff/1/Documentation/contributor/sour... File Documentation/contributor/source-code.itexi (right): https://codereview.appspot.com/46120044/diff/1/Documentation/contributor/sour... Documentation/contributor/source-code.itexi:123: command-line version of Git 1.7 or higher.} On 2014/01/01 06:08:09, Graham Percival wrote: > just curious, what changed in git 1.5 vs. 1.7 that's important to these > instructions? Possibly the default behavior for git push without arguments. Also possible git clone behavior. At any rate, LilyDev seems to be 1.7, so we probably are not all that informed about 1.5 any more. https://codereview.appspot.com/46120044/diff/1/Documentation/contributor/sour... Documentation/contributor/source-code.itexi:654: The branches are kept for archival reasons. That's not actually correct. It's more like "These branches are for making stable releases. They are only to be changed by their respective maintainers." https://codereview.appspot.com/46120044/diff/1/Documentation/contributor/sour... Documentation/contributor/source-code.itexi:1554: @node Push access Member access. https://codereview.appspot.com/46120044/diff/1/Documentation/contributor/sour... Documentation/contributor/source-code.itexi:1745: git config push.default matching That's actually the worst possible setting in my experience since it tends to push stuff you did not intend to push. The Git documentation explicitly says this is unsuitable for shared repositories: · matching - push all branches having the same name in both ends. This is for those who prepare all the branches into a publishable shape and then push them out with a single command. It is not appropriate for pushing into a repository shared by multiple users, since locally stalled branches will attempt a non-fast forward push if other users updated the branch. This is currently the default, but Git 2.0 will change the default to simple. I think we should rather recommend "simple" here. It's always possible to give explicit instructions, so it is not like the user will be blocked. "upstream" has the disadvantage that it will push feature branches straight to master. So "simple" is best.
Sign in to reply to this message.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
