will there be an update to rubygem?

[nbehrnd]

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?

[Gazler]

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.

[nbehrnd]

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.

[nbehrnd]

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.

[nbehrnd]

@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.

[Gazler]

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.

[nbehrnd]

@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.

[Gazler]

@nbehrnd I'll look at getting it published this week!

[Gazler]

I just pushed 0.5.1 - let me know if it works ok.

[nbehrnd]

Thank you for the note, I'm going to let you know the results of my tests soon.

[nbehrnd]

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.