Purpose of the problem set
The questions in this problem set are designed not only to give extra practice with the concepts from Lesson 1, but also to help you deepen your understanding of those concepts. Some of the questions will be tricky, and you’re not expected to get every question right on the first try. The purpose is for you to learn, so have fun!
Reconstructing a final file
Suppose you had a file, called file.txt, and you made a copy of this file, named it updated.txt and made some changes to it. Next, suppose you ran diff -u file.txt updated.txt.
The contents of the original file and the output of the diff are below. Given this information, it is possible to reconstruct what the final contents of updated.txt must have been. On the next screen, enter these contents.
Contents of original file.txt
A
B
C
D
E
F
These letters are stand-ins for the actual lines of the file. For example, this file could be a recipe, and the lines could be ingredients. Or the file could be a code file, and each letter could stand for a line of code.
Output of diff -u
--- file.txt 2014-12-03 16:27:41.000000000 -0500
+++ updated.txt 2014-12-03 16:28:11.000000000 -0500
@@ -2,4 +2,6 @@
B
+$
C
-D
+#
+%
E
Just like the letters, the symbols are stand-ins for actual lines.
هل لديك أي أسئلة؟ اذهب إلىمنتديات النقاش مع مجتمع Udacity
Reconstructing a final file
Suppose you had a file, called file.txt, and you made a copy of this file, named it updated.txt and made some changes to it. Next, suppose you ran diff -u file.txt updated.txt.
The contents of the original file and the output of the diff are below. Given this information, it is possible to reconstruct what the final contents of updated.txt must have been. On the next screen, enter these contents.
Contents of original file.txt
A
B
C
D
E
F
These letters are stand-ins for the actual lines of the file. For example, this file could be a recipe, and the lines could be ingredients. Or the file could be a code file, and each letter could stand for a line of code.
Output of diff -u
--- file.txt 2014-12-03 16:27:41.000000000 -0500
+++ updated.txt 2014-12-03 16:28:11.000000000 -0500
@@ -2,4 +2,6 @@
B
+$
C
-D
+#
+%
E
Just like the letters, the symbols are stand-ins for actual lines.
هل لديك أي أسئلة؟ اذهب إلىمنتديات النقاش مع مجتمع Udacity
Final file
The contents of updated.txt must have been
A
B
$
C
#
%
E
F
The lines with plus signs in the diffoutput were added, meaning they were in updated.txt but not file.txt, and the lines with minus signs were removed, meaning they were in file.txt but not updated.txt. Any other lines were unchanged.
Starting from the original file, adding a dollar sign below line B, removing line D, and adding a pound sign and a percent sign above line E gives the file contents shown above.
هل لديك أي أسئلة؟ اذهب إلىمنتديات النقاش مع مجتمع Udacity
هل لديك أي أسئلة؟ اذهب إلىمنتديات النقاش مع مجتمع Udacity
Tracking versions using Git
What if instead of saving a new version of the file named updated.txt, you had been using Git to track your changes to file.txt? On the next screen, select any of the statements that would be true.
هل لديك أي أسئلة؟ اذهب إلىمنتديات النقاش مع مجتمع Udacity
Tracking versions using Git
You would be able to see the difference between the two versions, but you would no longer be able to directly access the old version.
This is false. You could still access the old version of the file by checking out the commit associated with that version. Then the recipe would temporarily revert to its state at the time that commit was made.
Using git diff to compare the two versions would show the same changes as diff -u did in the previous exercise.
This is true. diff -u and git diffshow very similar outputs. Even if the exact format was slightly different, the actual changes indicated would be the same.
The name of the file would change when you saved a second version in Git.
This is false. The name of the file would remain the same. Git does not rename files when you save a new commit. Instead, Git uses the commit IDs to refer to different versions of the files, and you can use git checkout to access old versions of your files.
To save two versions of the file, you would create two commits.
This is true. Commits are Git’s way of saving versions, so to save two different versions, you would create two commits.
هل لديك أي أسئلة؟ اذهب إلىمنتديات النقاش مع مجتمع Udacity
هل لديك أي أسئلة؟ اذهب إلىمنتديات النقاش مع مجتمع Udacity
Git command review
You learned four Git commands in the previous lesson. Each of the four actions on the next screen can be completed using one of the Git commands you learned. For each action, type the Git command you would use to complete that action.
هل لديك أي أسئلة؟ اذهب إلىمنتديات النقاش مع مجتمع Udacity
Git command review
Compare two commits, printing each line that is present in one commit but not the other.
git diff will do this. It takes two arguments – the two commit ids to compare.
Make a copy of an entire Git repository, including the history, onto your own computer.
git clone will do this. It takes one argument – the url of the repository to copy.
Temporarily reset all files in a directory to their state at the time of a specific commit.
git checkout will do this. It takes one argument – the commit ID to restore.
Show the commits made in this repository, starting with the most recent.
git log will do this. It doesn’t take any arguments.
هل لديك أي أسئلة؟ اذهب إلىمنتديات النقاش مع مجتمع Udacity
هل لديك أي أسئلة؟ اذهب إلىمنتديات النقاش مع مجتمع Udacity
Behavior of git clone
For each of the statement on the next screen, select whether it is true if you clone a Git repository, if you copy a directory that is not being tracked using Git, or if it is true in both cases.
هل لديك أي أسئلة؟ اذهب إلىمنتديات النقاش مع مجتمع Udacity
Behavior of git clone
If someone else gives you the location of their directory or repository, you can copy or clone it to your own computer.
This is true for both copying a directory and cloning a repository.
As you saw in the previous lesson, if you have a URL to a repository, you can copy it to your computer using git clone.
For copying a directory, you weren’t expected to know this, but it is possible to copy a directory from one computer to another using the command scp, which stands for “secure copy”. The name was chosen because the scp command lets you securely copy a directory from one computer to another.
The history of changes to the directory or repository is copied.
This is true for cloning a repository, but not for copying a directory. The main reason to use git clonerather than copying the directory is because git clone will also copy the commit history of the repository. However, copying can be done on any directory, whereas git cloneonly works on a Git repository.
If you make changes to the copied directory or cloned repository, the original will not change.
This is true for both copying a directory and cloning a repository. In both cases, you’re making a copy that you can alter without changing the original.
The state of every file in the directory or repository is copied.
This is true for both copying a directory and cloning a repository. In both cases, all the files are copied.
هل لديك أي أسئلة؟ اذهب إلىمنتديات النقاش مع مجتمع Udacity
هل لديك أي أسئلة؟ اذهب إلىمنتديات النقاش مع مجتمع Udacity
Behavior of git log
Suppose you ran git log in a repository. Part of the output is given below. If you were to run git checkout and examine each of these three commits in turn, which ones would you expect to contain code for a mute button?
git log output:
commit 7be5a12f1567866b0d77ccdf2055d1a33831da78
Author: Ellison Leão <el@gmail.com>
Date: Fri Jul 11 12:56:26 2014 -0300
Add sound for the wing.
commit 06d72e1f95f046002ec46f41cf71957227111141
Author: Ellison Leão <el@gmail.com>
Date: Wed Jul 9 23:42:55 2014 -0300
Add mute button.
commit 3d4d45b246aad6a1cd0afaf7cfae26966110727e
Author: Ellison Leão <el@gmail.com>
Date: Mon Jul 7 17:35:47 2014 -0300
Fix leaderboard button
هل لديك أي أسئلة؟ اذهب إلىمنتديات النقاش مع مجتمع Udacity
Behavior of git log
git log lists the most recent commit first, as you can verify by checking the commit dates. The middle commit probably contains the code for the mute button, since the commit message indicates that the mute button was added in that commit. The top commit also probably contain the mute button, since that commit is more recent and nothing suggests the mute button has been removed. The bottom commit probably does not contain the mute button, since that commit was created before the commit that added the mute button.
To summarize:
- commit 7be5a12f1567866b0d77ccdf2055d1a33831da78 (the top commit listed)
Yes, probably contains the mute button.
- commit 06d72e1f95f046002ec46f41cf71957227111141 (the middle commit listed)
Yes, probably contains the mute button.
- commit 3d4d45b246aad6a1cd0afaf7cfae26966110727e (the bottom commit listed)
No, probably does not contain the mute button.
git log output
For reference, here is the git logoutput again:
commit 7be5a12f1567866b0d77ccdf2055d1a33831da78
Author: Ellison Leão <el@gmail.com>
Date: Fri Jul 11 12:56:26 2014 -0300
Add sound for the wing.
commit 06d72e1f95f046002ec46f41cf71957227111141
Author: Ellison Leão <el@gmail.com>
Date: Wed Jul 9 23:42:55 2014 -0300
Add mute button.
commit 3d4d45b246aad6a1cd0afaf7cfae26966110727e
Author: Ellison Leão <el@gmail.com>
Date: Mon Jul 7 17:35:47 2014 -0300
Fix leaderboard button
هل لديك أي أسئلة؟ اذهب إلىمنتديات النقاش مع مجتمع Udacity
هل لديك أي أسئلة؟ اذهب إلىمنتديات النقاش مع مجتمع Udacity
Behavior of git diff
Consider the same partial git logoutput as in the previous exercise. Which arguments would you need to give the git diff command for the lines of code that implement the mute button to be marked as additions (with a plus sign)?
To make the options on the next screen easier to read, only the first 6 characters of each commit ID have been included. This will not change the output of git diff unless two commits start with the same 6 characters.
git log output
For reference, here is the output from git log again:
commit 7be5a12f1567866b0d77ccdf2055d1a33831da78
Author: Ellison Leão <el@gmail.com>
Date: Fri Jul 11 12:56:26 2014 -0300
Add sound for the wing.
commit 06d72e1f95f046002ec46f41cf71957227111141
Author: Ellison Leão <el@gmail.com>
Date: Wed Jul 9 23:42:55 2014 -0300
Add mute button.
commit 3d4d45b246aad6a1cd0afaf7cfae26966110727e
Author: Ellison Leão <el@gmail.com>
Date: Mon Jul 7 17:35:47 2014 -0300
Fix leaderboard button
هل لديك أي أسئلة؟ اذهب إلىمنتديات النقاش مع مجتمع Udacity
Behavior of git diff
The middle commit, 06d72e, is the first commit with the mute button, so comparing that commit and the previous commit, 3d4d45, would show the changes that add the mute button.
In order for the changes adding the mute button to be shown as additions, the commit with the mute button needs to be the second argument to git diff. That is because git diff considers the first argument as the “original”, and the second argument as the “new” version, so additions are lines present in the second argument but not the first.
Thus, the last command listed, git diff 3d4d45 06d72e, is correct, and would show the mute button lines as additions. Reversing the arguments and running git diff 06d72e 3d4d45 would instead show the mute button lines as deletions.
git log output
For reference, here is the git logoutput again:
commit 7be5a12f1567866b0d77ccdf2055d1a33831da78
Author: Ellison Leão <el@gmail.com>
Date: Fri Jul 11 12:56:26 2014 -0300
Add sound for the wing.
commit 06d72e1f95f046002ec46f41cf71957227111141
Author: Ellison Leão <el@gmail.com>
Date: Wed Jul 9 23:42:55 2014 -0300
Add mute button.
commit 3d4d45b246aad6a1cd0afaf7cfae26966110727e
Author: Ellison Leão <el@gmail.com>
Date: Mon Jul 7 17:35:47 2014 -0300
Fix leaderboard button
هل لديك أي أسئلة؟ اذهب إلىمنتديات النقاش مع مجتمع Udacity
هل لديك أي أسئلة؟ اذهب إلىمنتديات النقاش مع مجتمع Udacity
Behavior of git checkout
On the next screen, check whether each statement is always, sometimes, or never true about using git checkout to checkout an earlier commit in a repository with multiple files.
هل لديك أي أسئلة؟ اذهب إلىمنتديات النقاش مع مجتمع Udacity
Behavior of git checkout
Checking out an earlier commit will change the state of at least one file.
This is sometimes true. Git doesn’t allow you to save a new commit if no files have been updated, so you might think this is always true. However, it’s possible to do the following:
- Save a commit (call this commit 1).
- Update some files and save another commit (call this commit 2).
- Change all the files back to their state during commit 1, then save again (call this commit 3).
This sometimes happens if commit 2 contained a bug, and it’s important to fix the bug quickly. The easiest thing to do might be to remove all the changes introduced by commit 2 to fix the bug, then figure out how to safely reintroduce the changes later.
At this point, commit 3 is the latest commit, so if you checkout commit 1, none of the files will be changed.
Checking out an earlier commit will change the state of more than one file.
Checking out an earlier commit will change the state of every file in the repository.
Both of these are sometimes true. Since each commit tracks the state of all files in the repository, it is possible that checking out an earlier commit will change the state of multiple files, or even all the files in the repository. However, it is possible to save a new commit after changing only one file, so it is possible only one file will change.
After checking out a commit, the state of all the files in the repository will be from the same point in time.
This is always true. A commit saves a snapshot of all files in the repository at the time the commit was made, so checking out an earlier commit will result in all the files being reverted to their state at the time the commit was made. That is, the files will be in a consistent state.
هل لديك أي أسئلة؟ اذهب إلىمنتديات النقاش مع مجتمع Udacity
هل لديك أي أسئلة؟ اذهب إلىمنتديات النقاش مع مجتمع Udacity
New repository introduction
In the rest of this problem set, you’ll be using a new repository to get additional practice viewing history with Git. The process will be similar to the one you went through for the asteroids repository in the previous lesson.
The new repository is also a game, Pappu Pakia, that you can play in your browser, and like in the lesson, you’ll be tracking down some bugs in the game by looking through its commit history. As such, don’t be surprised if you spot some bugs when you start the game!
Clone the repository
To get started, clone the repository, which is located at the url https://github.com/udacity/pappu-pakia.git. Then open the file index.htm using your web browser. On the next screen, select the two creators of the game. Their names will be displayed on the initial screen when you open the game.
URL for Pappu Pakia: https://github.com/udacity/pappu-pakia.git
URL for Pappu Pakia: https://github.com/udacity/pappu-pakia.git
Cloning the repository
You can clone the repository by running git clone https://github.com/udacity/pappu-pakia.git. To open the game in your web browser, follow the same process as in this video.
Creators of the game
As stated on the initial page of Pappu Pakia, the game was created by Rishabh and Kushagra. Many thanks to Kushagra and Rishabh for creating this awesome game! We made some modifications to the game to create the following exercises, but you can play the original version of their game here.
Strange behavior
If you actually started playing the version of the game that you cloned, you may have noticed some strange behavior. This is expected! You’ll look into this behavior further in the next exercise.
URL for Pappu Pakia: https://github.com/udacity/pappu-pakia.git
هل لديك أي أسئلة؟ اذهب إلىمنتديات النقاش مع مجتمع Udacity
هل لديك أي أسئلة؟ اذهب إلىمنتديات النقاش مع مجتمع Udacity
هل لديك أي أسئلة؟ اذهب إلىمنتديات النقاش مع مجتمع Udacity
Buggy behavior
If you started playing Pappu Pakia, you should have noticed some pretty strange behavior! The game seems empty of any obstacles, so it’s pretty boring. Also, the bird (called a “pappu”), seems to flicker in various locations across the screen.
As you did in the previous lesson, use Git to checkout commits, run the game, and figure out which commit introduced the bug. When deciding where to start, it may be helpful to know that the bug was introduced recently! Enter the ID of the buggy commit on the next screen. You can also enter only the first four or more characters of the commit ID if that is easier.
In case you forget it and need it again, here is the ID of the most recent commit in the repository: fa4c6bade4970c282b3870ad16f1bde8164663a9
In case you forget it and need it again, here is the ID of the most recent commit in the repository:
fa4c6bade4970c282b3870ad16f1bde8164663a9
Buggy behavior
The commit that introduced this bug has the ID 547f4171a82ec6429d002c1acef357aec41d3f17. One way to find this out would have been to run git log, which should have shown that the most recent 4 commits, and their commit ids, were:
commit fa4c6bade4970c282b3870ad16f1bde8164663a9 changing flattr link commit 708bcce690e5faa5739bd471507c102ea16b77f7 pressing down arrow wont cause scroll down anymore commit 547f4171a82ec6429d002c1acef357aec41d3f17 refactoring collision detection commit 71d52709ddc4066e7a79a1d0a412e43429a0cdeb removing old readme
(This output has been shortened to be easier to read.)
Then you could use git checkout to examine old commits and see which ones have the bug. You already know the most recent commit, “changing flattr link” has the bug, so you could run git checkout 708bcce690e5faa5739bd471507c102ea16b77f7to test the second-most-recent commit . You should find that this commit also has the bug. Next, you’ll find the commit “refactoring collision detection” also has the bug, but the commit “removing old readme” does not. That means the commit “refactoring collision detection” with commit ID 547f4171a82ec6429d002c1acef357aec41d3f17, is the one that introduced the bug.
In case you forget it and need it again, here is the ID of the most recent commit in the repository:
fa4c6bade4970c282b3870ad16f1bde8164663a9
هل لديك أي أسئلة؟ اذهب إلىمنتديات النقاش مع مجتمع Udacity
In case you forget it and need it again, here is the ID of the most recent commit in the repository:
fa4c6bade4970c282b3870ad16f1bde8164663a9
هل لديك أي أسئلة؟ اذهب إلىمنتديات النقاش مع مجتمع Udacity
هل لديك أي أسئلة؟ اذهب إلىمنتديات النقاش مع مجتمع Udacity
Examining the buggy commit
Use Git’s history to figure out what changes were introduced in the commit that caused the bug. On the next screen, check any changes that were introduced, and enter the name of the file that was affected.
Finding and fixing the bug
Now that you know what changes were introduced by the buggy commit, do you have any idea what could have caused the bug? If not, don’t worry about it. The answer will be in the solution if you’re curious.
Once you’ve identified the code that caused the bug, obtain a working version of the game. You can do this by either:
- Figuring out what caused the bug (or check the solution), and modify the code to fix the bug
- Checking out the commit before the one with the bug. That commit won’t contain the most up-to-date version of the code, but for the purposes of the upcoming exercise it won’t matter.
Changes introduced
To find the lines introduced by the buggy commit, you can use git diff. You’ll need the ID of the buggy commit, which you just found to be 547f4171a82ec6429d002c1acef357aec41d3f17. Then you’ll need the ID of the previous commit, which will be the commit below it in git log. (That’s because git log lists the most recent commit first.) That turns out to be 71d52709ddc4066e7a79a1d0a412e43429a0cdeb.
Thus, by running git diff 71d52709ddc4066e7a79a1d0a412e43429a0cdeb 547f4171a82ec6429d002c1acef357aec41d3f17, you can find out that the lines changed by the buggy commit were:
- return !(
- bounds1.end_x < bounds2.start_x ||
- bounds2.end_x < bounds1.start_x ||
- bounds1.end_y < bounds2.start_y ||
- bounds2.end_y < bounds1.start_y
- );
-
+ if (bounds1.end_x < bounds2.start_x) {
+ return true;
+ }
+ if (bounds2.end_x < bounds1.start_x) {
+ return true;
+ }
+ if (bounds1.end_y < bounds2.start_y) {
+ return true;
+ }
+ if (bounds2.end_y < bounds1.start_y) {
+ return true;
+ }
+ return false;
This change represents an “or” expression being separated out into several “if” statements. The number of functions did not change, and no variables were renamed.
File changed
Near the top of the git diffoutput, you can see the lines
--- a/js/utils.js +++ b/js/utils.js
This indicates that the file changed was js/utils.js, that is, the file utils.js within the js directory.
What caused the bug
Based on the change that was made, a reasonable guess is that the bug is some sort of logic error – maybe the new version does not return true and false at the correct times.
It turns out that this is correct. The new code has true and falsereversed! Even if you weren’t sure exactly why the bug was there, congratulations! You tracked down exactly where the bug was introduced, and knew which lines introduced it, without knowing the code base. All you had to know was how to use Git.
هل لديك أي أسئلة؟ اذهب إلىمنتديات النقاش مع مجتمع Udacity
هل لديك أي أسئلة؟ اذهب إلىمنتديات النقاش مع مجتمع Udacity
هل لديك أي أسئلة؟ اذهب إلىمنتديات النقاش مع مجتمع Udacity
There is a second bug
Now you should have a version of the code that works much better – your pappu is not flickering across the screen, and there are plenty of obstacles to avoid. However, there is another, harder to see, bug in the code.
During the game, a cluster of berries appears reasonably often. When the pappu hits those berries, it should split into three pappu clones, but instead, nothing seems to happen.
Finding the bug
This time, instead of checking out old versions of the code, just run git log and look at the 10 most recent commits. Based only on the commit messages, which commit do you think is most likely to have introduced this bug? You can’t be sure just by reading the messages, but pick the one you think is most likely.
هل لديك أي أسئلة؟ اذهب إلىمنتديات النقاش مع مجتمع Udacity
Identifying the bug
One reasonable guess is that the commit with message “speeding clones up”, that is, commit 003c8c197cd3b1e5b28b58f53ee14d7ebaa9bb3a, is likely to be the one causing the bug. The bug is related to clones, and this commit changed the behavior of clones, so it seems plausible that this commit caused the bug.
Of course, the most likely-looking commit won’t always be the culprit, so you’ll always have to take a closer look at the suspicious commit to see if it actually caused the bug. In this case, the commit “speeding up clones” did in fact cause the bug.
Using this strategy of examining the most likely looking commits doesn’t always work, but it often does, and it can save a lot of debugging time. This is one of the reasons it’s so useful to make one commit per logical change and give each commit a good message – to make it possible to take shortcuts like this!
هل لديك أي أسئلة؟ اذهب إلىمنتديات النقاش مع مجتمع Udacity
هل لديك أي أسئلة؟ اذهب إلىمنتديات النقاش مع مجتمع Udacity
Examining the buggy commit
Again, use Git’s history to figure out what changes were introduced in the commit that caused the bug. On the next screen, select the change that was introduced, and enter the name of the file that was affected.
Finding and fixing the bug
Now that you know what changes were introduced by the buggy commit, do you have any idea what could have caused the bug? If not, don’t worry about it. The answer will be in the solution if you’re curious.
It’s not necessary to obtain a working version of the game for future exercises. However, it can still be nice to verify that you’ve actually found the bug! You can do this by either:
- Figure out what caused the bug (or check the solution), and modify the code to fix the bug.
- Check out the commit before the one with the bug. That commit won’t contain the most up-to-date version of the code, but it will let you verify that your hunch was correct. (Note: this will not work if you modified the code to fix the last bug.)
Changes introduced
As before, you can use git diff to find the lines introduced by the buggy commit. Again, you’ll need the ID of the buggy commit, which is 003c8c197cd3b1e5b28b58f53ee14d7ebaa9bb3a, and the ID of the previous commit, which is 746f762e38b5bbb7d0b837464ef6ec3f8ee5bf91.
Thus, by running git diff 746f762e38b5bbb7d0b837464ef6ec3f8ee5bf91 003c8c197cd3b1e5b28b58f53ee14d7ebaa9bb3a, you can find out that the change made by the buggy commit was:
- clone.x += utils.randomNumber(5, 10); - clone.y += utils.randomNumber(-20, 20); + clone.x += utils.randomNumber(500, 1000); + clone.y += utils.randomNumber(-2000, 2000);
That is, the x and y coordinate of each clone is changed by a larger random amount. This will have the effect of making the clones move more quickly, or speed up, since their positions change more quickly.
File changed
Near the top of the git diffoutput, you can see the lines:
--- a/js/pappu.js +++ b/js/pappu.js
This indicates that the file changed was `js/pappu.js`, that is, the file `pappu.js` in the directory `js`. ## What caused the bug Based on the change that was made, one possible bug is that the clones move **too** quickly – so quickly they have left the screen before you see them. This turns out to be correct. If you change the code to have numbers bigger than the original numbers, but smaller than the new numbers, the clones will move more quickly, but still be visible. Some lines of code that work well are:
clone.x += utils.randomNumber(20, 40); clone.y += utils.randomNumber(-30, 30);
Again, even if you weren’t sure exactly why the bug was there, congratulations! You tracked down which lines introduced a bug without knowing the code base, just by using Git.
هل لديك أي أسئلة؟ اذهب إلى
هل لديك أي أسئلة؟ اذهب إلىمنتديات النقاش مع مجتمع Udacity
مسار الاندرويد 