@@ -268,23 +268,6 @@ understands the justification for the change). Also, if a non-core developer
268
268
contributed to the resolution, it is good practice to credit them.
269
269
270
270
271
- Reverting a Commit
272
- ------------------
273
-
274
- To revert a merged pull request, press the ``Revert `` button at the bottom of
275
- the pull request. It will bring up the page to create a new pull request where
276
- the commit can be reverted. It also creates a new branch on the main CPython
277
- repository. Delete the branch once the pull request has been merged.
278
-
279
- Always include the reason for reverting the commit to help others understand
280
- why it was done. The reason should be included as part of the commit message,
281
- for example::
282
-
283
- Revert bpo-NNNN: Fix Spam Module (GH-111)
284
-
285
- Reverts python/cpython#111.
286
- Reason: This commit broke the buildbot.
287
-
288
271
289
272
Working with Git _
290
273
=================
@@ -313,107 +296,6 @@ into a state you aren't happy with.
313
296
.. _Git : https://git-scm.com/
314
297
315
298
316
- Minimal Configuration
317
- ---------------------
318
-
319
- If you use Git as a committer of patches (your own or others), you should
320
- set up some basic options. Here are the minimal options you need to activate:
321
-
322
- * Your *name * and *email *: these settings defines what will be used when you
323
- commit changes::
324
-
325
- git config --global user.name "Your Name"
326
- git config --global user.email [email protected]
327
-
328
- ``--global `` flag sets configuration options at a global level, if instead you
329
- want to set it at a project level use ``--local ``, instead.
330
-
331
- * *Under Windows *, you should also enable the *autocrlf * option, which will
332
- fix any Windows-specific line endings your text editor might insert when you
333
- create or modify versioned files. The public repository has a hook which
334
- will reject all changesets having the wrong line endings, so enabling this
335
- extension on your local computer is in your best interest.
336
- ::
337
-
338
- git config --global core.autocrlf input
339
-
340
-
341
- Remotes Setup
342
- -------------
343
-
344
-
345
- .. _remote-configuration :
346
-
347
- Configuration
348
- '''''''''''''
349
-
350
- There are several possible ways how to set up your git repository. This section
351
- discusses the simplest approach of having a single directory with two remotes,
352
- one pointing to private fork, the other one being the official repository.
353
-
354
- Assuming you have :ref: `cloned the official repository <checkout >` here is how
355
- your current setup should look like::
356
-
357
- $ git remote -v # show remotes
358
- origin https://github.com/python/cpython (fetch)
359
- origin https://github.com/python/cpython (push)
360
-
361
- You can have multiple remotes defined for a single repository, the usual approach
362
- is to have ``origin `` pointing to your :ref: `private fork <forking >`, and ``upstream ``
363
- pointing to the official repository. To do so, here are the steps needed to have
364
- that setup::
365
-
366
- git remote set-url origin https://github.com/<your-username>/cpython
367
- git remote add upstream https://github.com/python/cpython
368
-
369
- After that, your remotes configuration should look like this::
370
-
371
- $ git remote -v # show remotes
372
- origin https://github.com/<your-username>/cpython (fetch)
373
- origin https://github.com/<your-username>/cpython (push)
374
- upstream https://github.com/python/cpython (fetch)
375
- upstream https://github.com/python/cpython (push)
376
-
377
- At any point in time you can use SSH-based URL instead of HTTPS-based ones.
378
-
379
-
380
- .. _committing-push-changes :
381
-
382
- Pushing changes
383
- '''''''''''''''
384
-
385
- You have two remotes configured (see previous section for setup). Publishing
386
- your changes to any of them is as simple as specifying the name of the remote
387
- upon your push. Assuming I am working on a local branch ``bug1234 `` and I want to
388
- push it to my private fork I do::
389
-
390
- git push origin bug1234
391
-
392
- Option ``-u|--set-upstream `` creates a remote-tracking branch that tracks what
393
- have been pushed to ``origin ``::
394
-
395
- git push -u origin bug1234
396
-
397
- That allows to avoid rebasing beyond already pushed commits.
398
- ``git status --branch `` and ``git branch --verbose `` remind that the branch(es)
399
- have not pushed commits.
400
-
401
-
402
- Synchronizing remotes
403
- '''''''''''''''''''''
404
-
405
- To synchronize your fork, from the official repository you need to execute following
406
- commands::
407
-
408
- git fetch upstream # fetch remote changes
409
- git checkout master # checkout your current master branch
410
- git merge upstream/master # merge remote changes into your local master branch
411
- git push origin master # publish changes to your private fork
412
-
413
- The above steps can be executed against any branch you wish to, just replace master
414
- with an appropriate branch name.
415
-
416
-
417
299
.. _committing-active-branches :
418
300
419
301
Active branches
@@ -454,34 +336,19 @@ Developers can apply labels to GitHub pull requests).
454
336
.. _cherry_picker.py : https://github.com/python/core-workflow/tree/master/cherry_picker
455
337
456
338
457
- .. _forking :
458
-
459
- Forking repository
460
- ------------------
461
-
462
- Forking a repository on GitHub is as simple as clicking Fork button in the right
463
- upper corner at https://github.com/python/cpython.
464
-
339
+ Reverting a Merged Pull Request
340
+ -------------------------------
465
341
466
- Maintaining a repository
467
- ------------------------
342
+ To revert a merged pull request, press the ``Revert `` button at the bottom of
343
+ the pull request. It will bring up the page to create a new pull request where
344
+ the commit can be reverted. It also creates a new branch on the main CPython
345
+ repository. Delete the branch once the pull request has been merged.
468
346
469
- The Git object database and other files/directories under ``.git `` require
470
- periodic maintenance and cleanup. For example, commit editing leaves
471
- unreferenced objects (dangling objects, in git terminology) and these
472
- objects should be pruned to avoid collecting cruft in the DB. The
473
- command ``git gc `` is used for maintenance. Git automatically runs
474
- ``git gc --auto `` as a part of some commands to do quick maintenance.
475
- Users are recommended to run ``git gc --aggressive `` from time to
476
- time; ``git help gc `` recommends to run it every few hundred
477
- changesets; for CPython it should be something like once a week
478
- (GitHub itself runs the command weekly, so new checkouts do not need to
479
- perform this step).
347
+ Always include the reason for reverting the commit to help others understand
348
+ why it was done. The reason should be included as part of the commit message,
349
+ for example::
480
350
481
- ``git gc --aggressive `` not only removes dangling objects, it also
482
- repacks object database into indexed and better optimized pack(s); it
483
- also packs symbolic references (branches and tags).
351
+ Revert bpo-NNNN: Fix Spam Module (GH-111)
484
352
485
- From time to time run ``git fsck --strict `` to verify integrity of
486
- the database. ``git fsck `` may produce a list of dangling objects;
487
- that's not an error, just a reminder to perform regular maintenance.
353
+ Reverts python/cpython#111.
354
+ Reason: This commit broke the buildbot.
0 commit comments