On 26-02 02:43, Andrei Pelinescu-Onciul wrote: > On Feb 26, 2009 at 02:15, Jan Janak <[email protected]> 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. _______________________________________________ Serdev mailing list [email protected] http://lists.iptel.org/mailman/listinfo/serdev
