On Mon, 30 Jun 2014, Johan Hovold wrote:

quoted

I think the better place is HID/input tree, since this patch depends
on the initial one which is not in my tree.
I'm going to merge Johan's whole patchset and this patch probably
depends Johan's work too.

Dmitry has ACKed the input-patch and Bryan has applied that one and the
leds-patches to his tree (of which the first one is a dependency of this
patch).

Jiri, are you saying that the gt683r-driver should go in through his
tree as well, that is all three patches including the first that you
have already applied? I just assumed your for-next branch was immutable,
but perhaps I was mistaken.

Well, for-next branch is a collection of all the topic branches I am 
queuing for the following merge window.

I am never really rebasing it, but I can definitely not include 
'for-3.17/hid-gt683r' topic branch in the pile I will be sending to Linus 
(all the scheduled branches are getting merged into 'for-linus' only when 
merge window open). So the only potential conflict between hid.git and 
Bryan's tree would be in linux-next (and probably there will be none, git 
can handle duplicate patches nicely).

So once Bryan confirms he's queued it (please preserve my Signoff from my 
tree), then I will just not include for-3.17/hid-gt683r branch in pull 
request to Linus and all is fine.

Thanks,

-- 
Jiri Kosina
SUSE Labs