Use git to maintain Vim code

As we all know, Vim'sCodeIt is maintained by Bram using patches, a typical centralized management, although edyfox
The https://vim.svn.sourceforge.net/svnroot/vim maintains the SVN version, but it only imports CVS
The problem is that when you want to develop a series of experimental features, you cannot directly work on the vim SVN repository.
(For example, creating a branch), instead of using its own version to manage the repository.

This causes an obvious maintenance problem. For example, the vim-cocoa code originally uses the svn provided by code.google.com.
The service is maintained, but the Subversion is tracked and modified in the directory. Therefore, the same code directory is either from the vim code repository or from Google
Code repository.

So I used a very troublesome maintenance method:

 
$ SVN Co https://vim.svn.sourceforge.net/svnroot/vim/vim7
$ CP-r vim7/vim-Cocoa/
$ CD vim-cocoa; find.-Name ". SVN/*"-exec Rm-RF {};
$ SVN import src/gui_mac.m https://vim-cocoa.googlecode.com/gui_mac.m
...
 

That is to say, capture the next Vim code, copy it, remove the svn data, and then import the modified part to Google Code.
Version repository. After I complete some modifications and the code becomes stable, I will return to the vim7 directory, update the code downloaded from SVN, and run the following command in vim-Cocoa/
Back port to the latest vim7 code, generate the patch for the latest version, compile, publish.

Obviously, it takes a lot of time to perform manual operations, which is easy to make mistakes. This is the time for git to appear. Let's simply repeat my needs:

1. The latest Vim code can be updated frequently through SVN
2. The vim-cocoa branch code that you are working on is not affected.
3. Merge trunk code and branch code as needed
4. Some automatically generated files in the svn library of VIM should be deleted, because Bram is unwilling, so I should be able to delete them in my own branch, this avoids the need to restore these automatically generated files before each commit.

The following steps are completed with git, mainly using Git-SVN as a convenient tool:

 
$ Mkdir Vim; CD Vim
$ Git-SVN init https://vim.svn.sourceforge.net/svnroot/vim/vim7
$ Git-SVN fetch-r 625 # to reduce consumption, you only need to capture the latest revision instead of copying the entire SVN repository.
 

At this time, Git-SVN will generate a remote branch called Git-SVN, and let the local master point to this branch. Therefore, we can spend a version of our own from the master:

 
$ Git checkout-B cocoa
# The following describes all the modifications made by VIM-cocoa in the latest Vim code.
$ Git commit-M "Import vim-cocoa changes into git repo"
 

After that, if the upstream Vim SVN library is updated, we can use git fetch Git-SVN to download the update, and then use git merge
Git-SVN: Update merge to the current branch. Of course, you can also use git pull Git-SVN.
Combine the two steps, as long as you confirm that merge will not conflict.

Now there is a good platform for local modification, but one problem with vim is that the files automatically generated in src/auto/are also placed in SVN repo.
This is a very troublesome problem, because Vim does not support off-directory build, so after testing and debugging, if you want to generate
Patch, you have to first restore these (in the configure/make process) files that will inevitably be generated to the initial state, without any additional operations, if in git
Commit will also prompt you that these files have been updated, but you obviously do not want to include these changes into your commit. How can you make these files not annoying?

Simple: No matter how the upstream Vim SVN library is maintained, you can delete these files in the local git repository, that is, do not track the changes:

 
# -- Cached indicates that only the GIT cache is deleted and the actual file is not deleted.
$ Git Rm -- cached src/auto/config. h
$ Git Rm -- cached src/auto/config. mk
$ Git Rm -- cached src/auto/configure
...
$ Git commit-M "Stop tracking auto generated files"
 

Because even if these files are not in the tracking, once they have been modified, git status will prompt you that they have been updated, in addition, it is not convenient to use git commit-a to add all modified files to the next commit. What should I do? Use the. gitignore file:

 
$ VI. gitignore
 

Add the following content:

 
. *. SWP
. Ds_store
Src/tags
Src/tags
Src/Vim
Src/auto /*
Src/auto/configure
Src/auto/config. h
Src/auto/config. mk
Src/auto/if_perl.c
Src/auto/link. Log
Src/auto/link. Sed
Src/auto/osdef. h
Src/auto/pathdef. c
Src/config. Log
Src/config. Status
Src/objects
Src/xxd /*
Src/Vim. APP /*
 

So no matter how the files change, git will not prompt.

Now we need a branch for reference to regularly generate patches. This branch must be updated with the update of upstream SVN, however, what should we do if we delete the records of these automatically generated files and do not include them? You can use the master branch automatically generated by Git-SVN to do this:

 
$ Git checkout master
$ Git Rm -- cached src/auto/config. h
...
$ Git commit-M "blahblahblah"
 

In this way, each time an independent vim-cocoa branch is generated next to a Vim trunk patch, I can first on the master Branch:

 
$ Git-SVN rebase
$ Git pull Git-SVN
 

Switch back to the cocoa Branch:

$ Git checkout cocoa
$ Git diff master> vim-cocoa.patch
 

In this way, the patch generation is complete.

Finally, what should we do if we want to publish the current vim-cocoa code repository to the Internet at any time like the original Google code repository? The http://repo.or.cz provides a public repository of code and you can get a push address after applying:

 
Git + SSH: // Repo. Or. cz/srv/git/vim-cocoa.git
 

You need to add a user for push, and then upload its SSH Public Key (generated locally using SSH-keygen ). Then, if I want to publish the local cocoa branch to the Internet, I can execute:

 
$ Git push git + SSH: // Repo. Or. cz/srv/git/vim-cocoa.git cocoa: Master
 

Cocoa refers to the source (local) branch and master refers to the target (remote) Branch. Why should we push it to another branch name? Because
The master node is the branch cloned by default by git. To facilitate the capture by other users and display gitweb information, the master node remains in the public repository.
The master branch is the most frequently updated branch.

This entry was written Jjgod And posted on November 3, 2007 at AMAnd filed under MAC, programming, tools. Bookmark the permalink. follow any comments here with the RSS feed for this post. post a comment or leave a trackback: trackback URL.