Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ordering the katas #185

Closed
adamatan opened this issue Jul 4, 2019 · 17 comments · Fixed by #189
Closed

Ordering the katas #185

adamatan opened this issue Jul 4, 2019 · 17 comments · Fixed by #189

Comments

@adamatan
Copy link
Contributor

adamatan commented Jul 4, 2019

Thanks!

First, thanks a lot for this very useful repo. I refer to it a lot when I deliver git sessions on stage as a great learning and practicing resource.

The Problem

Newcomers to the katas, who just want to get more professional with git, don't have a clear starting point and progress path. Some katas clearly require prior knowledge, and taking a random kata might be frustrating.

Current (ad-hoc) solution

I have built a github repo with a reasonable starting point and path.

Suggested solution

I would like to add an order prefix to the katas, with leaps of 10 to allow future insertions. For example, basic-commits0010-basic-commits, basic-staging0020-basic-staging and so on, by the following order:

  1. basic-commits
  2. basic-staging
  3. basic-branching
  4. reset
  5. squashing
  6. detached-head
  7. ff-merge
  8. merge-conflict
  9. 3-way-merge
  10. rebase-branch
  11. advanced-rebase-interactive

The first numbering should include what we consider basic knowledge for any senior developer.

Advanced material (e.g. Investigation, submodules, ...) can be numbered with a different prefix (e.g. 1010-Investigation, 1020-submodules) to denote that they are not part of the basic path every user should know.

Next steps

I'm opening this to discussion here. If we reach a consensus, I'll PR with a numbering schema.

@RandomSort
Copy link
Contributor

I like your suggestion. We have also been touching on this in #56 and #130 :)
We can also add a "next" command to the exercises to jump to the proper exercise - but that is probably the next step.

We should also drop the basic prefix.

My suggestion would be:
Staging
Commits
basic branching -> branching
ff-merge
3-way-merge
merge-mergesort (better than merge-conflict)
reset
detached-head
squashing
rebase-branch
advanced-rebase-interactive

@RandomSort
Copy link
Contributor

My thoughts at the moment is that perhaps the 0 prefix should be for getting up and running, with perhaps now only the configure git thing. That could also contain some very basic shell katas or some actual katas in configuring.

I tend to talk about ignoring quite early in the setting, so I'd like to move that to the current 0 track.

I can do the reordering, what are your thoughts?

Pulling in some Praqma trainers @JKrag @praqma-thi @sofusalbertsen

@adamatan
Copy link
Contributor Author

adamatan commented Jul 5, 2019

Makes perfect sense. I'll try to set the numbers and suggest a new ordering during the weekend (please let me know if you already did it).

@adamatan
Copy link
Contributor Author

adamatan commented Jul 5, 2019

  • Moved configuration and ignore to 0xxx
  • Increased other prefixes accordingly (basics are 1xxx, commits 2xxx and so on)

aa690f7

Todo, after we agree on numbers:

  • Rewrite Overview.md
  • Change README.md - state the starting point
  • Squash WIP commits

@JKrag
Copy link
Contributor

JKrag commented Jul 9, 2019

While I get the intention, I don't think this is the right way to create a learning path. Partly I think it is hard to agree on a good "order" for learning even the basics, and partly I fear that having a numeric fixed order as part of the file names will also lead us to making too many assumptions within the individual katas as to what the user already knows. Yes, this could be a good thing, as it could make exercises more concise, but only if we all use the exercises in the suggested order, which we don't.

I think we should consider other options for creating learning paths. I suddenly have a half backed idea that i might try to explain in a new issue.

With regards to renaming the actual exercises (not numbering), I also want to mention the thoughts in #156.

@JKrag
Copy link
Contributor

JKrag commented Jul 9, 2019

Just for reference and input, here is the order I currently run the exercises in during my 2-day git class:

  • git-katas/basic-commits
  • git-katas/basic-staging
  • git-katas/investigation
  • git-katas/basic-branching
  • git-katas/ff-merge
  • git-katas/3-way-merge
  • git-katas/merge-mergesort
  • git-katas/rebase-branch
  • git-katas/basic-revert
  • git-katas/reset
  • git-katas/basic-cleaning
  • git-katas/amend
  • git-katas/reorder-the-history
  • git-katas/advanced-rebase-interactive (Typically just live demo)
  • git-katas/basic-stashing

But quite a few changes in order have occurred from time to time.

@adamatan
Copy link
Contributor Author

adamatan commented Jul 9, 2019

@JKrag Thanks for your response!

I would like to argue that having a default numbered order might be a good idea because it would help instructors safely assume some prior knowledge when fixing a kata or creating a new one. For example, @RandomSort teaches staging before commits, and you're doing it the other way around. If they are to be ordered, adding steps to the katas would be much easier.

We can also add a "prior knowledge" section at the beginning of each kata, to let the student know what should they practice in order to do the current kata effectively.

I'll follow the issues here - please mention me when you post your new idea about learning paths.

@RandomSort
Copy link
Contributor

RandomSort commented Jul 21, 2019

Partly I think it is hard to agree on a good "order" for learning even the basics

I think this is a valid point - but I would argue that any sane suggested order is better than none. It will make the repository infinitely more valuable for non-praqma people - I assume this is why we opensourced it :)
I think we should run with the way you are going through the exercises - If we internally are doing it in very different ways we should look at why :)

I fear that having a numeric fixed order as part of the file names will also lead us to making too many assumptions within the individual katas as to what the user already knows.

This is a very good point! Glad I pulled you in the discussion :)
This might be the deal breaker. I see two options. We go for a default ordering - signified by numbers - to be very explicit about what would be the order we expect a newcomer to the repository to go through things. This exercise will also help us figure out how we actually want to teach Git :)
This requires us to add the assumed prior knowledge to all katas - but we probably should do that anyway.

Or we can number only the core exercises and leave the supplementary material unorder - I am not a lot for this.

Alternatively we can just document the suggested learning path through the repository in Markdown file. With optional next.sh scripts in each kata - but that is for later :)
How does this approach feel to you @adamatan ? Also look at #156 as @JKrag mentioned.

I think we should consider other options for creating learning paths. I suddenly have a half backed idea that i might try to explain in a new issue.

I will look into that when the issue has been created ;)

I have another week of vacation, but I will follow up no later than the week I get back

@JKrag
Copy link
Contributor

JKrag commented Jul 22, 2019

@RandomSort "The issue" has now been created :-) #188

@praqma-thi
Copy link

Hopping in a bit late, but I'm a big fan of ordering core katas. Having a clear starting point and a path forward would really help accessibility. However, doing that but leaving the rest as is wouldn't be ideal, as they'd just be lying around without any indication of the knowledge required to do them. (Hopping from 040-basic-branching to optional-filter-branch would cause a newbie much grief. 😅)

I wonder if we can order core katas, while making it easy to identify when optional katas would be a good idea to do. Perhaps something like:

  • split all the katas into "difficulty" levels
  • number the core katas throughout those levels
  • suggest optional exercises throughout the core katas

Difficulties could be basic (daily git), intermediate (problem solving), advanced (wacky problem solving, messing with internals, etc.) Mostly arbitrary categories though, so I'm not sure I feel about the whole thing.

@adamatan
Copy link
Contributor Author

Hi everybody!

@RandomSort Hope you had a terrific vacation!
@JKrag Thanks for #188 (commented there).

@praqma-thi :
I do agree that numbering is an all-or-nothing move, and a mix would be confusing. However, I think that defining the level of difficulty is problematic. Is interactive rebase a daily action? What about merging conflicts, or amending?

Therefore, I think that the solution should be twofold: ordered and numbered learning path on the first hand, and a clear prior knowledge list at each kata on the second hand. A linear learner can move forward without wondering what's the next move, and a learner that wants to understand any advanced topic can easily see what prior knowledge is required without running through the entire learning path.

I would refrain from a next.sh script. It's another file to maintain, and the user can lose orientation if some magic script took them elsewhere. A cd to the next number would be easier to grasp.

Suggested Solution (#186)

# Configuration and environment
0010---configure-git
0020---ignore

# Daily / Basic
1010---staging
1020---commits
1030---branching
1040---ff-merge
1050---3-way-merge
1060---merge-mergesort
1070---reset
1080---detached-head
1090---squashing
1100---rebase-branch
1110---interactive-rebase

# Advanced (Commits)
2010---amend
2020---bad-commit
2030---commit-on-wrong-branch
2040---commit-on-wrong-branch-2
2050---revert
2060---reverted-merge
2070---cleaning
2080---stashing
2090---save-my-commit

# Advanced (References and Objects)
3010---merge-conflict
3020---merge-driver
3030---rebase-exec
3040---reorder-the-history
3050---bisect
3060---objects
3070---investigation
4010---pre-push
4020---submodules

@RandomSort
Copy link
Contributor

RandomSort commented Jul 29, 2019

My part conclusion here is:

  • We would like a learning path
  • Automating it is not in this step
  • Learning path should be seperated from a posisble renaming of exercises

We will order the exercises according to the suggested order that @JKrag posted in this thread.
Beside that will be a group of ad-hoc or optional exercises. They will also be grouped.

To move it forward and get a first we'll go with one of the two suggested solutions:

  • ordering by numbering of file names
  • Learning Path as part of the README.md

Vote by reacting to this comment with 🚀 for numbering and 👀 for README.md. I will close the voting friday at noon.
I would like to see votes from: @meekrosoft @Neppord @JKrag @praqma-thi @RandomSort, If I have forgotten any please mention them here.

Thank you for your participation, you all rock!

@JKrag
Copy link
Contributor

JKrag commented Jul 29, 2019

😕 = really on the fence on this one. I might come up with a more clear 🚀 or 👀 vote in a few days....

@RandomSort
Copy link
Contributor

Understandable Jan, but then we know that the Agile way tells us to do a first increment, and iterate from there :)

@JKrag
Copy link
Contributor

JKrag commented Jul 29, 2019

@RandomSort ....., you got me there!

So maybe the first increment is to number the basic exercises for now and leave the advanced topics for now or have them grouped by some naming convention?

@RandomSort
Copy link
Contributor

RandomSort commented Jul 29, 2019 via email

@RandomSort
Copy link
Contributor

As no one has made any votes I will be happy to add a Learning path to the read me. It gives me a chance to brush up that anyway :D
I will add @JKrag's suggested order to the readme, and reject your pull request @adamatan Thank you for sparking this discussion and making us move.
The README solution is also the least invasive solution :)

RandomSort added a commit that referenced this issue Aug 5, 2019
farzanahmad863 added a commit to farzanahmad863/git-katas that referenced this issue Oct 7, 2020
* Fix typos

* Remove usage of patch mode add from 3-way-merge exercise

Patch mode add is an advanced topic that does not fit the level of this
exercise and the time and way it is typically used in training.

* Add a bare minimum shell survival guide for training

* Add more editor config options to basic-commits

Instructions for Atom and Notepad++

* Fixed commit -m example

* Remove --decorate from katas

The --decorate option is default in git log, and provides no value in
the form where it is currently used in the examples.

* Mention `touch` to create an empty file

* Update SHELL-BASICS.md

Added elaboration

* Fix a typo: append missing closing brace

* Style: mark 'file.txt' as code

* Fix typos

* Adding note about running sh in windows
FIX  eficode-academy#183

* Mark "git status" as code

* Add learning path to README

Close eficode-academy#185 close eficode-academy#130 close eficode-academy#56

* setup.sh and verify.sh should be executables

* Fixed numbering, so that it now increments both in shell and in markdown

* Added atom and vscode to config examples

* Add simple way of setting up fake remote for exercises

* Change reorder-the-history exercise to use a remote

This allows `git rebase -i` to automatically go back
to origin/master if no target tree'ish is specified.

* Change fake remote script to create bare repo

Clean up new util shell scripts to separate files

* Fixed a typo in reorder-the-history/README.md

* Tweaked markdown in configure-git katas a bit.

* Added .gitattributes to make line endings consistent.

There was a mixture of both DOS and UNIX line endings in the files. The .gitattributes
file can serve as an example.

* Added more explanatory text to basic-commits/README

* Added exercise about excluding something from .gitignore

* Introduction to github

* Added exec-flag to setup.sh script, and fixed syntax error with shebang.

* Set theme jekyll-theme-midnight

* Use makerepo function

* Added to Merge Mergesort README

Added to the task and to the relevant commands

* Added useful commands section to amend/README.

* Added to the task in reorder-the-history/README.

Also added to useful commands.

* Add clone step to README Gif

* Added useful commands and more to reset/README

Added useful commands section and a further explanation section.

* Added the task section to bad-commit/README.md

Added a detailed the task section and added to useful commands.

* Added The task to commit-on-wrong-branch/README.md

Also added Useful commands

* Added to The task in merge-conflict/README.md

Added detailed steps to The tasks and updated the Relevant commands

* Added to The task in reverted-merge/README.md

Added detail to The task and added to Useful commands.

* Added The task in save-my-commit/README.md

Updated the README to be more similar to others.
Made The task slightly clearer and added some hints (via googling)

* Added to the task detached-head/README.

* Made The task more standard and added some detail.
* Added useful commands.

* Changed "git" to "Git" in detached-head/README

* Update README.md

Fix a typo

* Added kata about git tags.

* Improved squashing/README.md

* Made section names more consistent with other READMEs
* How to clean up the \n's wasn't clear so made it it own step and
added to Useful commands
* Added Further information on how to write Git commit messages
* Left in question on git rev-parse. Why this is useful should be made
clearer or the command deleted.

* Removed reference to 'git rev-pars'

* Minor improvements to submodules/README.md

* Made more standard.
* Added some explanatory text about why steps are being done.
* Replaced reference to `git submodule status` with
  `git submodule foreach 'git status'`, because it isn't obvious what the
  output of `git submodule status` means
* Not sure why we are making a second clone so put a TBD.

* Fix link in squashing-README

* Simplify `git lol` alias

`--oneline` is is a shorthand for `--pretty=oneline --abbrev-commit`, see git-log(1)

* Added kata for .gitattributes

* Mention `less` in SHELL-BASICS.md

Helpful alternative to `cat` for long files.

* Word ordering

* Add missing shebang in squashing/setup.sh

`setup.sh` should be executable according to the instructions given in README.md

* fix: wording

* Reordered katas on Overiew and added missing ones

Also grouped into sections in a suggested order.

* Added pointer to Overview also as Learning Path

With change to Overview file, it also contains a learning path.

* Use explicit numbering

* Expand  on  submodules kata

* Fix three typos

* Fix typos in submodule README

* Add kata Rebase Interactive with autosquash

* Clean up unused trainer-notes.md

* Update README.md

`git show <commit id>` was very helpful to me when I did this kata & and later on the job

* Updating git cheatsheet

* clarified pull-request comments

* correction to wrong description of 'git reset'

* clearing the description to be precise

* changed how shell script could be sourced in katas

* Set local git user name and email after initializing exercise repo (to distinguish commits).

* updating a email address to look like one.

* chaning email address to suggested

* helper functions to set and unset local user for training bot commits. Updated setup.sh instructions in few katas to take new effect in place.

* unset error option at the end

* advanced-rebase-interactive README: be consistent with cmdline args

Use `--interactive` as in previous step.

* configure-git README.md: mention private SSH key file

Mention files corresponding to public/private key.

* Simplify basic revert

close eficode-academy#177

* Elaborate and bugfix on rebase-exec

close eficode-academy#187

* use local remote for prepush kata

* Elaborate save my commit

* Small typos in ignore kata README

* Add master based workflow kata

* Fix wording in new exercise description

* Add fake author in master-based-workflow exercise

To easily distinguish own commits from the "virtual" collaborator's
ones.

* Fleshed out section one of config-git.md

* Fixed language and content for config-git

* Consistently use dashes in utils function names

Fix eficode-academy#248

* Add +x rights to pre-push setup.sh

* [Master Workflow] Fix Autor typo

* Consistently write 'Git' if talking about the tool

- Use 'Git' for the tool name
- Use 'git' as the command

* First try to rework "Configure Git" kata

- Start with installation, mention to open Git Bash one time for
  further cfg. steps
- Sub-chapter about SSH authentication

* Prevent weird errors when running setup.sh using e.g. bash setup-sh instead of source setup.sh

* Fix setup scripts of `submodule` kata

- Use parts of the infrastructure in `../utils/`
- Sourcing (`. setup.sh`) or executing (`./setup.sh`) the script now both works
- Don't try to be smarter than the average setup.sh script if it doesn't work anyway...

* Create GitHub actions CI pipeline for running test scripts (eficode-academy#265)

* Create CI pipeline running test scripts

* Fix CI definition

* Add execute access to test.sh

* Fix CI definition

* Make test.ps1 go through all exercises

* Add git user for submodules kata

* Add git user for submodules kata

* Fix setup.ps1 for submodules kata

* Add MacOS to GitHub actions jobs

* Create setup and verify scripts for bisect kata

Resolves: eficode-academy#164

* Create setup script for merge-driver kata

Resolves: eficode-academy#164

* Add file ending new lines

* Add setup.ps1 for git-attributes kata

Related issue: eficode-academy#261

* Add setup.ps1 for git-tag kata

Related issue: eficode-academy#261

* Add setup.ps1 for master-based-workflow kata

Related issue: eficode-academy#261

* Update README.md for git-attributes and git-tag

Add `setup.ps1` to the README.md files.

* Add setup.ps1 for pre-push kata

* Add setup.ps1 and verify.ps1 for rebase-exec kata

Related issue: eficode-academy#261

* Update README.md for bisect and merge-driver

* Gracefully fail when removing exercises folder

If for whatever reason the `exercises` folder cannot be removed the
`setup.ps1` script did not stop but continue running potentionally
spilling a lot of error messages.
With this change the failing deletion will stop the setup script.

Resolves: eficode-academy#243

* Further improve error handling in setup.ps1

Resolves: eficode-academy#243

* FIX problem that kills shell if not bash (eficode-academy#268)

Co-authored-by: Jan Krag <jankrag@gmail.com>

* adding Dockerfile with zsh for regression test

* Complete zsh test

* Fix errors in actions CI file

* added explanatory text to ffmerge README

* Update README.md

* Disable GPG signing of commits locally during setup

As signing might be enabled globally, commits from setup scripts local user
should happen without signing.

* Add VS Code as a suggested editor

* Create change author kata

With this kata you can practice what does it take to change the authors
of already committed and pushed commits.
The idea sprang from a personal experience.

* Fix PR review findings

* Add commands that show contents of commits to better illustrate amending via adding a new file.

* Add an explanation for commands to run with amend.

* Final proposal for subtree git-katas

Co-authored-by: Mads Jensen <mads.jensen@eficode.com>

* Add publish workflow

This is a precursor to our upcoming release pipeline, where the katas are made accessible without cloning them down, causing the dreaded nested git repo confusion.

* Change archive publising to a GH Release

* Fix indentation issue in publish.yml

* Fix tag in release asset name

Co-authored-by: Katrin Leinweber <Katrin.Leinweber@tib.eu>
Co-authored-by: Johan Sigfred Abildskov <randomsort@gmail.com>
Co-authored-by: Jan Krag <jankrag@gmail.com>
Co-authored-by: Frank Theile <frank.theile@web.de>
Co-authored-by: Adam Matan <adam@matan.name>
Co-authored-by: Thanh-Nhon NGUYEN <ntnhon.cs@gmail.com>
Co-authored-by: Sofus Albertsen <soa@praqma.com>
Co-authored-by: Adam Matan <adamatan@users.noreply.github.com>
Co-authored-by: kvartborg <hello@kvartborg.net>
Co-authored-by: Victor Gram Thomsen <victor_gram@ymail.com>
Co-authored-by: Jan Krag <jak@praqma.net>
Co-authored-by: Mads Jensen <maj@praqma.net>
Co-authored-by: Brent Clark <clark@sedsystems.ca>
Co-authored-by: Natasha2001 <natashasee.2001@gmail.com>
Co-authored-by: Alex Blanc <alexandre_blanc@yahoo.fr>
Co-authored-by: Frank Theile <ftheile@grundfos.com>
Co-authored-by: Fuchen Shi <44103628+shifuchen98@users.noreply.github.com>
Co-authored-by: Michael Ingeman-Nielsen <min@praqma.net>
Co-authored-by: Sudheer Kumar Chiluveri <Sudheer.Chiluveri@gmail.com>
Co-authored-by: Sofus Albertsen <sofusalbertsen@users.noreply.github.com>
Co-authored-by: git-katas trainer bot <git-katas@example.com>
Co-authored-by: Thierry Lacour <thi@praqma.net>
Co-authored-by: Niels Kristian Jensen @ MAN <nielsk.jensen@man-es.com>
Co-authored-by: bothzoli <bothzoli@gmail.com>
Co-authored-by: Christoffer Nissen <christoffer.nissen@eficode.com>
Co-authored-by: Joachim Bülow <43139346+joachimbulow@users.noreply.github.com>
Co-authored-by: Dan Grøndahl Glavind <dan.glavind@eficode.com>
Co-authored-by: Thierry Lacour <thierry.lacour@eficode.com>
Co-authored-by: EfiGaja <gaja.kochaniewicz@eficode.com>
Co-authored-by: Claus Schneider (Praqma) <cls@praqma.net>
Co-authored-by: Mads Jensen <mads.jensen@eficode.com>
CristianStanciu pushed a commit to CristianStanciu/git-katas that referenced this issue Jun 2, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
4 participants