Description of problem: (Sorry, this bug is against Fedora because I couldn't work out how to file it against EPEL). In RHEL 5 + EPEL, fedpkg clone -B fails like this: $ fedpkg clone -B po4a Initialized empty Git repository in /home/rjones/d/fedora/po4a/fedpkg.git/ remote: Counting objects: 207, done. remote: Compressing objects: 100% (96/96), done. remote: Total 207 (delta 95), reused 200 (delta 94) Receiving objects: 100% (207/207), 21.93 KiB, done. Resolving deltas: 100% (95/95), done. Could not clone: Could not locally clone el4/master from /home/rjones/d/fedora/po4a/fedpkg.git: 'git clone --branch el4/master /home/rjones/d/fedora/po4a/fedpkg.git el4' returned exit status 129: error: unknown option `branch' usage: git-clone [options] [--] <repo> [<dir>] -n, --no-checkout don't create a checkout --bare create a bare repository --naked create a bare repository -l, --local to clone from a local repository --no-hardlinks don't use local hardlinks, always copy -s, --shared setup as a shared repository --template ... path to the template directory -q, --quiet be quiet --reference ... reference repository -o, --origin ... use <name> instead of 'origin' to track upstream -u, --upload-pack ... path to git-upload-pack on the remote --depth ... create a shallow clone of that depth --use-separate-remote compatibility, do not use --no-separate-remote compatibility, do not use Version-Release number of selected component (if applicable): fedora-packager-0.5.1.4-1.el5 How reproducible: Always if the -B option is used. Works OK if you don't use -B. Steps to Reproduce: 1. As above. 2. 3. Actual results: Expected results: Additional info:
ugh, I think the "easiest" solution here is to just not have a -B option in our el5 version of fedpkg. I wasn't expecting a lot of people to be using this version anyway.
This problem kinda went away, as git was upgraded to 1.7 on el5.