On Feb 26, 2009 at 02:15, Jan Janak
<jan(a)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.