Open nbehrnd opened 8 months ago
I wasn't planning on releasing a new version. However if someone can confirm that the latest master is in a releasable state then I can look into publishing a new version.
I removed my previous installation of githug
by
$ sudo gem uninstall githug
as well as the local ~/git_hug
folder.
Then, as a preliminary test, without any edit to the source code as provided here, in Linux Debian 13/trixie and ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [x86_64-linux-gnu], I run
$ git clone https://github.com/Gazler/githug.git
$ cd git_hug/
$ gem build githug.gemspec
$ sudo gem install --local ./githug-0.5.0.gem
Successfully installed githug-0.5.0
Parsing documentation for githug-0.5.0
Installing ri documentation for githug-0.5.0
Done installing documentation for githug after 0 seconds
1 gem installed
$
$ githug
********************************************************************************
* Githug *
********************************************************************************
No githug directory found, do you wish to create one? [yn] y
Welcome to Githug!
Name: init
Level: 1
Difficulty: *
A new directory, `git_hug`, has been created; initialize an empty repository in it.
The directory was created as announced (~/git_hug
), the commands githug [help | hint | levels | play | reset]
initially seemed to work, however I didn't pass 4 (commit the README file) now -- though the previous commit was about this file and both contained a title, an empty line, a line with a more verbose note. May bad, something I check again on late arvo/on the weekend. Perhaps an optional flag --version
could be added (similar to e.g., markdownlint).
githug
is mentioned in an early chapter «learning by doing» as a complementary tool to learn git in the book by Michael Kofler and Bernd Öggl I borrowed because I already knew Kofler for instance by his books about Linux (250k copies sold) and Markdown/Pandoc.
Edit: I recognized the cause. My screening isn't complete yet.
Depending where the tool was used, passing level 4 was possible / was not possible because of the different naming convention of the principal branch (of deployment) either master
(as seen in an instance of Ubuntu LTS 22.04), or main
(as seen in an instance of Debian 13/trixie). Thread #331 provides as a bypass to rename the branch githug
creates, e.g.
git branch -m master
if necessary. Because this arguably would be be much more useful if implemented, than the helpful note on the project's README.md
alone, I wonder if anyone of you @Gazler, or @aargeee, or @odiraneyya apparently sharing commit and merge privileges of the project gradually could either merge, or close the PR already pending.
Regarding the issue of the naming of the main/master branch, I have to look up my notes again.
@Gazler I would like to suggest edits to a couple of questions; however prior to working on them, and eventually filing a PR, I would like to get in touch with you.
Some of the questions (4, 16, 19, 20, ...) are affected if ~/.gitconfig
reads, for example
[init]
defaultBranch = main
instead of master
. I observe this obstacle can be removed by an additional entry in the question definition itself system "git branch -m master"
for instance of question commit.rb
/ level 04:
difficulty 1
description "The `README` file has been added to your staging area, now commit it."
setup do
repo.init
system "git branch -m master"
FileUtils.touch("README")
repo.add("README")
end
solution do
return false if repo.commits.empty?
true
end
hint do
puts "You must include a message when you commit."
end
(cf. local branch here).
Other questions (for instance level 03 / add.rb
) work regardless of the name of the principal branch.
My proposal to update the code basis of githug
would be the addition of this line; either a) where necessary, in questions already mentioned in the issue reports (as well as ones not yet mentioned [e.g., 45, 46, 47, 50] -- revealed by testing. Or b) to apply the edit equally on questions not (yet) affected.* What is your preference?
* The questions appear as (initially) sorted in increasing difficulty expressed by asterisks. This isn't consistently the case (any more), e.g. #30: blame
of difficulty 2 is followed by #31: branch
of difficulty 1. In case this isn't intentional, were you fine if the LEVELS
block in file githug/lib/githug/level.rb
were gently resorted?
** One then equally could imagine an additional question; i.e. in addition to #31: branch
about moving files within a git managed branch another one about renaming branches.
Thanks for your efforts with this.
We can either explicitly set the branch in the individual levels, or perhaps we could write a local file to .git/config
which sets the defaultBranch
to master - this should override the default config, and we could do this on every level setup to ensure it always applies.
The levels weren't necessarily designed to be from easiest to most difficult, but rather ordered so that they made sense, for example, adding before committing, even though neither is more difficult. Happy for these to be re-ordered if you have a different order in mind that makes sense. I believe the integration tests are order dependent, however they could me modified to explicitly be set to a specific level before running the tests.
@Gazler What happened to the proposal to update githug
on rubygems, e.g. from from current version 0.5.0 to 0.5.1 if one considers the imposed name master
of the principal / default branch by accepted and merged PR #348 as a patch (rather than a minor, or major increment in functionality provided)?
There are a couple of levels in githug
this PR affects/affected and an adoption would allow to close some of the issues filed to the project; see for instance #339, #337, #331, #312, #227.
@nbehrnd I'll look at getting it published this week!
I just pushed 0.5.1 - let me know if it works ok.
Thank you for the note, I'm going to let you know the results of my tests soon.
I'm not sure if it is because of using Ruby greater than version 3.0 the landing page discourages to use. But while question 10) in Debian 13/trixie worked just fine (githug 0.5.1)
$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux trixie/sid
Release: n/a
Codename: trixie
$ ruby --version
ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [x86_64-linux-gnu]
$ git --version
git version 2.43.0
it does not within Xubuntu 22.04 LTS
$ githug reset 10
********************************************************************************
* Githug *
********************************************************************************
resetting level
Name: number_of_files_committed
Level: 10
Difficulty: *
There are some files in this repository; how many of them are staged for a commit?
$ git status
On branch master
No commits yet
Changes to be committed:
(use "git rm --cached <file>..." to unstage)
new file: rubyfile1.rb
new file: rubyfile4.rb
new file: rubyfile5.rb
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: rubyfile5.rb
Untracked files:
(use "git add <file>..." to include in what will be committed)
rubyfile6.rb
rubyfile7.rb
$ githug
********************************************************************************
* Githug *
********************************************************************************
How many files are going to be committed? 3
Sorry, this solution is not quite right!
Name: number_of_files_committed
Level: 10
Difficulty: *
There are some files in this repository; how many of them are staged for a commit?
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 22.04.2 LTS
Release: 22.04
Codename: jammy
$ ruby --version
ruby 3.0.2p107 (2021-07-07 revision 0db68f0233) [x86_64-linux-gnu]
$ git --version
git version 2.34.1
I have to repeat this the way the landing page recommends it, inside/with the ruby version manager.
Observation:
At present, githug as available on rubygem is version 0.5.0 which is an upload by November 13, 2016. On the other hand, the last commit to the repository here was October 13, 2023 about 7 years later.
Simultaneously, a couple of issues and other pull requests equally wait in line for some time.
Question:
When will there be a newly tagged version of this program eventually uploaded to rubygem?