Show log(x).since combination in README

[mattsalt]

Your checklist for this pull request

🚨Please review the guidelines for contributing to this repository.

• Ensure all commits include DCO sign-off.
• Ensure that your contributions pass unit testing.
• Ensure that your contributions contain documentation if applicable.

Description

• Adds some more detail to the README for the log function, specifically around combining with other filters.

.log.since respects the default count configuration which makes sense but isn't clear in the examples or the docs.
Perhaps naively I expected g.log.since('1 month ago') to return a whole month's worth of commits. Instead it consistently returned 30 which is the default for the count param. To return a whole month you have to also specify a greater maximum i.e. g.log(1000).since('1 month ago') depending on the amount of activity in the repository.

[jcouball]

The build failure for TruffleRuby and JRuby on Windows are expected to fail for the git-2.x gem.

• The TruffleRuby build should be resolved with the release of TruffleRuby 24.0.0 and support for that version in the ruby-setup Github action.
• JRuby on Windows is awaiting Process.wait and Process.wait2 not behaving as expected on Windows with JDK > 8 jruby/jruby#7515

You are merging to master which is the git-2.x pre-release branch. There is a 1.x branch for the 1.x release line.

[jcouball]

Thank you for the contribution @mattsalt.

Approved.

I am thinking of changing the default to return all commits with the 2.x release.

@example Return all commits that meet the critieria
  git = Git.open('.')
  commits = git.log

@example Return at most 30 commits
  git = Git.open('.')
  commits = git.log

The thinking is that is the way that git itself works. I think that the (undocumented) principle of this gem is to provide an interface that adhears closely to the git CLI.

Comments welcome.

[jcouball]

Since you changed your base branch to 'v1' the documentation won't show on the default Github README.md since it is on the default branch of master. Sorry I just noticed that as I hit the merge button.

[jcouball]

@mattsalt I merged this PR without realizing that when you changed the base, it pulled all the commits from master that were not also in v1.

Since I caught this issue within a few minutes of merging the change, I ended up force-pushing the v1 branch back to what it was before your PR. You will need to update your local repository to match. Hopefully I caught this before it impacts anyone else.

Sorry for the mess up on my part for not catching this in my review. I'll add your change in a new PR in just a bit.

That said, since the change is to the README, I think you do want it on the master branch since that is what people see in the Github UI by default. But to atone for my sins, I'll add it in both branches.

[jcouball]

Ok, your change has been merged on both master and v1.

Again, sorry for my mistake and the resulting confusion.

[mattsalt]

Thank you! Apologies, I changed the base branch after what you mentioned in the first comment. I saw the unit tests were still failing so was going to check on that but you're clearly far too quick for me.

[mattsalt]

Thank you for the contribution @mattsalt.

Approved.

I am thinking of changing the default to return all commits with the 2.x release.

@example Return all commits that meet the critieria
  git = Git.open('.')
  commits = git.log

@example Return at most 30 commits
  git = Git.open('.')
  commits = git.log

The thinking is that is the way that git itself works. I think that the (undocumented) principle of this gem is to provide an interface that adhears closely to the git CLI.

Comments welcome.

Personally that would have been easier to understand as a new user of the library. However once you do understand there is a limit it easy to use with the default.

That said matching the git CLI experience would definitely reduce the onboarding load. I imagine most people using this library for any log related activity would be looking at more than 30 items.