Skip to content

Git::Base(or Lib)#describe does not output dirty flag, even if it was requested #429

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
a4z opened this issue Dec 5, 2019 · 6 comments · Fixed by #447
Closed

Git::Base(or Lib)#describe does not output dirty flag, even if it was requested #429

a4z opened this issue Dec 5, 2019 · 6 comments · Fixed by #447

Comments

@a4z
Copy link
Contributor

a4z commented Dec 5, 2019

Subject of the issue

using ruby git like this

require 'git'
puts Git.open(".").describe(nil, {long:true, tags:true, :dirty=>true, always:true})

output: v0.0.0-2-g03626ae

but running git directly produces the correct result

git describe --long --tags --dirty --always

output: v0.0.0-2-g03626ae-dirty

Your environment

  • git version 2.24.0
  • ruby-git 1.5.0
  • ruby 2.6.5p114 (2019-10-01 revision 67812) [x86_64-darwin19]

Steps to reproduce

Generate a dirty repo, add a tag, add a commit, change a file,
now you have a dirty repo

run

require 'git'
puts Git.open(".").describe(nil, {long:true, tags:true, :dirty=>true, always:true})

Expected behaviour

there should be a dirty in the output string (at the end)

Actual behaviour

the dirty flag is not in the output

@stale
Copy link

stale bot commented Feb 3, 2020

A friendly reminder that this issue had no activity for 60 days.

@stale stale bot added the stale label Feb 3, 2020
@a4z
Copy link
Contributor Author

a4z commented Feb 3, 2020

why is this issue ignored? it takes 10 seconds to reproduce

got into a git repo, make some change,
run git describe --long --tags --dirty --always
40a48a9

compare with ruby git

run irb

irb(main):001:0> require 'git'
=> true
irb(main):002:0> puts Git.open(".").describe(nil, {long:true, tags:true, :dirty=>true, always:true})
40a48a9
=> nil

this is clearly a bug, why is this issue stale ?

@stale stale bot removed the stale label Feb 3, 2020
@jcouball
Copy link
Member

jcouball commented Feb 3, 2020

@a4z this project was in a bit of slump for the past year or so. We are just getting it going again.

@a4z
Copy link
Contributor Author

a4z commented Feb 3, 2020

ah, OK, thanks for the information!

if you need some help, no problem

there is some inconsistency how parameters are taken by the function
the documentation says :dirty , a symbol, the implementation checks for a string, see

arr_opts << '--dirty' if opts['dirty'] == true

so this does not work
puts Git.open(".").describe(nil, {long:true, tags:true, dirty:true, always:true})
while this does
puts Git.open(".").describe(nil, {long:true, tags:true, 'dirty'=>true, always:true})

I guess, some other parameters of this function might have some similar problem

if this can wait (I guess it can) I can submit a PR the next or next next weekend, if no one else fixes it until then.
and I assume the implementation should be as the documentation says, yes?

@jcouball
Copy link
Member

jcouball commented Feb 3, 2020

I would really appreciate a PR that fixes this issue.

The implementation should be to use symbols as the key into the arr_opts hash and not strings.

You are correct that other options to describe have this problem... I think they are even worse:

      arr_opts << "--abbrev=#{opts['abbrev']}" if opts[:abbrev]
      arr_opts << "--candidates=#{opts['candidates']}" if opts[:candidates]
      arr_opts << "--match=#{opts['match']}" if opts[:match]

The if is looking up by symbol, but the string interpolation looks up by a string... that would never work.

I would take a fix for this to put things on the right track. However, this points out the need for better testing -- across the board.

a4z added a commit to a4z/ruby-git that referenced this issue Feb 5, 2020
a4z added a commit to a4z/ruby-git that referenced this issue Feb 5, 2020
Signed-off-by: a4z <harald.achitz@gmail.com>
@a4z
Copy link
Contributor Author

a4z commented Feb 5, 2020

PR done, not improved tests because unsure how to do it ,but I might look into it next time I find some time

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants