Difference between revisions of "Git asynchronous development"
Line 183: | Line 183: | ||
First get an overview, over which commits should be squashed | First get an overview, over which commits should be squashed | ||
git log | git log | ||
− | Let's say you wan't to squash the last 6 commits | + | Let's say you wan't to squash the last 6 commits. Set HEAD~6+1. |
− | git rebase -i HEAD~ | + | git rebase -i HEAD~7 |
− | In the pop-up editor, replace | + | In the pop-up editor, for all the commits who should be squashed, replace '''pick''' with '''s''' or '''squash'''. Do not change the '''pick''' for the first commit. |
− | + | Save and exit editor. | |
− | + | ||
+ | Now compose a new commit message, which can be combined of the earlier commit messages. Comment out lines with "#" which should not be added. | ||
+ | <source lang="text"> | ||
+ | |||
+ | </source> | ||
== See also == | == See also == |
Revision as of 21:04, 19 July 2013
Contents
Motivation
Subversion needs an online repository, to store each commits. Subsequent calls to svn diff > patch will generate the difference according to the last revision. Therefore the development at the moment, require to
- make some lines of code
- make a path file and a commit message
- use the support tracker to upload patch and commit message
- wait for acceptance
- wait for commit to official repository
- then do an svn update
- then return to point 1
This takes time, and require that repository maintainer is online.
If the above scheme is not followed, the patch files will come out of sync.
This can be solved by using git.
Initialization of git
Navigate to the root folder of the branch of relax, you want to develop. Initialize with:
git init
Setup commit information
If you havent set the repository variables for author information and commit message, this is good time. See Git_installation.
Example
Preparation
As an example, we can take the development of the NMRPipe SeriesTab reader: sr #3043: Support for NMRPipe seriesTab format *.ser
We are going to make a support request sr branch. See ref. on branching. In this branch we add the files we would like to track for changes. Then we create a branch sr/seriestab from sr. We then track and create patches of the differences between sr/seriestab and sr.
Create the support request sr branch.
git co -b sr master # See all branches git br -a
Then we add the files
git add lib/software/nmrpipe.py git commit
commit message
Added nmrpipe into git
# To see the commit message git log # Or see last changes by git log -p
Then we create the seriestab branch, from where we will create the patch according to the differences of the sr branch.
git co -b seriestab sr
Checking out a development branch
This section is modified from a how-to for Creating subversion patches with git. We want to be able to create patches and commit messages, which are seamless to patch into the subversion relax repository.
Modification 1
Then we modify lib/software/nmrpipe.py, and add following
# Python module imports.
from re import split
# relax module imports.
from lib.errors import RelaxError
We add the change to be recorded
git add lib/software/nmrpipe.py # OR use this, to add changes from all tracked files git add -u
Then we commit
git commit
commit message. See Format_commit_logs.
Imported expected used modules in lib.software.nmrpipe.py.
Progress sr #3043: (https://gna.org/support/index.php?3043) Support for NMRPipe seriesTab format *.ser
Expected modules for use in lib\software\nmrpipe.py is imported.
To see the commit message
git log
If you would like to replace the last commit info
git commit --amend
Or see last changes by
git log -p
Now create your patch, comparing to the sr branch
git format-patch sr
Modification 2
Then we modify, and add following
def read_list_intensity_seriestab(file_data=None, int_col=None):
"""Return the peak intensity information from the NMRPipe SeriesTab peak intensity file.
The residue number, heteronucleus and proton names, and peak intensity will be returned.
@keyword file_data: The data extracted from the file converted into a list of lists.
@type file_data: list of lists of str
@keyword int_col: The column containing the peak intensity data (for a non-standard formatted file).
@type int_col: int
@raises RelaxError: When the expected peak intensity is not a float.
@return: The extracted data as a list of lists. The first dimension corresponds to the spin. The second dimension consists of the proton name, heteronucleus name, residue number, the intensity value, and the original line of text.
@rtype: list of lists of str, str, int, float, str
"""
We add the change to be recorded
git add lib/software/nmrpipe.py # OR use this, to add changes from all tracked files git add -u
Then we commit
git commit
commit message. See Format_commit_logs.
Added doc string in lib.software.nmrpipe.py.
Progress sr #3043: (https://gna.org/support/index.php?3043) Support for NMRPipe seriesTab format *.ser
Doc string and variables for read_list_intensity_seriestab() function in lib.software.nmrpipe.py is provided.
To see the commit message
git log
If you would like to replace the last commit info
git commit --amend
Or see last changes by
git log -p -1
Now create your patches, comparing to the sr branch
git format-patch sr
This should provide two patch files
Getting an overview
This section is prepared from this site.
Using a GUI to Visualize History. If you like to use a more graphical tool to visualize your commit history, you may want to take a look at a Tcl/Tk program called gitk that is distributed with Git. Gitk is basically a visual git log tool, and it accepts nearly all the filtering options that git log does. Type gitk on the command line in your project.
gitk
Let's review how we can change older commit messages, how-to amend older commit. We want to change the commit message we made some commits ago
To find out, how long we would like to go back, we use the log
git log
We would like change the commit message with commit hash sha1 of (833b91e6064cc8175ad741757ada25edd52c2cce)
git rebase -i 833b91e6064cc8175ad741757ada25edd52c2cce~1 # Instead of 'sha1' you can use 'HEAD~N', where N is the number of commits before 'HEAD' git rebase -i HEAD~2
Now mark the ones you want to amend with reword r (replace pick). Now save and exit editor.
In the next editor, you can then write the new message. Save and exit editor.
Now create your patch, comparing to the sr branch
git format-patch sr
Continuation
You continue with this cycle.
- Modify code
- Track the change
git add -u
- Make a commit message
git commit
Finishing up
Complete test suite
First we test if we pass the test we setup for ourself
relax -s Peak_lists.test_read_peak_list_NMRPipe_seriesTab
Upload patches
First delete all the previous made patches.
rm -r 000*.patch
Now create your patches, comparing to the sr branch
git format-patch sr
Then upload a zip file with all the patches to the support tracker.
Reviewing suggestions and modify commit
There were a number of suggestions to the patches.
=== Squash commits. You can squash commits, which essentially take smaller commits and combine them into larger ones. This can be useful if you’re are wrapping up the day’s work of code. Then you can also prepare a better commit message.
First get an overview, over which commits should be squashed
git log
Let's say you wan't to squash the last 6 commits. Set HEAD~6+1.
git rebase -i HEAD~7
In the pop-up editor, for all the commits who should be squashed, replace pick with s or squash. Do not change the pick for the first commit. Save and exit editor.
Now compose a new commit message, which can be combined of the earlier commit messages. Comment out lines with "#" which should not be added.