git module doesn't seem to work on centos 6.2

[kohanamin]

Have been using the original oh-my-zsh for quite a while without any issues. Then switched to your version (I call it "zorinsh"), because it seems to better (good job!).

I have been using it on Ubuntu 12.04 for a while without any issues. then deciced to run it on Centos 6.2 as well. Installed as usual and added modules git and substring search (basically exactly the same .zshrc that I installed on ubuntu).

Unfortunately the git module doesn't seem to work. This is what happens:

ssh [email protected]                                                        ⏎
Last login: Fri Jul 13 01:52:58 2012
~ # cd .oh-my-zsh
git-info:158: bad math expression: operand expected at `> 0 '
git-info:165: bad math expression: operand expected at `> 0 '
.oh-my-zsh git:master # 
~ # zsh --version
zsh 4.3.10 (i386-koji-linux-gnu)
~ # git --version
git version 1.7.1
~ # 

Any ideas?

[sorin-ionescu]

I am not sure. Thus far the only problems that occurred with CentOS is an old ls.

[kohanamin]

No problem, will switch back to "robby russell" for the time being.

I suspect your script doesn't work with git v1.7.1?

[sorin-ionescu]

Investigate what's wrong with it instead of quitting. It seems to be whining about the counts of modified files. You can try changing if (( $modified > 0 )) to if (( modified > 0 )) in modules/git/functions/git-info.

[kohanamin]

That didn't work, but there were several other similar > 0 lines. I removed the $ there as well and the error disappeared.

[tangledhelix]

I have this issue with git 1.7.1 on RHEL 6.3 as well. As @kohanamin indicates, removing the $ gets rid of the error, but then things are broken (e.g. if I am ahead of the upstream repo, my prompt doesn't say so because this test has been crippled by removing the $).

Not sure I have any suggestions here, but it seems to be complaining about git rev-list for me.

ahead_and_behind_cmd='git rev-list --count --left-right HEAD...@{upstream}'

Trying directly:

± git rev-list --count --left-right HEAD...@{upstream}
fatal: ambiguous argument 'HEAD...@a': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions

So the command seems to be failing. I don't know where it is getting this @a from, either, the only remote on this repo is named origin. Thinking the @{..} construct might be an expansion I don't know about, I also tried

git rev-list --count --left-right HEAD...origin

But that just prints the entire help for the command, it isn't happy with that either.

[sorin-ionescu]

If you change

ahead_and_behind_cmd='git rev-list --count --left-right HEAD...@{upstream}'

to

ahead_and_behind_cmd='git rev-list --count --left-right HEAD..."@{upstream}"'

or

ahead_and_behind_cmd='git rev-list --count --left-right HEAD...@\{upstream\}'

does it work?

[sorin-ionescu]

In the shell, you have to escape or quote the curly braces, but in the script, it should work without quoting. It does for me.

[sorin-ionescu]

If you have $foo in a math expression, $(( ... )) or (( ... )), and $foo is empty or not defined, you'll get a bad math expression error. However, if you use foo, without the sigil, it will be considered 0, and it will work.

This means, that one or more counts is not being set for whatever reason.

[tangledhelix]

I think this is just that my git is too old. The same repos seem to work fine on newer git (1.7.7 series instead of ancient 1.7.1). I'll try building my own git package, since Red Hat is so fond of providing archaic releases of most things that don't listen on network sockets.

[sorin-ionescu]

1.7.1 is not that ancient. It would be helpful if you mention what switch fails.

[tangledhelix]

The error is not very specific, but this is the actual output I get:

± git rev-list --count --left-right HEAD..."@{upstream}"
usage: git rev-list [OPTION] <commit-id>... [ -- paths... ]
  limiting output:
    --max-count=nr
    --max-age=epoch
    --min-age=epoch
    --sparse
    --no-merges
    --remove-empty
    --all
    --branches
    --tags
    --remotes
    --stdin
    --quiet
  ordering output:
    --topo-order
    --date-order
    --reverse
  formatting output:
    --parents
    --children
    --objects | --objects-edge
    --unpacked
    --header | --pretty
    --abbrev=nr | --no-abbrev
    --abbrev-commit
    --left-right
  special purpose:
    --bisect
    --bisect-vars
    --bisect-all

But what I can see is that if I remove --count, while I get no output, I also get no errors or help output, which would seem to point to --count as the culprit.

[sorin-ionescu]

To get around --count, you would have to run the command twice for --left and --right and suffix | wc -l at the end.

[tangledhelix]

@sorin-ionescu, that doesn't work (--left and --right don't seem to exist, only --left-right). I'm still experimenting, but I think that I will end up with something like this:

± git rev-list --left-right HEAD...@\{upstream\} | grep -c '^<'
2

± git rev-list --left-right HEAD...@\{upstream\} | grep -c '^>'
0

[tangledhelix]

Before someone asks, --left-only and --right-only do not work either (with or without --cherry-pick).

[sorin-ionescu]

There is a switch that outputs SHA-1's, which you can wc -l.

[benohara]

It looks like this is from the git-info function, which is only used by the sorin theme....all the others use vcs_info, why not just fix the prompt and scrap the git-info function? unless its vastly different to vcs_info?

[sorin-ionescu]

@benohara vcs_info is harder to use because of the messy zstyles and it also coded to the lowest common denominator in many cases. Hence why git-info was written by me then further improved by @ColinHebert. I will not remove it.

You can also try the following for ahead and behind.

git rev-list @\{upstream\}..HEAD 2 > /dev/null | wc -l
git rev-list HEAD..@\{upstream\} 2 > /dev/null | wc -l

[benohara]

I dont use the sorin prompt so it doesnt affect me, jsut seemed that the git-info was doing the same as vcs_info which is part of zsh.

[sorin-ionescu]

It does provide some of the same information, and more, but interacting with it is very different, and you can also turn it off per repository, which is useful for big ones.

[tangledhelix]

FYI, this is what ended up working for me, so far as I can tell.

tangledhelix@006b89d

I did not submit a pull request, but if you think it's worth doing one, I can send one. I considered making this conditional on the version of git, but ended up not bothering.

[sorin-ionescu]

I'm going to let @ColinHebert comment on that.

[ColinHebert]

To be honnest 1.7.1 is that ancient (of the top of my head I would say about two years old).

As I'm really curious I looked in the git source, and found out this: git/git@f69c501

Anyway, back to the real question, does it worth being "fixed"? I would say no, mostly because this is for an old version of git.
In my opinion, regarding git, every version older than 1.7.6 (one year ago) is old enough to not be supported by OMZ (or any project); git moves fast.
Besides, this feature has been included in 1.7.2, and even debian (haha) supports 1.7.2.5 out of the box in the current stable version "squeeze" or 1.7.10 if you use the backports (and for RHEL5, EPEL provides git 1.7.4).

Regarding @tangledhelix's code, even if I don't think it should be included in the current project, it can be useful for some people using 1.7.1 or older, so why not add a comment in the wiki and a link to the patch.

[tangledhelix]

I stuck it in a Gist with a problem description, if that's convenient to link to.

https://gist.github.com/3136583

[sorin-ionescu]

RHEL/CentOS seem to be causing a lot of problems. Are they more ancient than Debian stable? Though, I suspect that administrators use a non-configured BASH just to be safe, @ColinHebert, dismissing one of the most popular Linux distribution is probably not wise.

[ColinHebert]

RHEL tends to use very old packages, and even ZSH is a really old version (4.2.6 on RHEL5).

[sorin-ionescu]

We should probably add a version check to git-info then.

[ColinHebert]

RHEL tends to use very old packages, and even ZSH is a old version (4.2.6 on RHEL5).

So I would say that RHEL5 shouldn't be supported (out of the box) even if with EPEL RHEL5 has git 1.7.4, RHEL6 however uses ZSH 4.3.10 (yay), but doesn't have git available in its EPEL and has only git 1.7.1 provided out of the box. AFAIK, EPEL not providing an up-to-date version of git is not "normal", there is not even the version provided for RHEL5 (1.7.4) which would have been fine.

So, the first action would be asking to EPEL maintainer to provide a newer version of git, and in the mean time install it through another repository (http://pkgs.repoforge.org/git/ you can even get git 1.7.11.1!).

---

I'm not dismissing a popular distribution lightly, RHEL and centos are know for being extremely stable and this is useful for servers/mainframes and for clients who don't really do many things (or like outdated software) which isn't really the target of OMZ anyway.

So for those who absolutely want to use RHEL6 and OMZ and git < 1.7.2 and a prompt theme using git-info (so far only sorin's theme [and mine :)]), having to apply a patch seems to me to be the most sensible approach.
Putting both solutions (and a version check for git) in the git module will only slow things and bloat the code.

---

Regarding the version check I'm not against (even if I don't really see the point, this should be documented in the README IMHO), probably not in the git-info (checking the version each time the prompt is generated doesn't seem like a good idea), maybe in the init file of the git module this way a message is displayed.

[sorin-ionescu]

The way the Git module is set up, the version will have to be checked every time git-info is run. I'll update the readme.