From: Theodore Tso <tytso@mit.edu>
To: Valerie Aurora <vaurora@redhat.com>
Cc: linux-ext4@vger.kernel.org, Eric Sandeen <sandeen@redhat.com>,
Ric Wheeler <rwheeler@redhat.com>
Subject: Re: Fix device too big bug in mainline?
Date: Tue, 4 Aug 2009 16:41:22 -0400 [thread overview]
Message-ID: <20090804204122.GL28678@mit.edu> (raw)
In-Reply-To: <20090804182811.GG9324@shell>
On Tue, Aug 04, 2009 at 02:28:11PM -0400, Valerie Aurora wrote:
> On Sat, Aug 01, 2009 at 10:22:09PM -0400, Theodore Tso wrote:
> > In case people are wondering why it's taking so long to merge the
> > 64-bit patch series, let me show one patch as exhibit 'A' about how
> > not to submit patches to me (or Linus, or any other upstream
> > maintainer):
>
> Oh, geez, those are an old patch set! I did go back and fix the
> temporary commits and dangly semi-colons, plus reimplemented progress
> meters the way you wanted:
>
> http://osdir.com/ml/linux-ext4/2009-02/msg00591.html
Oh, I see what happened. It looks like you fixed some of that up in
the "shared-64bit-handover" branch, but I didn't see that one, since
you checked in the bug fixes and patches which Nick Dokus submitted
into the "shared-64bit" branch. Hence, the shared-64bit branch had
commits in it dating from May, 2009, while the shared-64bit-handover
branch had commits dating from February, 2009. Hence, I started work
using the shared-64bit branch instead of the shared-64bit-handover
branch.
This is, by the way, why I believe using a patch queue is a
****much**** better way of working, instead of using multiple git
branches. I'm guessing that when Nick started submitting patches, you
got confused and applied his patches onto the wrong branch, and so of
course I used the latest, new version of the 64-bit branch --- which
meant that I got Nick's fixes, but not your cleanups. Argh....
I wish I had figured this out much earlier, since at this point, I've
done so much work using the non-cleaned-up patches, including merging
around a third of the patches into e2fsprogs mainline, that it's
probably not worth it to go back.
- Ted
next prev parent reply other threads:[~2009-08-04 20:41 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-30 21:53 Fix device too big bug in mainline? Valerie Aurora
2009-08-02 0:28 ` Theodore Tso
2009-08-02 2:22 ` Theodore Tso
2009-08-02 3:49 ` Theodore Tso
2009-08-03 20:11 ` Valerie Aurora
2009-08-03 20:27 ` spatch for 64-bit e2fsprogs (was Re: Fix device too big bug in mainline?) Valerie Aurora
2009-08-03 22:56 ` Valerie Aurora
2009-08-04 6:40 ` Julia Lawall
2009-08-04 14:48 ` Theodore Tso
2009-08-04 18:18 ` Valerie Aurora
2009-08-04 19:24 ` Andreas Dilger
2009-08-04 19:58 ` Valerie Aurora
2009-08-04 20:32 ` Theodore Tso
2009-08-04 18:28 ` Fix device too big bug in mainline? Valerie Aurora
2009-08-04 20:41 ` Theodore Tso [this message]
2009-08-04 21:29 ` Valerie Aurora
2009-08-04 22:12 ` Theodore Tso
2009-08-04 23:56 ` Theodore Tso
2009-08-03 18:04 ` Valerie Aurora
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090804204122.GL28678@mit.edu \
--to=tytso@mit.edu \
--cc=linux-ext4@vger.kernel.org \
--cc=rwheeler@redhat.com \
--cc=sandeen@redhat.com \
--cc=vaurora@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).