pip: pip install -e inconsistent checkout with git url and branch

Hi,

The way pip install -e works is inconsistent when you specify the branch name in a git url.

Look at the following behaviours :

Specifying a branch, example master on pip source repository:

$ pip install -e git+https://github.com/pypa/pip.git@master#egg=pip
$ cd src/pip/
$ git status
HEAD detached at 08ebc0a
nothing to commit, working directory clean

Specifying a branch again, develop from the same repo this time :

$ pip install -e git+https://github.com/pypa/pip.git@develop#egg=pip
$ cd src/pip/
$ git status
On branch develop
Your branch is up-to-date with 'origin/develop'.
nothing to commit, working directory clean

I would not expect to have 2 different states for the same command, depending on the branch I specified is the default one or not. Because I specified it in both cases, this should behave in the same way. Any further work with this editable installation becomes dependant on whether I am in the first case, or the second one.

About this issue

  • Original URL
  • State: closed
  • Created 10 years ago
  • Comments: 18 (14 by maintainers)

Commits related to this issue

Most upvoted comments

Hi, if people don’t mind I’m going to assign myself to this issue as it’s something I’ve had my eye on for a while and had put a fair amount of thought into. Also, the refactoring I had been wanting to do before working on this issue (and that I mentioned above) is now pretty much done. (Thank you, @pradyunsg and @xavfernandez for the reviews!)

The main prerequisite to this issue is PR #5623, which I’m still waiting for a review on. The new resolve_revision() method that PR adds will be very useful in addressing this issue.

For this issue, I was planning to address just the fetch_new() (aka “clone”) case as it’s simpler than the update() case and can be addressed separately. The update() case can be addressed in a later PR.