| Apr | MAY | Jun |
| 04 | ||
| 2020 | 2021 | 2022 |
COLLECTED BY
Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
History is littered with hundreds of conflicts over the future of a community, group, location or business that were "resolved" when one of the parties stepped ahead and destroyed what was there. With the original point of contention destroyed, the debates would fall to the wayside. Archive Team believes that by duplicated condemned data, the conversation and debate can continue, as well as the richness and insight gained by keeping the materials. Our projects have ranged in size from a single volunteer downloading the data to a small-but-critical site, to over 100 volunteers stepping forward to acquire terabytes of user-created data to save for future generations.
The main site for Archive Team is at archiveteam.org and contains up to the date information on various projects, manifestos, plans and walkthroughs.
This collection contains the output of many Archive Team projects, both ongoing and completed. Thanks to the generous providing of disk space by the Internet Archive, multi-terabyte datasets can be made available, as well as in use by the Wayback Machine, providing a path back to lost websites and work.
Our collection has grown to the point of having sub-collections for the type of data we acquire. If you are seeking to browse the contents of these collections, the Wayback Machine is the best first stop. Otherwise, you are free to dig into the stacks to see what you may find.
The Archive Team Panic Downloads are full pulldowns of currently extant websites, meant to serve as emergency backups for needed sites that are in danger of closing, or which will be missed dearly if suddenly lost due to hard drive crashes or server failures.
Collection: Archive Team: URLs
●Python »
Python Developer's Guide »
autocrlf on Windows
●Creating and Switching Branches
●Deleting Branches
●Renaming Branch
●Staging and Committing Files
●Reverting Changes
●Stashing Changes
●Committing Changes
●Pushing Changes
●Creating a Pull Request
●Updating your CPython Fork
●Applying a Patch from Mercurial to Git
●Downloading Other’s Patches
●Accepting and Merging a Pull Request
●Backporting Merged Changes
●Editing a Pull Request Prior to Merging
Fork on the top right.
(三)When asked where to fork the repository, choose to fork it to your username.
(四)Your forked CPython repository will be created at https://github.com/<username>/cpython.
git clone git@github.com:<username>/cpython.git
It is also recommended to configure an upstream remote repository:
cd cpython git remote add upstream git@github.com:python/cpython.gitYou can also use SSH-based or HTTPS-based URLs.
git remote -v
You should have two remote repositories: origin pointing to your forked CPython repository,
and upstream pointing to the official CPython repository:
origin git@github.com:<username>/cpython.git (fetch) origin git@github.com:<username>/cpython.git (push) upstream git@github.com:python/cpython.git (fetch) upstream git@github.com:python/cpython.git (push)
git config --global user.name "Your Name"
git config --global user.email your.email@example.com
The --global flag sets these parameters globally while
the --local flag sets them only for the current project.
autocrlf on Windows¶
autocrlf option will fix automatically any Windows-specific line endings.
This should be enabled on Windows, since the public repository has a hook which
will reject all changesets having the wrong line endings:
git config --global core.autocrlf input
main branch.
Create a new branch and switch to it:
# creates a new branch off main and switch to it git checkout -b <branch-name> mainThis is equivalent to:
# create a new branch from main, without checking it out git branch <branch-name> main # check out the branch git checkout <branch-name>To find the branch you are currently on:
git branch
The current branch will have an asterisk next to the branch name. Note, this
will only list all of your local branches.
To list all the branches, including the remote branches:
git branch -a
To switch to a different branch:
git checkout <another-branch-name>
Other releases are just branches in the repository. For example, to work
on the 2.7 release from the upstream remote:
git checkout -b 2.7 upstream/2.7
git checkout main git branch -D <branch-name>To delete a remote branch:
git push origin -d <branch-name>
You may specify more than one branch for deletion.
mastertomain
after the Python 3.10b1 release. If you had cloned the repository before this
change, you can rename your local branch as follows:
git branch -m master main git fetch upstream git branch -u upstream/main main
git status
To stage the files to be included in your commit:
git add <filename1> <filename2>
To commit the files that have been staged (done in step 2):
git commit -m "bpo-XXXX: This is the commit message."
git checkout <filename>
If the change has been committed, and now you want to reset it to whatever
the origin is at:
git reset --hard HEAD
git stash
To re-apply the last stashed change:
git stash pop
git add <filename>
Commit the files:
git commit -m "<message>"
git checkout <branch-name> git push origin <branch-name>
New pull request button.
(三)Click the compare across forks link.
(四)Select the base repository: python/cpython and base branch: main.
(五)Select the head repository: <username>/cpython and head branch: the branch
containing your changes.
(六)Press the Create pull request button.
python:mainto<username>:main as the authors of the patches will
get notified unnecessarily.
Solution:
git checkout main git pull upstream main git push origin mainNote For the above commands to work, please follow the instructions found in the Get the source code section Another scenario: ●You created
some-branch some time ago.
●Time passes.
●You made some commits to some-branch.
●Meanwhile, there are recent changes from the upstream CPython repository.
●You want to incorporate the recent changes from the upstream CPython
repository into some-branch.
Solution:
git checkout some-branch git fetch upstream git merge upstream/main git push origin some-branchYou may see error messages like “CONFLICT” and “Automatic merge failed;” when you run
git merge upstream/main.
When it happens, you need to resolve conflict. See these articles about resolving conflicts:
●About merge conflicts
●Resolving a merge conflict using the command line
git apply /path/to/issueNNNN-git.patch
If there are errors, update to a revision from when the patch was
created and then try the git apply again:
git checkout $(git rev-list -n 1 --before="yyyy-mm-dd hh:mm:ss" main) git apply /path/to/issueNNNN-git.patchIf the patch still won’t apply, then a patch tool will not be able to apply the patch and it will need to be re-implemented manually. If the apply was successful, create a new branch and switch to it. Stage and commit the changes. If the patch was applied to an old revision, it needs to be updated and merge conflicts need to be resolved:
git rebase main git mergetoolPush the changes and open a pull request.
$ git config --global alias.pr '!sh -c "git fetch upstream pull/${1}/head:pr_${1} && git checkout pr_${1}" -'On Windows, reverse the single (
') and double (") quotes:
git config --global alias.pr "!sh -c 'git fetch upstream pull/${1}/head:pr_${1} && git checkout pr_${1}' -"The alias only needs to be done once. After the alias is set up, you can get a local copy of a pull request as follows:
git pr <pr_number>
Note
hub command line utility makes this
workflow very easy. You can check out the branch by
hub prcheckout <pr_number> [<branch_name>].
This command configures remote URL for the branch too.
So you can git push if the pull request author checked
“Allow edits from maintainers” when creating the pull request.
Squash and merge
button.
Replace the reference to GitHub pull request #NNNN with GH-NNNN.
If the title is too long, the pull request number can be added to the
message body.
Adjust and clean up the commit message.
Example of good commit message:
bpo-12345: Improve the spam module (GH-777) * Add method A to the spam module * Update the documentation of the spam moduleExample of bad commit message:
bpo-12345: Improve the spam module (#777) * Improve the spam module * merge from main * adjust code based on review comment * rebasedNote How to Write a Git Commit Message is a nice article describing how to write a good commit message. Press the
Confirm squash and merge button.
main. It is usually indicated
by the label needs backport toX.Y on the pull request itself.
Use the utility script
cherry_picker.py
from the core-workflow
repository to backport the commit.
The commit hash for backporting is the squashed commit that was merged to
the main branch. On the merged pull request, scroll to the bottom of the
page. Find the event that says something like:
<core_developer> merged commit <commit_sha1> into python:main <sometime> ago.
By following the link to <commit_sha1>, you will get the full commit hash.
Alternatively, the commit hash can also be obtained by the following git
commands:
git fetch upstream
git rev-parse ":/bpo-12345"
The above commands will print out the hash of the commit containing
"bpo-12345" as part of the commit message.
When formatting the commit message for a backport commit: leave the original
one as is and delete the number of the backport pull request.
Example of good backport commit message:
bpo-12345: Improve the spam module (GH-777) * Add method A to the spam module * Update the documentation of the spam module (cherry picked from commit 62adc55)Example of bad backport commit message:
bpo-12345: Improve the spam module (GH-777) (#888) * Add method A to the spam module * Update the documentation of the spam module
Misc/ACKS.
To edit an open pull request that targets main:
In the pull request page, under the description, there is some information
about the contributor’s forked CPython repository and branch name that will be useful later:
<contributor> wants to merge 1 commit into python:main from <contributor>:<branch_name>
Fetch the pull request, using the git pr alias:
git pr <pr_number>
This will checkout the contributor’s branch at <pr_number>.
Make and commit your changes on the branch. For example, merge in changes
made to main since the PR was submitted (any merge commits will be
removed by the later Squash and Merge when accepting the change):
git fetch upstream
git merge upstream/main
git add <filename>
git commit -m "<message>"
Push the changes back to the contributor’s PR branch:
git push git@github.com:<contributor>/cpython <pr_number>:<branch_name>
Optionally, delete the PR branch.
autocrlf on Windows
●32.6. Creating and Switching Branches
●32.7. Deleting Branches
●32.8. Renaming Branch
●32.9. Staging and Committing Files
●32.10. Reverting Changes
●32.11. Stashing Changes
●32.12. Committing Changes
●32.13. Pushing Changes
●32.14. Creating a Pull Request
●32.15. Updating your CPython Fork
●32.16. Applying a Patch from Mercurial to Git
●32.17. Downloading Other’s Patches
●32.18. Accepting and Merging a Pull Request
●32.19. Backporting Merged Changes
●32.20. Editing a Pull Request Prior to Merging
autocrlf on Windows
●32.6. Creating and Switching Branches
●32.7. Deleting Branches
●32.8. Renaming Branch
●32.9. Staging and Committing Files
●32.10. Reverting Changes
●32.11. Stashing Changes
●32.12. Committing Changes
●32.13. Pushing Changes
●32.14. Creating a Pull Request
●32.15. Updating your CPython Fork
●32.16. Applying a Patch from Mercurial to Git
●32.17. Downloading Other’s Patches
●32.18. Accepting and Merging a Pull Request
●32.19. Backporting Merged Changes
●32.20. Editing a Pull Request Prior to Merging
●33. Appendix: Topics
●Python »
Python Developer's Guide »