Consistent use of ordered lists in tasks

3-way-merge/README.md

@@ -6,18 +6,18 @@ Run ./setup.sh && cd exercise
 ## The task
 You again live in your own branch, this time we will be doing a bit of juggling with branches, to show how lightweight branches are in git.
 
- 1. Create a branch called greeting and check it out
- 2. Edit the greeting.txt to contain an oslo-specific greeting
- 3. Add greeting.txt files to staging area using patch mode
- 4. Commit
- 5. Switch back to the master branch
- 6. Create a file README.md with information about this repository
- 7. Try adding README.md file to staging area using patch mode (it wont work)
- 8. What is the output of `git status`?
- 9. Add the README.md file to staging area and make the commit
- 10. What is the output of `git log --oneline --decorate --graph --all`
- 11. Diff the branches
- 8. Merge the greeting branch into master
+1. Create a branch called greeting and check it out
+1. Edit the greeting.txt to contain an oslo-specific greeting
+1. Add greeting.txt files to staging area using patch mode
+1. Commit
+1. Switch back to the master branch
+1. Create a file README.md with information about this repository
+1. Try adding README.md file to staging area using patch mode (it wont work)
+1. What is the output of `git status`?
+1. Add the README.md file to staging area and make the commit
+1. What is the output of `git log --oneline --decorate --graph --all`
+1. Diff the branches
+1. Merge the greeting branch into master
 
 ## Useful commands
 - `git branch`

amend/README.md

@@ -4,11 +4,11 @@ Sometimes we just forgot something obvious that we want to fix quickly.
 
 `git commit --amend` allows us to do that - tinkering with the last commit we made.
 
-## 
-- run the command `. ./setup.sh`
-- What does `git status` tell us?
-- What does `git log` tell us?
-- Stage the addition of bar.txt
-- run `git commit --amend`
-- What happened? What does `git log` tell us?
-- What happens if you run `git commit --amend` again?
+##
+1. run the command `. ./setup.sh`
+1. What does `git status` tell us?
+1. What does `git log` tell us?
+1. Stage the addition of bar.txt
+1. run `git commit --amend`
+1. What happened? What does `git log` tell us?
+1. What happens if you run `git commit --amend` again?

basic-branching/README.md

@@ -5,22 +5,22 @@ Run ./setup.sh
 ## The task
 You again live in your own branch, this time we will be doing a bit of juggling with branches, to show how lightweight branches are in git.
 
-- `cd exercise`
-- Use `git branch to see the two branches that are relevant for this exercise
-- What branch are you on?
-- use `git branch <branch-name>` to create a new branch
-- use `git checkout <branch-name>` to switch to your new branch
-- How does the output from `git status` change when you switch between the master and the new branch that you have created?
-- How does the workspace change when you change between the two branches?
-- In the branch you created, create a file called `file1.txt`.
-- Add your name to the file, make a commit with this change.
-- Merge the `basic-branching-master` onto your current branch.
-- Checkout `basic-branching-master`, merge your branch onto this master branch
-- What happened?
-- Merge the `basic-branching-second-branch` onto your master branch
-- Resolve the merge conflict ( `git status` always helps you )
-- Having resolved the merge conflict take a look at `git log` and see what happened.
-- Draw what happened!
+1. `cd exercise`
+1. Use `git branch` to see the two branches that are relevant for this exercise
+1. What branch are you on?
+1. Use `git branch <branch-name>` to create a new branch
+1. Use `git checkout <branch-name>` to switch to your new branch
+1. How does the output from `git status` change when you switch between the master and the new branch that you have created?
+1. How does the workspace change when you change between the two branches?
+1. In the branch you created, create a file called `file1.txt`.
+1. Add your name to the file, make a commit with this change.
+1. Merge the `basic-branching-master` onto your current branch.
+1. Checkout `basic-branching-master`, merge your branch onto this master branch
+1. What happened?
+1. Merge the `basic-branching-second-branch` onto your master branch
+1. Resolve the merge conflict ( `git status` always helps you )
+1. Having resolved the merge conflict take a look at `git log` and see what happened.
+1. Draw what happened!
 
 ## Useful commands
 - `git checkout`

basic-ignore/README.md

@@ -5,18 +5,18 @@ Run ./setup.sh
 ## The task
 You have your own branch. We'll work a bit with .gitignore
 
-- Create a `.s` file
-- What is the output of `git status`?
-- create a `.gitignore` file in your working directory containing `*.s`
-- What is the output of `git status`?
-- Commit the `.gitignore` file
-- Add `txt` files to `.gitignore`
-- What does `git status` tell us?
-- Change `file1.txt`
-- What does `git status` tell us?
-- Make another textfile in the repository, what does `git status` look like now?
-- Stage the removal of `file1.txt`
-- What does `git status` say?
+1. Create a `.s` file
+1. What is the output of `git status`?
+1. Create a `.gitignore` file in your working directory containing `*.s`
+1. What is the output of `git status`?
+1. Commit the `.gitignore` file
+1. Add `txt` files to `.gitignore`
+1. What does `git status` tell us?
+1. Change `file1.txt`
+1. What does `git status` tell us?
+1. Make another textfile in the repository, what does `git status` look like now?
+1. Stage the removal of `file1.txt`
+1. What does `git status` say?
 
 ## Useful commands
 - `git rm`
@@ -32,4 +32,4 @@ You have your own branch. We'll work a bit with .gitignore
 ## Aliases
 You can set up aliases as such:
 `git config --global alias.lol 'log --oneline --decorate --graph --all'`
-This might be useful to you.
+This might be useful to you.

basic-staging/README.md

@@ -5,29 +5,29 @@ Run ./setup.sh
 ## The task
 You live in your own repository. There is a file called file.txt
 
-- What's the content of file.txt?
-- Overwrite the content in file.txt: `echo 2 > file.txt`
-- What does `git diff` tell you?
-- What does `git diff --staged` tell you?
-- Run `git add file.txt` to stage your change
-- What does `git diff` tell you?
-- What does `git diff --staged` tell you?
-- Overwrite the content in file.txt: `echo 3 > file.txt`
-- What does `git diff` tell you?
-- What does `git diff --staged` tell you?
-- Explain what is happening
-- Run `git reset HEAD file.txt` to unstage the change
-- What does git status tell you now?
-- Stage the change and make a commit
-- What does the log look like?
-- Overwrite the content in file.txt
-- What is the content of file.txt?
-- What does `git status` tell us?    
-- run `git checkout file.txt`
-- What is the content of file.txt?
-- What does `git status` tell us?
-          
-                           
+1. What's the content of file.txt?
+1. Overwrite the content in file.txt: `echo 2 > file.txt`
+1. What does `git diff` tell you?
+1. What does `git diff --staged` tell you?
+1. Run `git add file.txt` to stage your change
+1. What does `git diff` tell you?
+1. What does `git diff --staged` tell you?
+1. Overwrite the content in file.txt: `echo 3 > file.txt`
+1. What does `git diff` tell you?
+1. What does `git diff --staged` tell you?
+1. Explain what is happening
+1. Run `git reset HEAD file.txt` to unstage the change
+1. What does git status tell you now?
+1. Stage the change and make a commit
+1. What does the log look like?
+1. Overwrite the content in file.txt
+1. What is the content of file.txt?
+1. What does `git status` tell us?    
+1. Run `git checkout file.txt`
+1. What is the content of file.txt?
+1. What does `git status` tell us?
+
+
 
 ## Useful commands
 - `git add`

ff-merge/README.md

@@ -6,19 +6,19 @@ Run ./setup.sh && cd exercise
 ## The task
 You again live in your own branch, this time we will be doing a bit of juggling with branches, to show how lightweight branches are in git.
 
- 1. Create a branch called uppercase
- 2. Checkout the branch
- 3. What is the output of `git status`?
- 4. Edit the greeting.txt to contain an uppercase greeting
- 5. Add greeting.txt files to staging area and commit
- 6. 3. What is the output of `git branch`?
- 6. What is the output of `git log --oneline --decorate --graph --all`
- 7. Checkout `master` branch
- 8. Use `cat` to see the contents of the greetings
- 9. Diff the branches
- 10. Merge the branches
- 11. Use `cat` to see the contents of the greetings
- 12. Delete the uppercase branch
+1. Create a branch called uppercase
+1. Checkout the branch
+1. What is the output of `git status`?
+1. Edit the greeting.txt to contain an uppercase greeting
+1. Add greeting.txt files to staging area and commit
+1. What is the output of `git branch`?
+1. What is the output of `git log --oneline --decorate --graph --all`
+1. Checkout `master` branch
+1. Use `cat` to see the contents of the greetings
+1. Diff the branches
+1. Merge the branches
+1. Use `cat` to see the contents of the greetings
+1. Delete the uppercase branch
 
 ## Useful commands
 - `git branch`

merge-conflict/README.md

@@ -2,7 +2,7 @@
 ## Kata 1 merge conflict
 In this kata git can't figure how to merge the content added on `kata1-merge-conflict-branch1` with the content on `master`.
 
-Both changes needs to be in master when you're done.
+Both changes need to be in master when you're done.
 
 ## Relevant commands
 - `git merge`

objects/README.md

@@ -8,12 +8,12 @@ Objects are stored in `<repository>/.git/objects` in subfolders matching the fir
 `git ls-tree master .` inflates and lists the content of a folder.
 
 ## Task
-- Use `git log` to find the sha of a commit
-- Locate the file in the `.git` folder
-- What is in the file?
-- Use `git cat-file -p <sha>` to inflate and view the content.
-- Use `git cat-file` to look at the tree referenced in your commit
-- Use `git cat-file` to look at the parent commit
-- Do these commands work in the `.git` folder? Do you have to be in there?
-- Compare `cat-file` looking at a _tree_ object to using `ls-tree` on a _commit_
-- How does it look on an older commit compared to what you have in `HEAD`?
+1. Use `git log` to find the sha of a commit
+1. Locate the file in the `.git` folder
+1. What is in the file?
+1. Use `git cat-file -p <sha>` to inflate and view the content.
+1. Use `git cat-file` to look at the tree referenced in your commit
+1. Use `git cat-file` to look at the parent commit
+1. Do these commands work in the `.git` folder? Do you have to be in there?
+1. Compare `cat-file` looking at a _tree_ object to using `ls-tree` on a _commit_
+1. How does it look on an older commit compared to what you have in `HEAD`?

pre-push/README.md

@@ -5,8 +5,8 @@ You can look in the `.git/hooks/` folder to see what hooks are available.
 They are all named `*.sample` to prevent them from being executed.
 
 ## Task
-- Clone a repository ( or use one that you already have )
-- In the repository's `.git/hooks/` folder put the file `pre-push` that's in this repository
-- What happens when you try to push to master?
-- What happens if you try to push to a different branch?
-- What happens if you switch the if / else blocks?
+1. Clone a repository ( or use one that you already have )
+1. In the repository's `.git/hooks/` folder put the file `pre-push` that's in this repository
+1. What happens when you try to push to master?
+1. What happens if you try to push to a different branch?
+1. What happens if you switch the if / else blocks?

rebase-branch/README.md

@@ -6,11 +6,11 @@ Run ./setup.sh && cd exercise
 ## The task
 You again live in your own branch, this time we will be doing a bit of juggling with branches, to show how lightweight branches are in git.
 
- 1. git checkout uppercase
- 2. git rebase master
- 3. git lg
- 4. git checkout master
- 5. git merge uppercase
+1. git checkout uppercase
+1. git rebase master
+1. git lg
+1. git checkout master
+1. git merge uppercase
 
 ## Useful commands
 - `git checkout <branch-name>`

reorder-the-history/README.md

@@ -5,7 +5,7 @@ Unfortunately they actually contain useful information - it's just that the hist
 You should fix this such that our `git log` looks great!
 
 ## Task
-- Reorder the history such that it actually makes sense
+1. Reorder the history such that it actually makes sense
 
 ### useful commands
 - `git rebase -i`

reset/README.md

@@ -4,17 +4,14 @@ We can manipulate the History very much so. We should only ever tinker with our
 We use reset to unstage change, but we can also do many more different things.
 
 ## Task
-- run the command `. setup.sh`
-- How does your working directory look like?
-- What does your log look like?
-- Try to run `git reset --soft HEAD~1`
-- What happens to your working directory, your log and your stage?
-- Run `git reset --mixed HEAD~1`
-- What happens to your working directory, your log and your stage?
-- Run `git reset --hard HEAD~1`
-- What happens to your working directory, your log and your stage?
-- Now try to use `git revert HEAD~1` 
-- What happens to your working directory, your log and your stage?
-
-
-
+1. Run the command `. setup.sh`
+1. How does your working directory look like?
+1. What does your log look like?
+1. Try to run `git reset --soft HEAD~1`
+1. What happens to your working directory, your log and your stage?
+1. Run `git reset --mixed HEAD~1`
+1. What happens to your working directory, your log and your stage?
+1. Run `git reset --hard HEAD~1`
+1. What happens to your working directory, your log and your stage?
+1. Now try to use `git revert HEAD~1`
+1. What happens to your working directory, your log and your stage?

save-my-commit/README.md

@@ -4,17 +4,16 @@ We've lost the holy grail!
 Save it!
 
 # Task
-- run `. setup.sh`
-- save the most important commit that was lost
-- What's the difference between saving using reset and using cherry-pick?
-- Remove the ´exercise` folder.
-- run `. setup.sh`
-- run `git gc`
-- Can you still save the lost commit?
-- For extra credit what if someone reset their branch, force pushed and you pulled? Can you restore the old state?
+1. Run `. setup.sh`
+1. Save the most important commit that was lost
+1. What's the difference between saving using reset and using cherry-pick?
+1. Remove the `exercise` folder.
+1. Run `. setup.sh`
+1. Run `git gc`
+1. Can you still save the lost commit?
+1. For extra credit what if someone reset their branch, force pushed and you pulled? Can you restore the old state?
 
 ## Relevant git commands
 -`git reflog
 - git cherry-pick
 - git reset --hard`
-

squashing/README.md

@@ -9,8 +9,8 @@ I would like these commits to be squashed into a single commit!
 While you are at it I would really like the ugly `\n` to be removed from the history.
 
 ## Task
-- _Squash_ the five relevant commits into one, cleaning up the commit msg of one of the commits
-- How does `git log` look now?
+1. _Squash_ the five relevant commits into one, cleaning up the commit msg of one of the commits
+1. How does `git log` look now?
 
 ### Relevant commands
 - `git rebase -i <ref>`

submodules/README.md

@@ -7,23 +7,22 @@ A _product_ repository and two component repositories.
 You will only need the _product_ repo and one _component_, but feel free to use the other component to experiment.
 
 # Task
-- Go into the _product_ repo and run `git submodule add ../ComponentA/ include`
-- What does your working directory look like?
-- Does git status look like you expect? What if you cd to `include`?
-- Commit the changes to your product repo.
-- Go to the the component repository in the exercise folder. Does it know that it is a submodule?
-- Make a change and commit it to your component.
-- Go back to your product repo.
-- Does `git status` or `git submodule status` tell you anything about this new commit?
-- Go to the `include` path and pull the newest version.
-- What is the status now in your product repo?
-- Go to your include folder, make a change and push it back to its origin
-- Go to the `./exercise/ComponentA/` folder, how does it look?
-- Go to the `exercise` dir
-- run `git clone productA productB`
-- What happened?
-- Go to productB, how does your working directory look, what does the log say?
-- Use `git submodule init`, what does your work dir look like?
-- use `git submodule update`, what does your work dir look like now?
-- Draw this entire exercise!
-
+1. Go into the _product_ repo and run `git submodule add ../ComponentA/ include`
+1. What does your working directory look like?
+1. Does `git status` look like you expect? What if you cd to `include`?
+1. Commit the changes to your product repo.
+1. Go to the component repository in the exercise folder. Does it know that it is a submodule?
+1. Make a change and commit it to your component.
+1. Go back to your product repo.
+1. Does `git status` or `git submodule status` tell you anything about this new commit?
+1. Go to the `include` path and pull the newest version.
+1. What is the status now in your product repo?
+1. Go to your include folder, make a change and push it back to its origin
+1. Go to the `./exercise/ComponentA/` folder, how does it look?
+1. Go to the `exercise` dir
+1. Run `git clone productA productB`
+1. What happened?
+1. Go to `productB`, how does your working directory look, what does the log say?
+1. Use `git submodule init`, what does your work dir look like?
+1. Use `git submodule update`, what does your work dir look like now?
+1. Draw this entire exercise!