On 01/24/2013 01:13 PM, David Sterba wrote:
On Tue, Jan 22, 2013 at 03:14:35PM -0500, Gene Czarcinski wrote:
On 01/21/2013 01:40 PM, David Sterba wrote:
On Sun, Jan 20, 2013 at 04:04:05PM -0500, Gene Czarcinski wrote:
I have done some additional scraping of the mailing list to
identify some "low hanging fruit" which I consider should
be merged into the btrfs-progs repository.
Thanks, I went through them and put together into an integration branch
git://repo.or.cz/btrfs-progs-unstable/devel.git integration-20130121
There is a problem with one of the patches:
detect if the disk we are formatting is a ssd
The commit comments appear to come from the patch I submitted. However, as I
said in the submission, the patch for mkfs.c has to be "refitted" because of
a conflict. The conflict is a result of the patch:
Fix compiler warnings on PPC64
which relocated the include "kerncompat.h" to a different line in the mkfs.c
file.
These merge conflicts are inevitable and normal (though sometimes not
that trivial). My initial aim was to build one linear branch only with
fixes and git-merge the patches that add features, but this will not be
easy to merge for much longer, so I'm going to do a linear integration
branch so others can take them as checkpoint to base the various
patchsets.
Yes, trying to merge branches with lots of changes are effectively
impossible (impractical?) as far as I am concerned. Unless it is simple
I I understand exactly what is happening, I have found it easier/better
to apply a set of patches one at a time and resolve problems manually.
I just got the subvol show patches applied. I tried putting it into a
separate branch and then doing a merge but I could not trust my results
when I ran mergetool. And, BTW they subvol show patches to apply with
not very many problems. My working branch currently has 44 commits over
91d9eec and subvol show added another ten.
Gene
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
