On Thu, Feb 26, 2015 at 4:49 PM, Matt <jackdachef@xxxxxxxxx> wrote:
Hi linux-btrfs list, Hi Chris, Hi Josef, it seemingly happened in the past and now it seems to happen again: after patches have been posted to the linux-btrfs mailing list and pulled by Linus, changes occured and additional pull-requests followed - the old commits don't appear to be anywhere accessible besides Linus' tree example: http://marc.info/?l=linux-btrfs&m=142203898505309&w=2 [GIT PULL] Btrfs fixes from January 23rd
Sorry for the confusion. What happens is that I send Linus pulls for the things he's missing, and we have slightly parallel development branches.
Before 3.19-rc1, I forked 3.18-rc5 and rebased my 3.19 merge window on top of that. All of my commits for 3.19 went on top of this branch.
I forked our tree for the 4.0 merge window at 3.19-rc5. This is where all the 4.0 commits went. But, 3.19 kept rolling and we had additional fixes in before 3.19-final.
I use the same branch for every pull to Linus (for-linus), so during 3.19-rc6 I sent him code on top of for-linus, which at the time was based on 3.18-rc5 and had all my 3.19 code in it.
Then the 4.0 merge window started and I switched to my 3.19-rc5 based merge window tree, which was actually missing the commit you mentioned because Linus took it after rc5.
It all works for Linus because git merges things easily, and he actually prefers that you don't merge in later releases unless you need some fix to keep things stable. In other words, if my for-linus for the 4.0 merge window has a merge with 3.19-final, he may push back.
In general, you can take my for-linus on top of the last released Linus kernel and have all the current commits that are considered stable.
In the future, I'll keep a for-linus-xxyyzz for the last release to make this less confusing.
-chris -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
