<jupyter_start><jupyter_text>Basic Tricks > Summary Rather than diving into a sea of Git commands, use these elementary examples toget your feet wet. Despite their simplicity, each of them are useful.Indeed, in my first months with Git I never ventured beyond the material in this chapter. Saving State About to attempt something drastic? Before you do, take a snapshot of all filesin the current directory with:<jupyter_code>! git init
 ! git add .
 ! git commit -m "My first backup"<jupyter_output><empty_output><jupyter_text>Now if your new edits go awry, restore the pristine version:<jupyter_code>! git reset --hard<jupyter_output><empty_output><jupyter_text>To save the state again:<jupyter_code>! git commit -a -m "Another backup"<jupyter_output><empty_output><jupyter_text>Add, Delete, Rename The above only keeps track of the files that were present when you first ran *git add*. If you add new files or subdirectories, you'll have to tell Git:<jupyter_code>! git add readme.txt Documentation<jupyter_output><empty_output><jupyter_text>Similarly, if you want Git to forget about certain files:<jupyter_code>! git rm kludge.h obsolete.c
 ! git rm -r incriminating/evidence/<jupyter_output><empty_output><jupyter_text>Git deletes these files for you if you haven't already.Renaming a file is the same as removing the old name and adding the new name. There's also the shortcut *git mv* which has the same syntax as the *mv* command. For example:<jupyter_code>! git mv bug.c feature.c<jupyter_output><empty_output><jupyter_text>Advanced Undo/Redo Sometimes you just want to go back and forget about every change past a certain point because they're all wrong. Then:<jupyter_code>! git log<jupyter_output><empty_output><jupyter_text>shows you a list of recent commits, and their SHA1 hashes:----------------------------------commit 766f9881690d240ba334153047649b8b8f11c664Author: Bob Date:   Tue Mar 14 01:59:26 2000 -0800    Replace printf() with write().commit 82f5ea346a2e651544956a8653c0f58dc151275cAuthor: Alice Date:   Thu Jan 1 00:00:00 1970 +0000    Initial commit.----------------------------------The first few characters of the hash are enough to specify the commit;alternatively, copy and paste the entire hash. Type:<jupyter_code>! git reset --hard 766f<jupyter_output><empty_output><jupyter_text>to restore the state to a given commit and erase all newer commits from the record permanently.Other times you want to hop to an old state briefly. In this case, type:<jupyter_code>! git checkout 82f5<jupyter_output><empty_output><jupyter_text>This takes you back in time, while preserving newer commits. However, like time travel in a science-fiction movie, if you now edit and commit, you will be in an alternate reality, because your actions are different to what they were the first time around.This alternate reality is called a 'branch', and >. For now, just remember that<jupyter_code>! git checkout master<jupyter_output><empty_output><jupyter_text>will take you back to the present. Also, to stop Git complaining, alwayscommit or reset your changes before running checkout.To take the computer game analogy again:- *`git reset --hard`*: load an old save and delete all saved games newer than the one just loaded.- *`git checkout`*: load an old game, but if you play on, the game state will deviate from the newer saves you made the first time around. Any saved games you make now will end up in a separate branch representing the alternate reality you have entered. >.You can choose only to restore particular files and subdirectories by appending them after the command:<jupyter_code>! git checkout 82f5 some.file another.file<jupyter_output><empty_output><jupyter_text>Take care, as this form of *checkout* can silently overwrite files. Toprevent accidents, commit before running any checkout command, especially whenfirst learning Git. In general, whenever you feel unsure about any operation, Git command or not, first run *git commit -a*.Don't like cutting and pasting hashes? Then use:<jupyter_code>! git checkout :/"My first b"<jupyter_output><empty_output><jupyter_text>to jump to the commit that starts with a given message.You can also ask for the 5th-last saved state:<jupyter_code>! git checkout master~5<jupyter_output><empty_output><jupyter_text>Reverting In a court of law, events can be stricken from the record. Likewise, you can pick specific commits to undo.<jupyter_code>! git commit -a
 ! git revert 1b6d<jupyter_output><empty_output><jupyter_text>will undo just the commit with the given hash. The revert is recorded as a newcommit, which you can confirm by running *git log*. Changelog Generation Some projects require a http://en.wikipedia.org/wiki/Changelog[changelog].Generate one by typing:<jupyter_code>! git log > ChangeLog<jupyter_output><empty_output><jupyter_text>Downloading Files Get a copy of a project managed with Git by typing:<jupyter_code>! git clone git://server/path/to/files<jupyter_output><empty_output><jupyter_text>For example, to get all the files I used to create this site:<jupyter_code>! git clone git://git.or.cz/gitmagic.git<jupyter_output><empty_output><jupyter_text>We'll have much to say about the *clone* command soon. The Bleeding Edge If you've already downloaded a copy of a project using *git clone*, you can upgrade to the latest version with:<jupyter_code>! git pull<jupyter_output><empty_output><jupyter_text>Instant Publishing Suppose you've written a script you'd like to share with others. You could just tell them to download from your computer, but if they do so while you're improving the script or making experimental changes, they could wind up in trouble.  Of course, this is why release cycles exist. Developers may work on a project frequently, but they only make the code available when they feel it is presentable.To do this with Git, in the directory where your script resides:<jupyter_code>! git init
 ! git add .
 ! git commit -m "First release"<jupyter_output><empty_output><jupyter_text>Then tell your users to run:<jupyter_code>! git clone your.computer:/path/to/script<jupyter_output><empty_output><jupyter_text>to download your script. This assumes they have ssh access. If not, run *git daemon* and tell your users to instead run:<jupyter_code>! git clone git://your.computer/path/to/script<jupyter_output><empty_output><jupyter_text>From now on, every time your script is ready for release, execute:<jupyter_code>! git commit -a -m "Next release"<jupyter_output><empty_output><jupyter_text>and your users can upgrade their version by changing to the directory containing your script and typing:<jupyter_code>! git pull<jupyter_output><empty_output><jupyter_text>Your users will never end up with a version of your script you don't want them to see. What Have I Done? Find out what changes you've made since the last commit with:<jupyter_code>! git diff<jupyter_output><empty_output><jupyter_text>Or since yesterday:<jupyter_code>! git diff "@{yesterday}"<jupyter_output><empty_output><jupyter_text>Or between a particular version and 2 versions ago:<jupyter_code>! git diff 1b6d "master~2"<jupyter_output><empty_output><jupyter_text>In each case the output is a patch that can be applied with *git apply*.Try also:<jupyter_code>! git whatchanged --since="2 weeks ago"<jupyter_output><empty_output><jupyter_text>Often I'll browse history with http://sourceforge.net/projects/qgit[qgit] instead, due to its slick photogenic interface, or http://jonas.nitro.dk/tig/[tig], a text-mode interface that works well over slow connections. Alternatively, install a web server, run *git instaweb* and fire up any web browser. Exercise Let A, B, C, D be four successive commits where B is the same as A except some files have been removed. We want to add the files back at D. How can we do this?There are at least three solutions. Assuming we are at D:  1. The difference between A and B are the removed files. We can create a patch representing this difference and apply it:<jupyter_code>! git diff B A | git apply<jupyter_output><empty_output><jupyter_text>2. Since we saved the files back at A, we can retrieve them:<jupyter_code>! git checkout A foo.c bar.h<jupyter_output><empty_output><jupyter_text>3. We can view going from A to B as a change we want to undo:<jupyter_code>! git revert B<jupyter_output><empty_output>
{'fraction_non_alphanumeric': 0.07918769526556116, 'fraction_numerical': 0.0136986301369863, 'mean_word_length': 5.543238993710692, 'pattern_counts': {'":': 0, '<': 121, '<?xml version=': 0, '>': 125, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 5, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'chain_length': '30', 'dir': 'jupyter-structured-clean-dedup', 'id': '35241', 'license': 'Apache-2.0', 'n_tokens_mistral': 2558, 'n_tokens_neox': 2415, 'n_words': 1049, 'path': '03_basic.ipynb', 'repo_name': 'StephanRempel/git_magic', 'size': '8322'}