On Friday 19 April 2013 19:28:29 William S Fulton wrote:
> On 23/03/13 13:15, Geert Janssens wrote:
> > A meta question...
> > I have cloned the master repository and have been playing on a private
> > branch for my guile updates.
> > I don't think my work is ready yet to be merged into the main repo. But
> > I'd like to publish what I have so far to gather feedback.
> > Since I have been working on a private branch so far, it was easy to
> > rebase my branch to the latest master HEAD. But I read here and there
> > that rebasing published branches is not really recommended.
> > So I wonder what swig's public branch policy is ?
> In the official swig repo, it will be frowned upon to rebase.
> > I can push my branch to a cloned git repo, so others can look into it
> > there or pull it into their own local repos. Can I still rebase it
> > afterwards without causing too much frustration for other developers ?
> For your own clone, you can do what you like. If other people are
> collaborating with you in your repo, then rebasing would be a bad idea.
> How about a private guile dev branch that you merge to a public guile
> dev branch which you advertise for general use?
> > Or should I start merging the master branch into my personal branch
> > regularly from there on ?
> Yup. Eventually I'd like one patch to apply to master for your initial
> guile update. We could do it via a merge from your repo/branch, but it
> seems that git bisect doesn't like branches, so I'm wondering if we
> should avoid branches and keep the development linear. It seems there
> are two schools of thought on best development practices for git, but we
> are still learning our way.
From some quick search on the internet, it seems that bisect can work perfectly fine with branches (1). But I haven't had real life experience with bisection across branches myself so I'm in no position to actually make statements about best practice. If you like to keep development linear, how about cherry-picking the individual commits on my branch ?
I'm currently at 6 commits. Two for the actual introduction of guile 2.0 support, one cleanup commit before, one for dropping guile 1.6 support, one for dropping the guile gh interface and the last one to fix the deprecation warnings.
Theoretically I could reduce this into one big patch, but that would make it much harder to understand what I actually did and why. So I prefer to keep them in separate commits.