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
- vcs.git: make sure to always be in detached HEAD closes issue #2037 — committed to xavfernandez/pip by xavfernandez 9 years ago
- Merge pull request #5723 from cjerdonek/vcs-add-git-get-branch Fix the "new install" case of issue #2037 — committed to pypa/pip by pradyunsg 6 years ago
- Merge #1576 1576: Scheduled weekly dependency update for week 40 r=peterbe a=pyup-bot ### Update [botocore](https://pypi.org/project/botocore) from **1.11.6** to **1.12.18**. <details> <sum... — committed to mozilla/normandy by bors[bot] 6 years ago
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 theupdate()
case and can be addressed separately. Theupdate()
case can be addressed in a later PR.