Issues with using tags

[junegunn]

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.

language: ruby
rvm:
  - 1.8.7
  - 2.0.0
  - 1.9.2 # Test with vim-nox package on ubuntu

before_script: |
  if [ $(ruby -e 'puts RUBY_VERSION') = 1.9.2 ]; then
    apt-get update -y
    apt-get install -y vim-nox
    ln -s /usr/bin/vim /usr/local/bin/vim
  else
    hg clone https://code.google.com/p/vim/
    cd vim
    ./configure --with-features=huge --enable-rubyinterp
    make
    sudo make install
    cd -
  fi

  git config --global user.email "[email protected]"
  git config --global user.name "Your Name"

script: |
  test/run !

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

# Git 1.7.9.5
git clone --progress --recursive https://github.com/junegunn/goyo.vim.git -b 1.5.3

Cloning into 'goyo.vim'...
remote: Counting objects: 261, done.
remote: Total 261 (delta 0), reused 0 (delta 0), pack-reused 261
Receiving objects: 100% (261/261), 46.80 KiB, done.
Resolving deltas: 100% (104/104), done.
warning: Remote branch 1.5.3 not found in upstream origin, using HEAD instead

# Git 2.2.1
Cloning into 'goyo.vim'...
remote: Counting objects: 261, done.
remote: Total 261 (delta 0), reused 0 (delta 0), pack-reused 261
Receiving objects: 100% (261/261), 46.80 KiB | 0 bytes/s, done.
Resolving deltas: 100% (104/104), done.
Checking connectivity... done.
Note: checking out 'ed3d591346cddf0bfcbc0916cf3a1b3fc4158ff2'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b new_branch_name

The failing test cases expect the second behavior. However, specifying the name of a branch does not result in inconsistency:

# Git 1.7.9.5
git clone --progress --recursive https://github.com/junegunn/seoul256.vim.git -b no-t_co

Cloning into 'seoul256.vim'...
remote: Counting objects: 314, done.
remote: Total 314 (delta 0), reused 0 (delta 0), pack-reused 314
Receiving objects: 100% (314/314), 62.45 KiB, done.
Resolving deltas: 100% (117/117), done.

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.

# Branch
> git merge --ff-only origin/no-t_co
Already up-to-date.

# Tag
> git merge --ff-only origin/1.5.3
fatal: 'origin/1.5.3' does not point to a commit

This regression was introduced by 0e9fa67 for fixing #139.

So, basically, it looks like tags and branches are not interchangeable.

[junegunn]

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".

[junegunn]

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.

[junegunn]

@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.

[starcraftman]

@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.

[junegunn]

@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.

[starcraftman]

@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.