On 26-02 02:43, Andrei Pelinescu-Onciul wrote:
On Feb 26, 2009 at 02:15, Jan Janak jan@iptel.org wrote:
On 24-02 12:13, Andrei Pelinescu-Onciul wrote:
[...]
- if someone working on the ser_30 branch (for example) finds a problem in the core and wants to fix it, it has to do it on the master branch.Switching branches in git is not that convenient if you are in the middle of some bigger changes and you have lots of uncommited changes. That practically means that you would have to clone the repository again, discard your local changes in the new clone and checkout another branch (master). Then you need to switch back to your original repository and merge the changes you just did on the master branch.
That could be done much more easier with git stash (I use it a lot): git stash save "my changes" git checkout master ... git stash pop # applies saved changes
Moreover I don't expect that the situation in which you are working on some project specific branch and you have to do some changes on the common part will occur so often (it does now, because we still need to do frequent "adjustments" as testing/integration progresses, but it will change).
Note also that having 3 repos will not help here (you'll still have to do common part changes on the sip-router repo/main) and I don't think you could use git stash in this case (unless you import all into the same local repository).
I've tried git stash but it does not integrate well with my emacs editing workflow. I'm much faster with multiple repositores because I can access them all at the same time from emacs.
Anyway, I feel easy about switching to branches inside one repository and I would not impose any restrictions on the master branch now, let's be open and see if we can get away with it.
I should also add that our current workflow is most likely more difficult than it will be in the future as we consolidate our stuff. We now have all the cvs/svn synchronization going on, in various repositories, filtered and unfiltered. That won't be needed in the future (at least not that much).
Jan.