Closed junegunn closed 9 years ago
The above commit fixes the second problem. The first problem is not reproducible on Travis CI as the default version of Git there is 1.8.
The behavior was implemented in 1.7.10:
* "git clone" learned to detach the HEAD in the resulting repository
when the user specifies a tag with "--branch" (e.g., "--branch=v1.0").
Clone also learned to print the usual "detached HEAD" advice in such
a case, similar to "git checkout v1.0".
In order the fix the first problem we have to expand the current clone command:
from git clone --recursive -b TAG
to git clone
+ cd
+ git checkout TAG
+ git submodule update --init --recursive
.
This is really painful.
@vheon @starcraftman I really don't want to fix it, what do you guys think? Everything works fine with old version of git except for tagged-clone. We should probably tell the users to upgrade their git if they want the full features.
By the way, I'm a bit surprised by the fact that nobody has reported these problems. This, once again, shows that very few actually use tags or branches.
@junegunn Re first question, man git 1.7 is old, almost 4 years. It really isn't hard to build/replace git from source (we could link instructions). Up to you whether you want to, but I'd be inclined to just recommend min version, like 1.8 or more. We can't go back every time somebody has x outdated version of software y. There's probably people still running python 2.4 or even 2.2, I've no interest in supporting that I can tell you.
On a related note, perhaps we need to consider better documenting on the front page README the minimum requirements for each installer option. Like your ruby installer has minimum patch set/RVM, but unless people look inside they don't know that before running. My python I know is >= 2.6. Git >= 1.8 and so on. Might prevent people trying combinations that won't ever work.
It doesn't surprise me that nobody uses tags/branches. Apart from the odd time a plugin is broken for more than a day I'd say its not very useful to track a different branch/tag. More importantly, it prevents you from getting updates from plugin authors. That kinda defeats the whole point of a plugin manager. Otherwise, there's a small set of users with conservative vimrcs that probably use em for stable plugins.
@starcraftman Thanks for your feedback. Plugin manager is a very special kind of software where compatibility is a very important virtue. It is especially so when it is for Vim, which people have been using for decades. So I've been trying to make it as compatible and available as possible so far. But if doing so means hurting the quality and the maintainability of the code - like in this case - yeah, we would have to refrain from doing it and give up supporting the old versions. As far as I know, every feature of vim-plug should work fine with Git 1.7.10 or above, and since your python installer does not use any extra git commands or options, the same holds true. If we don't count tagged-clone, vim-plug is known to work with 1.7.0.4, which I think is a good thing.
we need to consider better documenting on the front page README the minimum requirements for each installer option
I agree, I'll put it somewhere on the wiki page or on README after merging your work.
@junegunn Oh I know compatibility is nice, especially since vim runs on all kinds of systems! Your latter point is what I was getting at, at some point going back makes code poor. Somebody's always gonna want it to run on [insert old config], sometimes the answer is just no.
We had a few regressions lately (#166, #170, #173), so I'm trying to expand the coverage of Travis CI build by running the tests not only with the recent version of Vim, but with the older
vim-nox
package of Ubuntu 12.04.However, I've noticed that a couple of tests fail because of the inconsistent behavior of the stock git (1.7.9.5).
When cloning a repository with tag
The failing test cases expect the second behavior. However, specifying the name of a branch does not result in inconsistency:
Tags don't work with
git merge --ff-only origin/TAG_NAME
This is another bug I found, which makes it impossible to update plugins with designated tags. It fails regardless of the version of git.
This regression was introduced by 0e9fa672f824c178fa6778cd51a9b4c4b7482e2e for fixing #139.
So, basically, it looks like tags and branches are not interchangeable.