imposed master branch

[nbehrnd]

@Gazler Where deemed suitable, I added a line system "git branch -m master" and lightly edited the description of the tasks in levels 2 up and including 55. As a result, the locally build rubygem and its locally installed executable works regardless that my ~/.gitconfig includes an entry of

[init]
    defaultBranch = main

Can you please have a look on this? To ease the revision by a second party, edits to each level are intentionally retained in its own commit.

---

Level 28/push however is somewhat odd. Because I can run

$ git pull
hint: You have divergent branches and need to specify how to reconcile them.
hint: You can do so by running one of the following commands sometime before
hint: your next pull:
hint: 
hint:   git config pull.rebase false  # merge
hint:   git config pull.rebase true   # rebase
hint:   git config pull.ff only       # fast-forward only
hint: 
hint: You can replace "git config" with "git config --global" to set a default
hint: preference for all repositories. You can also pass --rebase, --no-rebase,
hint: or --ff-only on the command line to override the configured default per
hint: invocation.
$ git config pull.rebase true
$ git pull
Successfully rebased and updated refs/heads/master.
$ git push
Enumerating objects: 7, done.
Counting objects: 100% (7/7), done.
Delta compression using up to 4 threads
Compressing objects: 100% (6/6), done.
Writing objects: 100% (6/6), 600 bytes | 600.00 KiB/s, done.
Total 6 (delta 2), reused 0 (delta 0), pack-reused 0
To /tmp/d20240421-13523-hc2e0e/.git
   177f11e..934c868  master -> master
$ 
$ githug
********************************************************************************
*                                    Githug                                    *
********************************************************************************
Congratulations, you have solved the level!

though the commits just prior to the push likely are not in the sequence the initial design of this question aims for. I would accept if I'm wrong on this point.

---

I'm not yet comfortable to test the quizz of level 50 / stage_lines; however, because this is a git technique so far not used. It is a bit beyond resolving merge conflicts I usually resolve with git mergetool.

[Gazler]

This looks good. I was initially curious as to why this wasn't in repo.init or init_from_level but it looks like it doesn't always apply at the start of the level setup.

By the way, for the stage_lines level, you want to use git add -p :)

[nbehrnd]

«Hunk editing» is a thing I'm not yet confident in; thus the particular note to have the corresponding quiz be checked by someone who is.

One incentive for me to see githug working regardless of the entry of ~.gitignore file is that is serves like a test pad to memorize git. A bit like Anki flash cards, but with the advantage that one can issue other commands prior/after «the real command» the quiz is after to monitor the state and change of the git repository. This is more than «only» check e.g., if one knows the equivalent of for instance English «blue» as French «bleu» while learning a natural language.

Eventually, the slight modification by the lines of git branch -m master would allow to mark a couple of issues filed as resolved, and submit a new version to rubygems (including an explicit entry about the MIT license of the project, as suggested in PR #346).

grit which currently is used as interface between Ruby and grit is stated as no longer maintained (ref). A transition to libgit2/rugged (entry on rubygems) hence might be a next leap to consider for the over next version of githug i.e., 0.7.0. An increased visibility of githug in general as well as attracting help for this transition could be achieved for instance if it were packaged for Debian. As I did this for syntax checker markdownlint (relevant thread), were you be comfortable if a) I would do this after your release of githug 0.6.0 to rubygems while indicating b) you as the upstream-contact to Debian?

[Gazler]

I haven't forgotten about this btw. It looks good, I just need to confirm about the push level. I think it should be fine just looking at the code and tests, but need to double check.

[nbehrnd]

The work wasn't done in a single session (there are a few commits to adjust the same .rb file again a couple of days later once again, too). Backed by this experience, I easily understand the review will take some time.

[Gazler]

Thanks so much for this <3