Em 18-05-2011 03:43, Marius Mårnes Mathiesen escreveu:
On Mon, May 16, 2011 at 11:38 PM, Christian Johansen
<[email protected] <mailto:[email protected]>> wrote:
I'm not entirely sure how to handle this either, but I do know I
want to keep the rails-3.1 branch up to date in case anyone else
wants to chip in. As far as I know, the branch Marius pushed today
is currently a spike, and it's not given that will merge it as is
(Marius will have to confirm this). Maybe Marius has some input on
the process going forward too.
Well, I'm trying to keep the search stuff in master, not breaking
anything. As for rebasing, wouldn't it be best if you rebase as you
see fit? That's probably the best way to avoid diverging the two
branches too much?
Sorry, who is "you" here? And I think we should always rebase as soon as
master advances for easying the process...
But I think it would be simpler if there was a single person doing the
rebase.
Here is the problem. If I do the rebase, all commits change so that the
only way to check if the original commits were not modified is to
re-check all of them.
When I do the rebase *I* know that I've changed nothing on them unless
there was some conflict. In that case, I know how I managed it, but the
other ones would need to re-check them all again.
I'm ok if someone will be responsible for rebasing it since I rely on
both you. After rebasing I would checkout your rebase and than proceed
with my commits.
The other way is merging master from time to time so that it makes easy
for everyone to check only the last modifications and how eventual
conflicts were solved.
Anyway, I just need to know how we're going to proceed regarding this
synchronization with master. It is important to syncronize as often as
possible or it will be much harder to do it later on, specially when
there are other people working in top of rails-3.1 branch.
Any thoughts?
Rodrigo.
--
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
