| 1 |
On Sat, 2013-06-01 at 16:35 -0400, W. Trevor King wrote: |
| 2 |
> On Sat, Jun 01, 2013 at 12:48:13PM -0700, Brian Dolbec wrote: |
| 3 |
> > I've updated my rewrite with the other changes to master since I did |
| 4 |
> > started the rewrite branch. Some commits were just cherry-picked |
| 5 |
> > across, some needed minor editing to suit. |
| 6 |
> |
| 7 |
> In other projects I'm involved in, the preferred approach is to rebase |
| 8 |
> the feature branch onto the current master. The problem with cherry |
| 9 |
> picking master advances onto your feature branch is that anyone else |
| 10 |
> with feature branches based on the current master will have to rebase |
| 11 |
> *their* feature branches to keep up with your branch. If the person |
| 12 |
> proposing the changes does the rebasing, that's only a single branch |
| 13 |
> that has to be rebased, which scales better ;). |
| 14 |
> |
| 15 |
> Cheers, |
| 16 |
> Trevor |
| 17 |
> |
| 18 |
|
| 19 |
I didn't realize that. I can throw <some> blame towards Jorge who asked |
| 20 |
me to update my branch with the master additions. |
| 21 |
|
| 22 |
Well they weren't that tough, so I should be able to redo it. But my |
| 23 |
rewrite is more than just a feature. I am restructuring the entire code |
| 24 |
base. And the more my branch diverges the harder it gets to constantly |
| 25 |
rebase... |
| 26 |
|
| 27 |
It's stuff like this that I hate working in side branches :/ while |
| 28 |
development continues in the master. At some point, the decision has to |
| 29 |
be made to switch development, just maintain the old with needed bug |
| 30 |
fixes in a renamed side branch. Port the bug fixes that still apply to |
| 31 |
the new development branch. |
| 32 |
-- |
| 33 |
Brian Dolbec <dolsen@g.o> |
Archives