will there be an update to rubygem? about githug HOT 9 OPEN

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.

from githug.

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

from githug.

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.

from githug.

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.

from githug.

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

from githug.

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.

from githug.

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

from githug.

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

from githug.

from githug.