Stash requires git 1.7.6, but RHEL6 comes with git 1.7.1

[aarnetadmin]

Stash requires git 1.7.6, but RHEL6 comes with git 1.7.1. As RHEL6 is extremely common, and most shops want to stay in-band of the supported software and not add more deps, can stash be made to work with < 1.7.6, perhaps with reduced functionality?

[AddteqS · Accepted solution]

These are the steps we followed for CentOS6 and should work for RHEL6 with little or no modifications.

First, you have to install the dependencies:

yum -y install zlib-devel openssl-devel cpio expat-devel gettext-devel gcc

Then, install ExUtils-MakeMaker:

cd /usr/local/src 
wget http://files.directadmin.com/services/9.0/ExtUtils-MakeMaker-6.31.tar.gz 
tar xzvf ExtUtils-MakeMaker-6.31.tar.gz 
cd ExtUtils-MakeMaker-6.31 
perl Makefile.PL 
make 	
make install

Download the latest version of git:

cd /usr/local/src
wget http://git-core.googlecode.com/files/git-1.7.12.tar.gz 
tar xzvf git-1.7.12.tar.gz 
cd git-1.7.12 
./configure 
make 
make install

[aarnetadmin]

Yes, you can do this, but now you're out of band of the packaged software. Entropy gathers.

[Darren Pegg]

@Addteq

Thank you - Worked a treat for me!!

[Alexander Riggs]

Ok, I did this and it fixed my problem. But I have a new problem now - I am needing to mirror a project and I get the error "fatal: Unable to find remote helper for ‘https’" I am not sure how to fix this, or really even whats wrong. But after some googling, I found that you can recomile git with curl support? Any ideas?

[Jim Bethancourt]

We needed to include curl-devel in the yum package install as well (see http://git-scm.com/book/ch1-4.html). If you could update your instructions I'm sure it would help others too.

[papireddy]

Thank you Addteq -It worked for me and you save my time

[Christopher Medalis]

• Git 1.9.4 is available via Software Collections:

# scl enable git19 "git --version"

git version 1.9.4

# cat /etc/redhat-release

Red Hat Enterprise Linux Server release 6.7 (Santiago)

List of what I installed via "yum install git19" after enabling my system for SCL.

• git19-git-1.9.4-3.el6.x86_64
• git19-runtime-1.2-4.el6.x86_64
• git19-1.2-4.el6.x86_64
• git19-perl-Git-1.9.4-3.el6.noarch

 I have no idea, yet, how the deployment of "BitBucket" server will go with this release of git, as the actual path is : /opt/rh/git19/root/usr/bin/git

Will update with results soon.

[~tools admin] we added the Software Collections directory to the PATH in the setenv.sh script
<Stash Install Dir>/bin/setenv.sh

## Added Git 1.9.x Software Collection path
export PATH=$PATH:/opt/rh/git19/root/usr/bin

To be fair, we should probably run the start-up script with an SCL-enabled shell so that all the environment vars get set, but, this works, and is straight-forward enough for now.

--

[Christopher Medalis]

We've put in the full path to git and adjusted as needed for the version, and stas....er BitBucket v4.x is running. So far so good. I have not heard any problems from the dev team yet.

[Tools Admin]

Thank you.

[Mark McD]

If you want to install 1.7.6, you can probably grab one of the RPMs from here: http://pkgs.repoforge.org/git/

Or to ensure it links with the libs installed on your server, build it from source: https://github.com/git/git

[SPence]

I have tried the RPM's it produces an error with perl-git about the 1.7.1 which has been removed. I do not know how to build from source.

git-1.7.10-1.el6.rfx.x86_64 requires perl-Git = 1.7.10-1.el6.rfx

perl-Git-1.7.1-2.0.1.el6_0.1.noarch requires git = 1.7.1-2.0.1.el6_0.1

[Mark McD]

There are perl-Git RPMs on the first site I linked. You'll need to install them both at the same time (e.g. rpm -i git-1.7.10-1.el6.rfx.x86_64.rpm perl-Git-1.7.10-1.el6.rfx.x86_64.rpm). There are quite a few packages listed on that site so I suspect you might need to repeat this with a few extras.

[SPence]

Worked perfectly. I don't mess with the servers much.

[Matt Warren]

The IUS Community repo has a 1.8 version.

https://iuscommunity.org/

IUS is a packaging effort from RackSpace to address just this sort of trailing application version in RHEL repos. Not official, but much better maintained than rpmforge.

[JensOfSweden]

Redhat is in the late beta of something called software collections. Its channels with a faster release cycle of applications usualy needed by companies that doesnt choose redhat today due to thair trailing releases. So like node.js git pything ruby and so on will be released in those channels.

https://access.redhat.com/site/documentation/Red_Hat_Software_Collections/

[seb]

Hi Rob,

Unfortunately there are significant differences in the functionality between Git 1.7.1 and 1.7.6 (versioning in Git doesn't seem to follow any logical major/minor release pattern).

Stash relies very heavily on the command line options to git commands (such as git log, git ls-tree, etc) and we are at the mercy of the handling of the git client. Because we do not want to expose bugs in the git client as bugs in Stash, we cannot support earlier versions of Git. Doing so would add considerable maintenance overhead for the product, as well as provide differing levels of quality to the product.

Regards,

Seb

[aarnetadmin]

Hrm - you're calling the CLI from the stash java stack? Sounds clunky, and potentially quite fragile. I thought you'd be using http://eclipse.org/jgit/ or similar.

[Jens Schumacher [Atlassian]]

JGit is definitely a great project and we are using it in Bamboo if Git is not natively available. Unfortunately we had some memory issues with it in the past and found that features can lack behind. For example, support for submodules was only implemented in January this year.

[SPence]

Since 1.7.6 is required. How about the instructions on how to install / upgrade to 1.7.6 from 1.7.1

[Christopher Medalis]

https://www.softwarecollections.org/en/ Is the relevant link. https://wiki.centos.org/AdditionalResources/Repositories/SCL http://linux.web.cern.ch/linux/scl/

[stefanlasiewski]

It should be noted that as of 2014, Red Hat Software Collections works with CentOS and Scientific Linux also.

[Jim Bethancourt]

I would recommend installing the git2u package.  We've had great success with this package and it avoids the headache of installing and updating from git source.

[osecluna]

Update Stash is now Bitbucket Server, which requires git v1.8. This isn't in EPEL or rpmforge-extras so I was forced to install git from source following ths instructions here: https://git-scm.com/book/en/v2/Getting-Started-Installing-Git

[Michael E.]

I know this is an old thread, but it is still relevant.

I ran into the same problem that the standard RHEL repo has the old version, but Stash requires the newer one. I don't mind building it from source, but somehow it seems like there is no source package for git-svn available or at least I cannot find any information or instructions.

I need git-svn for migrating from SVN to GIT, as described in this guide: https://www.atlassian.com/git/tutorials/migrating-overview (even though it's for Bitbucket).

Does anybody have a solution for that? (besides repoforge)

[Simon Haslam]

This is a surprising restriction IMO. I wanted to install Stash on a central RHEL/OL 6.6 Jira/CI server so can't take the risk of using non-standard RPMs, and don't want to set up another VM just for Stash. As a small dev team I guess we can live without Stash (despite having paid for it)...

[Jim Bethancourt]

Another possibility to consider if you're stuck in this situation (granted, I haven't tried this myself) is to use a Docker image of Git as described in http://www.florentflament.com/blog/git-ssh-docker-container.html

[Fauzi Gomez]

I find useful to create the rpm in order to use it later if necessary, and not needing to compile over and over again you can have it on your local repository or whatever.

You'll need to install some dependencies first in case you don't already have them:

yum -y install zlib-devel openssl-devel cpio expat-devel gettext-devel gcc curl-devel xmlto asciidoc

Then follow this easy steps and you are done

mkdir -p ~/rpmbuild ~/rpmbuild/BUILD ~/rpmbuild/BUILDROOT ~/rpmbuild/RPMS ~/rpmbuild/SOURCES ~/rpmbuild/SPECS ~/rpmbuild/SRPMS
cd ~/rpmbuild/SOURCES
wget https://git-core.googlecode.com/files/git-1.9.0.tar.gz
rpmbuild -tb git-1.9.0.tar.gz
yum -y localinstall ~/rpmbuild/RPMS/`uname -i`/git-1.9.0-1.el6.x86_64.rpm ~/rpmbuild/RPMS/`uname -i`/perl-Git-1.9.0-1.el6.x86_64.rpm

if you want to, save for later:

perl-Git-1.9.0-1.el6.x86_64.rpm

git-1.9.0-1.el6.x86_64.rpm

this was tested on:

[root@tal]# cat /etc/redhat-release 
CentOS release 6.5 (Final)

[Deleted user]

what did you do about these dependencies?

--> Processing Dependency: perl(SVN::Client) for package: perl-Git-1.9.0-1.el6.x86_64
--> Processing Dependency: perl(SVN::Core) for package: perl-Git-1.9.0-1.el6.x86_64
--> Processing Dependency: perl(SVN::Delta) for package: perl-Git-1.9.0-1.el6.x86_64
--> Processing Dependency: perl(SVN::Ra) for package: perl-Git-1.9.0-1.el6.x86_64
--> Processing Dependency: perl(YAML::Any) for package: perl-Git-1.9.0-1.el6.x86_64

[Fauzi Gomez]

Hi Harry,

Can you provide more information? like OS version?

and, at what point did you get that prompt?

If you are running a minimal install you might need more dependencies, try this ones:

yum -y install perl-ExtUtils-MakeMaker perl-Error

Regards

[Deleted user]

Running RHEL 6.5. Had those packages installed all ready.

I ended up building from source with no rpm.

had this in my directory before after rpmbuild:

x86_64]$ ls
git-1.9.0-1.el6.x86_64.rpm git-arch-1.9.0-1.el6.x86_64.rpm git-email-1.9.0-1.el6.x86_64.rpm gitk-1.9.0-1.el6.x86_64.rpm gitweb-1.9.0-1.el6.x86_64.rpm
git-all-1.9.0-1.el6.x86_64.rpm git-cvs-1.9.0-1.el6.x86_64.rpm git-gui-1.9.0-1.el6.x86_64.rpm git-svn-1.9.0-1.el6.x86_64.rpm perl-Git-1.9.0-1.el6.x86_64.rpm

[Fauzi Gomez]

ok,

The important rpms will be:

perl-Git-1.9.0-1.el6.x86_64.rpm

git-1.9.0-1.el6.x86_64.rpm

the others are git tools, you can install them if you want.

but it looks like you are done.

Regards

[Tim McConechy]

For what its worth this worked for me: http://tecadmin.net/how-to-upgrade-git-version-1-7-10-on-centos-6/#

[Matt Warren]

Though well documented, this howto is using RPMForge. That's the less trustworthy repo specifically avoided in disucssion above. Just to clarify for future readers.

[Christine Lowrie]

We use RHEL 6.2 workstation at my company , which comes with git-1.7.1-2 and that works perfectly fine with Stash.

[Darren Pegg]

Redhat distros are normally on the ball.. :-)

[Simon Haslam]

On initial start-up of Stash 3.5.0 on Oracle (Red Hat) Linux 6.6 / git 1.7.1 you get this fatal error: stash.git.versiontooold[Stash, 1.7.6, 1.8.4.3, 2.0.2, 2.0.3, 1.7.1]

[Iain Kay]

Red Hat Software Collections are fine for users that have an active RHEL support subscription.

A lot of users will run a free deriviation such as CentOS or Scientific Linux and can still claim commercial support on our application servers deployed on top of these OS - as they are compatible with RHEL - but we do not have access to collections like the above that RedHat produce.

This product, Atlassian Stash, should make it far clearer that a RHEL 6.5 server will not run Stash without modification. Simple as that.

[Rich Kucera]

ah, the sucking vortex that is devops ... I choose to avoid the dag/rpmforge but I will compile. Thanks all for feeding back on this issue, very illuminating.

[xaviershay]

Not recommended, but it works:

sudo yum install perl-DBI -y
sudo rpm -e perl-Git-1.7.1-3.el6_4.1.noarch emacs-git-1.7.1-3.el6_4.1.noarch git-1.7.1-3.el6_4.1.x86_64
sudo rpm -i http://pkgs.repoforge.org/git/git-1.7.10-1.el6.rfx.x86_64.rpm http://pkgs.repoforge.org/git/perl-Git-1.7.10-1.el6.rfx.x86_64.rpm

[Philip Haynes]

At least until the system admin's gouge out your eye sockets and sever your fingers....

[xaviershay]

Technically it would still continue to work.

[Aleksey Maksimov]

Technically, no non-standard repos or artifacts manually taken from non-standard repos are allowed on production servers.

[xaviershay]

I wish I could down-vote my own answer.

[Philip Haynes]

Xavier - you did say "Not recommended". Losing your job and vital body parts simply clarifies what the consequences of "Not reccomended" are ;-).

[xaviershay]

This is a problem for me too :(

[Philip Haynes]

Hi Celso,

As I it turns out I am currently sitting with a very friendly sysadmin as he performs the 6th monthly patch upgrade of some of my servers. These are a just a few of the many hundreds RHEL servers he administers. I can confirm the sentiment - "No seasoned sysadmin will do this without thread of bodily harm".

We have purchased and would love to use Stash. It simply a non-starter unless it works with RHEL.

Bodgy upgrading is simply not an option.

Phil

[CelsoA]

Hi there,

Instead of compile git from scratch you can follow the steps found on this link http://akyl.net/how-install-latest-version-git-centos-63 to install it with rpm packages that is less painfull than compile it.

Also, there are some fedora git packages that are compatible with centos.

In my case I just followed the steps on this link to use the most apropriate version of git on Centos 6.4

Regards.

[aarnetadmin]

No rpmfoge repository software will ever darken my servers. AT/DAG RPMS are of the devil himself. It's EPEL or nothing, and git isn't in there.

[Justin Moninger]

I just started digging in to evaluate Stash as we consider migrating from Subversion and ran into this issue. Like others, we develop on RHEL6 and I'm not very exicted about building Git from scratch. Has anyone figured out othe good alternatives?

[Coop IT Coordinators]

I have to agree with the people saying that Stash is a non-starter on RHEL/CentOS. All options presented as work-arounds have serious drawbacks:

1. Compiling from source - unmaintainable. No seasoned sysadmin will do this without threat of bodily harm

2. Using a non-mainstream RPM repo - quickly creates problems with library and package compatibility and regulatory compliance. If it supported 1.7.4, then at least you could get it working with a quasi-official repo - EPEL. But given the stated reasons for using 1.7.6, this is probably not an option.

Given the complete lack of viability for Stash on RHEL/CentOS, some of the options presented here seem reasonable from an outsider's perspective:

1. Evaluate whether RHEL's backporting of fixes/functionality to 1.7.1 (or 1.7.4 in the case where users can utilize EPEL) has obviated the need for a newer version.

2. Redesign Stash to use git's libraries and abandon the use of the CLI client.

3. Devote Atlassian resources to either a) packaging the required version git for inclusion into the EPEL repo or b) making the JGit a viable option for Stash (which would be nice since you already use if for Bamboo). In option b) a redesign of Stash would neccesarily follow.

It would be nice if a considered response to the collected options was provided by Atlassian. The last comment from an Atlassian representative was over a year ago.

[micky]

Lack of support for RHEL is equivalent to saying "Stash is not meant for commercial SW development".

[JensOfSweden]

As rob.kearey says, we use RHEL6 100% at our company and due to compliance from product and app owners that deliver the core buissnes apps we cannot use any third party repositories that hasnt been approved, and for my own wellbeeing im not gonna import any third party repositorys.

Hope you can follow rhel release cyckle and since rhel usualy backports functionallity into thair "lower versions" of applications it might not be any issue?