Talk:Gerrit/git-review

Previous page history was archived for backup purposes at Talk:Gerrit/git-review/LQT Archive 1 on 2015-07-10.

If you get C:\Program: bad interpreter when running git-review from the git bash shell on Windows (this happens when Pythong is installed inside the Program Files folder), you can fix it by opening the git-review script file (probably C:\Program Files\Python\PythonXX\Scripts\git-review) and in the first line (the one starting with #!) changing Program Files to Progra~1.

I had the same problem. This fix worked. I had already used the Progra~1 substitution in the git-review.bat file.

My installation of git-review resides at C:\Program Files\Python27\Scripts\

There is a bug report here.

So after 5 years this has changed a bit. I went into the directory at: `C:\Program Files\Python27\Scripts\`

I had no git-review file but I did have a plain old `aws` file without an extension. I opened this and changed the `Program Files` piece of the directory path to `Progra~1` as mentioned by the others.

Thanks!

thanks

There seem to be a few issues with the section on Windows installation.

1) The latest version is now 3.5.1 (not a major point).

2) The Python documentation gives several important differences between an installation for all users and one for a single user. Especially the default directory, which is not C:\Pythonxx in the latter case. May I suggest that someone who knows what they are doing (i.e. not me) updates the text to indicate which is preferable?

3) The pip command does not work as specified under git bash (at least in my case). There is no file called pip in the main Python directory. In the Scripts subdirectory there are 3 files: pip.exe, pip3.exe and pip3.5.exe but I don't know which one to use. Or should I be in a Windows command line interpreter here?

The section "What happens when you submit a change" uses the term "tag" referring to the "t" option's argument. However, the git-review documentation refers to that argument as the "topic", which is consistent with how this concept is referred to in Gerrit.

Moreover, "tag" has another very common use in Git (viz, git-tag), which makes it even more confusing.

I'd like to propose to substitute "topic" for "tag" in that section.

This post was posted by Gnustavo~mediawikiwiki, but signed as Gnustavo.

Done

For those (windows users?) having trouble exec'ing git review -R, it works nicely to run the suggested scp command (please note that the shell used by git in windows puts stray characters at the end of lines, so IGNORE "←[K" in the following):

 mylocaldir>git review -R
 Enter passphrase for key '/c/Users/myusername/.ssh/id_rsa':
 Enter passphrase for key '/c/Users/myusername/.ssh/id_rsa':
 remote: Processing changes: refs: 1, done    ←[K
 remote: ERROR: missing Change-Id in commit message footer←[K
 remote: Suggestion for commit message:←[K
 remote:
 remote: Change-Id: I8155f3c92111ae8228e7ac1970225ddef73a88bc←[K
 remote:
 remote: Hint: To automatically insert Change-Id, install the hook:←[K
 remote:   scp -p -P 29418 myusername@gerrit.wikimedia.org:hooks/commit-msg .git/hooks/←[K

In other words, run the suggested "scp" command and your life will be more pleasant/

This post was posted by Qgil-WMF, but signed as Hypergrove.

Gerrit/git-review#Windows suggests to "run scp -v -P 29418 <USERNAME>@gerrit.wikimedia.org:hooks/commit-msg . from within the repo's .git/hooks directory". I believe using the path directly in the command instead of . is clearer, but I also would like to know which of the two other options that differ (-v and -p) should be kept in the instructions on that page. Any insights?

GitHub for windows ships with a portable git version whose executables are also added to %PATH%. In case you have trouble to connect, use ssh -vvv username@gerrit.wikimedia.org -p 29418

• I had to modify the C:\Users\<user>\AppData\Local\GitHub\PortableGit_<hash>\etc\ssh\ssh_config file extending it with:

Host gerrit.wikimedia.org
	StrictHostKeyChecking no
	UserKnownHostsFile=/dev/null
	IdentityFile=C:/Users/<username>/.ssh/id_rsa

Of course C:/Users/<username>/.ssh/id_rsa must contain the private SSH key.

• A successful connect will then look similar to:

Python 3.4.3 rc1/PIP mangled the hashbang line; it was looking like #!S:Python34python.exe for git-review-script.py As a result, I got a failed to create process. error.

The solution was to correct it to

#!S:\Python34\python.exe

Thanks PIP!

I'm confused about the references to git-remote and the .gitremote file. Should this really be the .gitreview file?

When I installed git-review and when I ran git remote -s, I got an error about a missing .gitreview file.

I created a .gitreview file (with contents similar to what this page calls the .gitremote) and then git remote -s worked fine.

An anonymous user changed the file name from .gitremote to .gitreview but left the name "git-remote" in the section title and text. There is a git-remote for configuring remote repositories, but I find its use in this context (for people new to git-review) confusing. Should these be changed to git-review? I'm new to git-review.

On debian shared hosting, one cannot sudo so as to install python-pip and git-review. One could install them locally for ones user account, but how? Can anyone help extending the section on debian appropriately?

Found a way and added a description.

The current state of git-review presents a series of obstacles for prospective gerrit users. Many windows users are likely turned away by the complex chain of installations and configurations. Resolving bugs in git-review on windows systems would help, but a single installer for git-review and its dependencies would retain more aspiring developers.

Pushing the features of git-review into git would be ideal.

Or we could just stop using the awful tool :\