Preparation for release 1: Trying out git
As part of the upcoming release, we would like to switch over completely to git as it simplifies branch management a lot. As preparation for that, it would be nice if people try it out in their working setup a bit. To check out imp with git do - get the code `git clone https://github.com/salilab/imp.git%60 - setup things `./setup_git.sh`
Git may instruct you to set up your email address and name, if so, follow its instructions.
That will give you a repository that has the current state of the release candidate (which, for the time being is synced with svn). You then use it just like an svn checkout for building IMP. We can talk about committing things later.
When you want to update do `git pull origin master`
Could you tell us a bit more about git flow? Do you want to use this dev scheme?
and when do we need to run setup_git.sh ?
On 12 avr. 2013, at 03:50, Daniel Russel drussel@gmail.com wrote:
> As part of the upcoming release, we would like to switch over completely to git as it simplifies branch management a lot. As preparation for that, it would be nice if people try it out in their working setup a bit. To check out imp with git do > - get the code > `git clone https://github.com/salilab/imp.git%60 > - setup things > `./setup_git.sh` > > Git may instruct you to set up your email address and name, if so, follow its instructions. > > That will give you a repository that has the current state of the release candidate (which, for the time being is synced with svn). You then use it just like an svn checkout for building IMP. We can talk about committing things later. > > When you want to update do > `git pull origin master` > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev
On Apr 15, 2013, at 3:45 PM, Yannick Spill yannick@salilab.org wrote:
> Could you tell us a bit more about git flow? Do you want to use this dev scheme? I use it a lot and plan to use it for managing patches once we have a release. And I would like to move towards a somewhat more controlled commit process, although how to do this well isn't at all clear to me. In general, I think I currently recommend the following strategies - if you are making a bug fix that will go into develop as well as patch the last release, use a git-flow hotfix branch. I would like to get to doing some sort of code review on such things, but that requires a lot of changes to how people operate. - if you are making a small change that is self-contained and you will finish before you move on to anything else, just commit to develop. This is particularly true if it is to a module you control. - if you are making a large change that, for example, touches a bunch of files or will not necessarily be finished before you would like to work on something else IMP related, use a git flow feature branch - if you are making a change that you would like to share with other people before it is committed into develop (eg to get them to check it doesn't break anything, or to test it as you are developing it), use an imp-flow feature branch. -if you are developing a new module or other large body of related code, create a new module in another repository and develop it against the release version of IMP
Using a branch (feature or hotfix) allows changes to be shared and inspected more easily. I'll update the wiki with the above ideas.
> and when do we need to run setup_git.sh ? After you clone the git repository. Running it multiple times is harmless.
I updated the wiki page (getting started as a developer) with related information.
On Apr 15, 2013, at 4:57 PM, Daniel Russel drussel@gmail.com wrote:
> > On Apr 15, 2013, at 3:45 PM, Yannick Spill yannick@salilab.org wrote: > >> Could you tell us a bit more about git flow? Do you want to use this dev scheme? > I use it a lot and plan to use it for managing patches once we have a release. And I would like to move towards a somewhat more controlled commit process, although how to do this well isn't at all clear to me. In general, I think I currently recommend the following strategies > - if you are making a bug fix that will go into develop as well as patch the last release, use a git-flow hotfix branch. I would like to get to doing some sort of code review on such things, but that requires a lot of changes to how people operate. > - if you are making a small change that is self-contained and you will finish before you move on to anything else, just commit to develop. This is particularly true if it is to a module you control. > - if you are making a large change that, for example, touches a bunch of files or will not necessarily be finished before you would like to work on something else IMP related, use a git flow feature branch > - if you are making a change that you would like to share with other people before it is committed into develop (eg to get them to check it doesn't break anything, or to test it as you are developing it), use an imp-flow feature branch. > -if you are developing a new module or other large body of related code, create a new module in another repository and develop it against the release version of IMP > > Using a branch (feature or hotfix) allows changes to be shared and inspected more easily. I'll update the wiki with the above ideas. > >> and when do we need to run setup_git.sh ? > After you clone the git repository. Running it multiple times is harmless.
For those who didn't follow all of it, have a look at this picture http://nvie.com/posts/a-successful-git-branching-model/
> - if you are making a large change that, for example, touches a bunch of files or will not necessarily be finished before you would like to work on something else IMP related, use a git flow feature branch > - if you are making a change that you would like to share with other people before it is committed into develop (eg to get them to check it doesn't break anything, or to test it as you are developing it), use an imp-flow feature branch. what is imp-flow vs git-flow? is this a typo? > -if you are developing a new module or other large body of related code, create a new module in another repository and develop it against the release version of IMP Why not the develop branch? It could be expected that the new module will be available for the next release, and it doesn't make sense to treat it as a hotfix either! > Using a branch (feature or hotfix) allows changes to be shared and inspected more easily. I'll update the wiki with the above ideas. > > and by wiki, you mean: https://github.com/salilab/imp/wiki
In the wiki it would be nice to have a chart with git and svn-equivalent commands (when applies) https://github.com/salilab/**imp/wiki https://github.com/salilab/imp/wiki
On Tue, Apr 16, 2013 at 1:35 AM, Yannick SPILL yannick@salilab.org wrote:
> > For those who didn't follow all of it, have a look at this picture > http://nvie.com/posts/a-**successful-git-branching-**model/http://nvie.com/posts/a-successful-git-branching-model/ > > > - if you are making a large change that, for example, touches a bunch of >> files or will not necessarily be finished before you would like to work on >> something else IMP related, use a git flow feature branch >> - if you are making a change that you would like to share with other >> people before it is committed into develop (eg to get them to check it >> doesn't break anything, or to test it as you are developing it), use an >> imp-flow feature branch. >> > what is imp-flow vs git-flow? is this a typo? > > -if you are developing a new module or other large body of related code, >> create a new module in another repository and develop it against the >> release version of IMP >> > Why not the develop branch? It could be expected that the new module will > be available for the next release, and it doesn't make sense to treat it as > a hotfix either! > > Using a branch (feature or hotfix) allows changes to be shared and >> inspected more easily. I'll update the wiki with the above ideas. >> >> >> and by wiki, you mean: https://github.com/salilab/**imp/wikihttps://github.com/salilab/imp/wiki > > ______________________________**_________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/**listinfo/imp-devhttps://salilab.org/mailman/listinfo/imp-dev >
There are a ton of git/svn comparisons out there already (google "git vs svn"). I'm not sure we need to produce a new one. But perhaps link to an existing one.
On Apr 17, 2013, at 6:02 PM, Riccardo Pellarin pellarin.riccardo@gmail.com wrote:
> In the wiki it would be nice to have a chart with git and svn-equivalent commands (when applies) > https://github.com/salilab/imp/wiki > > > On Tue, Apr 16, 2013 at 1:35 AM, Yannick SPILL yannick@salilab.org wrote: > > For those who didn't follow all of it, have a look at this picture > http://nvie.com/posts/a-successful-git-branching-model/ > > > - if you are making a large change that, for example, touches a bunch of files or will not necessarily be finished before you would like to work on something else IMP related, use a git flow feature branch > - if you are making a change that you would like to share with other people before it is committed into develop (eg to get them to check it doesn't break anything, or to test it as you are developing it), use an imp-flow feature branch. > what is imp-flow vs git-flow? is this a typo? > > -if you are developing a new module or other large body of related code, create a new module in another repository and develop it against the release version of IMP > Why not the develop branch? It could be expected that the new module will be available for the next release, and it doesn't make sense to treat it as a hotfix either! > > Using a branch (feature or hotfix) allows changes to be shared and inspected more easily. I'll update the wiki with the above ideas. > > > and by wiki, you mean: https://github.com/salilab/imp/wiki > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev
Riccardo hi
Hugest difference from svn in git is that you also have a local repository, so you can checkout locally without updating the remote repoisotory. So it is worthwhile learning git a bit on its own indeed. THAT BEING SAID, if you just want to clone a fresh version of IMP develop branch from the github repository, do a few changes, commit them ("add" "commit" and "push" in git terminology), and update occasionally with the main IMP repository ("pull" in git terminology), then go here: https://github.com/salilab/imp/wiki/Getting-started-as-a-developer
in general, a quick and very inaccurate conversion guide: *(1) svn checkout URL* ==> git clone URL * * *(2) svn commit -m "MESSAGE"* ==> git commit -a -m "MESSAGE" ; git push or ==> git add <specific files/folders> ; git commit -m "MESSAGE" ; git push
*(3) svn update* ==> git pull
*(4) svn log * ==> git log
*(5) svn status * ==> git status
On Wed, Apr 17, 2013 at 8:38 PM, Daniel Russel drussel@gmail.com wrote:
> There are a ton of git/svn comparisons out there already (google "git vs > svn"). I'm not sure we need to produce a new one. But perhaps link to an > existing one. > > On Apr 17, 2013, at 6:02 PM, Riccardo Pellarin < > pellarin.riccardo@gmail.com> wrote: > > In the wiki it would be nice to have a chart with git and svn-equivalent > commands (when applies) > https://github.com/salilab/**imp/wikihttps://github.com/salilab/imp/wiki > > > On Tue, Apr 16, 2013 at 1:35 AM, Yannick SPILL yannick@salilab.orgwrote: > >> >> For those who didn't follow all of it, have a look at this picture >> http://nvie.com/posts/a-**successful-git-branching-**model/http://nvie.com/posts/a-successful-git-branching-model/ >> >> >> - if you are making a large change that, for example, touches a bunch of >>> files or will not necessarily be finished before you would like to work on >>> something else IMP related, use a git flow feature branch >>> - if you are making a change that you would like to share with other >>> people before it is committed into develop (eg to get them to check it >>> doesn't break anything, or to test it as you are developing it), use an >>> imp-flow feature branch. >>> >> what is imp-flow vs git-flow? is this a typo? >> >> -if you are developing a new module or other large body of related code, >>> create a new module in another repository and develop it against the >>> release version of IMP >>> >> Why not the develop branch? It could be expected that the new module will >> be available for the next release, and it doesn't make sense to treat it as >> a hotfix either! >> >> Using a branch (feature or hotfix) allows changes to be shared and >>> inspected more easily. I'll update the wiki with the above ideas. >>> >>> >>> and by wiki, you mean: https://github.com/salilab/**imp/wikihttps://github.com/salilab/imp/wiki >> >> ______________________________**_________________ >> IMP-dev mailing list >> IMP-dev@salilab.org >> https://salilab.org/mailman/**listinfo/imp-devhttps://salilab.org/mailman/listinfo/imp-dev >> > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev > > > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev > >
great! thanks!
On Wed, Apr 17, 2013 at 8:58 PM, Barak Raveh barak.raveh@gmail.com wrote:
> Riccardo hi > > Hugest difference from svn in git is that you also have a local > repository, so you can checkout locally without updating the remote > repoisotory. So it is worthwhile learning git a bit on its own indeed. THAT > BEING SAID, if you just want to clone a fresh version of IMP develop branch > from the github repository, do a few changes, commit them ("add" "commit" > and "push" in git terminology), and update occasionally with the main IMP > repository ("pull" in git terminology), then go here: > https://github.com/salilab/imp/wiki/Getting-started-as-a-developer > > in general, a quick and very inaccurate conversion guide: > *(1) svn checkout URL* > ==> git clone URL > * > * > *(2) svn commit -m "MESSAGE"* > ==> git commit -a -m "MESSAGE" ; git push > or > ==> git add <specific files/folders> ; git commit -m "MESSAGE" ; git push > > *(3) svn update* > ==> git pull > > *(4) svn log * > ==> git log > > *(5) svn status * > ==> git status > > > > > On Wed, Apr 17, 2013 at 8:38 PM, Daniel Russel drussel@gmail.com wrote: > >> There are a ton of git/svn comparisons out there already (google "git vs >> svn"). I'm not sure we need to produce a new one. But perhaps link to an >> existing one. >> >> On Apr 17, 2013, at 6:02 PM, Riccardo Pellarin < >> pellarin.riccardo@gmail.com> wrote: >> >> In the wiki it would be nice to have a chart with git and svn-equivalent >> commands (when applies) >> https://github.com/salilab/**imp/wikihttps://github.com/salilab/imp/wiki >> >> >> On Tue, Apr 16, 2013 at 1:35 AM, Yannick SPILL yannick@salilab.orgwrote: >> >>> >>> For those who didn't follow all of it, have a look at this picture >>> http://nvie.com/posts/a-**successful-git-branching-**model/http://nvie.com/posts/a-successful-git-branching-model/ >>> >>> >>> - if you are making a large change that, for example, touches a bunch >>>> of files or will not necessarily be finished before you would like to work >>>> on something else IMP related, use a git flow feature branch >>>> - if you are making a change that you would like to share with other >>>> people before it is committed into develop (eg to get them to check it >>>> doesn't break anything, or to test it as you are developing it), use an >>>> imp-flow feature branch. >>>> >>> what is imp-flow vs git-flow? is this a typo? >>> >>> -if you are developing a new module or other large body of related >>>> code, create a new module in another repository and develop it against the >>>> release version of IMP >>>> >>> Why not the develop branch? It could be expected that the new module >>> will be available for the next release, and it doesn't make sense to treat >>> it as a hotfix either! >>> >>> Using a branch (feature or hotfix) allows changes to be shared and >>>> inspected more easily. I'll update the wiki with the above ideas. >>>> >>>> >>>> and by wiki, you mean: https://github.com/salilab/**imp/wikihttps://github.com/salilab/imp/wiki >>> >>> ______________________________**_________________ >>> IMP-dev mailing list >>> IMP-dev@salilab.org >>> https://salilab.org/mailman/**listinfo/imp-devhttps://salilab.org/mailman/listinfo/imp-dev >>> >> >> _______________________________________________ >> IMP-dev mailing list >> IMP-dev@salilab.org >> https://salilab.org/mailman/listinfo/imp-dev >> >> >> >> _______________________________________________ >> IMP-dev mailing list >> IMP-dev@salilab.org >> https://salilab.org/mailman/listinfo/imp-dev >> >> > > > -- > Barak > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev > >
I found this intro to git very helpful
http://www.youtube.com/watch?v=7N6VBtkCHSQ
On Wed, Apr 17, 2013 at 10:35 PM, Riccardo Pellarin < pellarin.riccardo@gmail.com> wrote:
> great! thanks! > > > On Wed, Apr 17, 2013 at 8:58 PM, Barak Raveh barak.raveh@gmail.comwrote: > >> Riccardo hi >> >> Hugest difference from svn in git is that you also have a local >> repository, so you can checkout locally without updating the remote >> repoisotory. So it is worthwhile learning git a bit on its own indeed. THAT >> BEING SAID, if you just want to clone a fresh version of IMP develop branch >> from the github repository, do a few changes, commit them ("add" "commit" >> and "push" in git terminology), and update occasionally with the main IMP >> repository ("pull" in git terminology), then go here: >> https://github.com/salilab/imp/wiki/Getting-started-as-a-developer >> >> in general, a quick and very inaccurate conversion guide: >> *(1) svn checkout URL* >> ==> git clone URL >> * >> * >> *(2) svn commit -m "MESSAGE"* >> ==> git commit -a -m "MESSAGE" ; git push >> or >> ==> git add <specific files/folders> ; git commit -m "MESSAGE" ; git push >> >> *(3) svn update* >> ==> git pull >> >> *(4) svn log * >> ==> git log >> >> *(5) svn status * >> ==> git status >> >> >> >> >> On Wed, Apr 17, 2013 at 8:38 PM, Daniel Russel drussel@gmail.com wrote: >> >>> There are a ton of git/svn comparisons out there already (google "git vs >>> svn"). I'm not sure we need to produce a new one. But perhaps link to an >>> existing one. >>> >>> On Apr 17, 2013, at 6:02 PM, Riccardo Pellarin < >>> pellarin.riccardo@gmail.com> wrote: >>> >>> In the wiki it would be nice to have a chart with git and >>> svn-equivalent commands (when applies) >>> https://github.com/salilab/**imp/wikihttps://github.com/salilab/imp/wiki >>> >>> >>> On Tue, Apr 16, 2013 at 1:35 AM, Yannick SPILL yannick@salilab.orgwrote: >>> >>>> >>>> For those who didn't follow all of it, have a look at this picture >>>> http://nvie.com/posts/a-**successful-git-branching-**model/http://nvie.com/posts/a-successful-git-branching-model/ >>>> >>>> >>>> - if you are making a large change that, for example, touches a bunch >>>>> of files or will not necessarily be finished before you would like to work >>>>> on something else IMP related, use a git flow feature branch >>>>> - if you are making a change that you would like to share with other >>>>> people before it is committed into develop (eg to get them to check it >>>>> doesn't break anything, or to test it as you are developing it), use an >>>>> imp-flow feature branch. >>>>> >>>> what is imp-flow vs git-flow? is this a typo? >>>> >>>> -if you are developing a new module or other large body of related >>>>> code, create a new module in another repository and develop it against the >>>>> release version of IMP >>>>> >>>> Why not the develop branch? It could be expected that the new module >>>> will be available for the next release, and it doesn't make sense to treat >>>> it as a hotfix either! >>>> >>>> Using a branch (feature or hotfix) allows changes to be shared and >>>>> inspected more easily. I'll update the wiki with the above ideas. >>>>> >>>>> >>>>> and by wiki, you mean: https://github.com/salilab/**imp/wikihttps://github.com/salilab/imp/wiki >>>> >>>> ______________________________**_________________ >>>> IMP-dev mailing list >>>> IMP-dev@salilab.org >>>> https://salilab.org/mailman/**listinfo/imp-devhttps://salilab.org/mailman/listinfo/imp-dev >>>> >>> >>> _______________________________________________ >>> IMP-dev mailing list >>> IMP-dev@salilab.org >>> https://salilab.org/mailman/listinfo/imp-dev >>> >>> >>> >>> _______________________________________________ >>> IMP-dev mailing list >>> IMP-dev@salilab.org >>> https://salilab.org/mailman/listinfo/imp-dev >>> >>> >> >> >> -- >> Barak >> >> _______________________________________________ >> IMP-dev mailing list >> IMP-dev@salilab.org >> https://salilab.org/mailman/listinfo/imp-dev >> >> >
participants (4)
-
Barak Raveh -
Daniel Russel -
Riccardo Pellarin -
Yannick Spill