Development Workflow

We currently host vim-Qt at the following locations:

• Bitbucket
• Github

We try keep all these in sync, so that you can fetch from any of these services and trigger pull requests at any of these services. However issue reporting only happens here at Bitbucket.

Submitting bugs

General netiquette applies, just be civil and patient. Please include detailed information with the bug report, it helps narrowing down problems:

• Operating system/Linux distribution
• Qt version
• Sometimes some information about your vim configuration may be helpful too
• If possible chek if the vim-gtk version also has the same issue

Master branch

As a rule of thumb the master branch should always build cleanly. This is also the branch from where packages are occasionally generated.

Topic branches

It is not uncommon to see topic branches - named as tb-somefeature - for more experimental features. Keep in mind that these may involve forced updates when a rebase occurs.

For bug fixes when some testing is desired - before going into the master branch - a fix branch may be created e.g. fix-cursorisbroken.

Upstream Vim

Periodically we merge with the upstream Vim repository(default) - github.com/vim/vim - but we do not keep Vim's history on our repository. The merge event shows up as a merge with a very large commit holding all the changes. The rationale for this is that we should be able to easily rebase our changes on top of other vim trees.

In a nutshell merging vim-qt against vim happens as follows

1. Get the vim-qt source using git (git clone)

2. Create a new branch (e.g. git branch upstream) with the upstream version of Vim

    $ git branch upstream
    $ git checkout upstream
    <erase old files>
    $ cp -r ../vim/upstream/* .

3. Commit the upstream version into the branch (git commit -a)

4. Create a new branch to stage a merge

git branch merge-upstream
git checkout merge-upstream

5. Finally merge with the master branch

git merge --no-commit master
autoreconf

Finally try building and if it succeeds finalize the `git commit`. Then merge-upstream can be merged into master.

Step 2 looks a bit weird, it makes more sense if you consider you have a paralell branch to track upstream (which is what I do).