mac80211 trees during the merge window

mac80211 trees during the merge window

[Johannes Berg]

Hi,

In order to not lose patches or have too many to catch up to, I'm going
to keep applying patches to the mac80211{,-next} trees. That does mean,
however, that I'm going to have to _rebase_ once the merge window closes
and John respins his trees. It also means that in the unlikely event
that I applied your patch but I have major issues with it during the
rebase, I might ask you to resend it then, but I don't actually expect
that to happen.

I'll send pull requests only after all of that happens, obviously.

johannes

Re: mac80211 trees during the merge window

[Kalle Valo]

Johannes Berg <johannes@sipsolutions.net> writes:

> In order to not lose patches or have too many to catch up to, I'm going
> to keep applying patches to the mac80211{,-next} trees. That does mean,
> however, that I'm going to have to _rebase_ once the merge window closes
> and John respins his trees.

Good idea. But why do you need to rebase?

I think it's ok just send a merge request even if the base commit is not
Linville's HEAD, but few weeks older. And once John has merged your pull
request you just merge back John's tree (which apparently looks like a
rebase, at least it did for me) and both trees have same HEAD again. I
recall doing this with ath6kl.git and it didn't have any problems, and
it's so much nicer for the users of your tree.

-- 
Kalle Valo

Re: mac80211 trees during the merge window

[Johannes Berg]

On Mon, 2012-10-01 at 16:53 +0300, Kalle Valo wrote:
> Johannes Berg <johannes@sipsolutions.net> writes:
> 
> > In order to not lose patches or have too many to catch up to, I'm going
> > to keep applying patches to the mac80211{,-next} trees. That does mean,
> > however, that I'm going to have to _rebase_ once the merge window closes
> > and John respins his trees.
> 
> Good idea. But why do you need to rebase?
> 
> I think it's ok just send a merge request even if the base commit is not
> Linville's HEAD, but few weeks older. And once John has merged your pull
> request you just merge back John's tree (which apparently looks like a
> rebase, at least it did for me) and both trees have same HEAD again. I
> recall doing this with ath6kl.git and it didn't have any problems, and
> it's so much nicer for the users of your tree.

Yes, good point, that should work as well. If anything goes wrong with
that though (like merge conflicts), I'd rather rebase I think.

johannes