linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "John W. Linville" <linville@tuxdriver.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Dan Williams <dcbw@redhat.com>,
	Holger Schurig <hs4233@mail.mn-solutions.de>,
	linux-wireless@vger.kernel.org, libertas-dev@lists.infradead.org
Subject: Re: [PATCH] fewer eventcause shifts
Date: Tue, 4 Dec 2007 11:57:45 -0500	[thread overview]
Message-ID: <20071204165745.GM19911@tuxdriver.com> (raw)
In-Reply-To: <1196785655.13978.333.camel@pmac.infradead.org>

On Tue, Dec 04, 2007 at 04:27:35PM +0000, David Woodhouse wrote:
> On Tue, 2007-12-04 at 11:12 -0500, John W. Linville wrote:

> > Keeping a clean patch stack at the top is the only way I know to
> > come close to guaranteeing you have mergeable patches.  Beyond that,
> > I'll work with you the best that I can.
> 
> Again you're talking of 'patches'. But if we're using "git as git", then
> it isn't about guaranteeing you have mergeable _patches_. It's about
> guaranteeing you have a mergeable _tree_.

This might be true if there were a guarantee that no one would rebase
from you to me to Jeff/Dave to Linus.  Experience tells me that I can't
guarantee the "Jeff/Dave" part of that chain.  Given that, experience
also tells me that when your patches pop-up in their rebase operation
that they will look like your original commit and not have any fixups
included as part of any 'git merge' along the way.  So by not rebasing
your patches (or insisting that you do so) before sending them along,
I'm making life harder for Jeff/Dave.  Since they handle even more
patches than I do, that seems to fall under the "not cool" category.

> On Tue, 2007-12-04 at 11:14 -0500, John W. Linville wrote:
> > If the new patches come fast enough to guarantee that then I have to
> > believe that we can work-out how to merge the new patches on top of
> > what I've already sent.  So, I would prefer to let the pull request
> > I sent today stand.
> 
> OK, that's fine, I think. Because if you've actually sent the pull
> request, then I can use those _commits_ and those will be the ones which
> turn up upstream. Those patches won't get recommitted, cherry-picked,
> rebased or otherwise mangled so that they're no longer the same commits
> that I'm basing my tree on.

You might presume so, and you might even be right this time around.
But, I think you presume too much in this case.

> Which branch of yours contains the commits (not patches) which are
> actually going upstream? I'll throw away my tree and rebase it on that.

I have asked Jeff to pull the 'upstream-jgarzik' branch, which contains
the libertas patches.

John
-- 
John W. Linville
linville@tuxdriver.com

      reply	other threads:[~2007-12-04 16:58 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-28  8:15 [PATCH] less eventcause shifts Holger Schurig
2007-11-28 14:53 ` Dan Williams
2007-11-28 15:02   ` David Woodhouse
2007-11-28 15:13     ` Holger Schurig
2007-11-28 15:22       ` Dan Williams
2007-11-28 16:29       ` David Woodhouse
2007-11-29  9:32         ` Holger Schurig
2007-11-28 15:21     ` Dan Williams
2007-12-03 17:58 ` Dan Williams
2007-12-03 20:48   ` David Woodhouse
2007-12-03 21:17     ` Dan Williams
2007-12-04 14:54     ` John W. Linville
2007-12-04 15:07       ` David Woodhouse
2007-12-04 15:06         ` Dan Williams
2007-12-04 15:21           ` David Woodhouse
2007-12-04 15:11         ` David Woodhouse
2007-12-04 15:21         ` John W. Linville
2007-12-04 15:29           ` David Woodhouse
2007-12-04 16:00             ` Dan Williams
2007-12-04 16:14               ` John W. Linville
2007-12-04 16:17                 ` Dan Williams
2007-12-04 16:12             ` John W. Linville
2007-12-04 16:27               ` [PATCH] fewer " David Woodhouse
2007-12-04 16:57                 ` John W. Linville [this message]

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=20071204165745.GM19911@tuxdriver.com \
    --to=linville@tuxdriver.com \
    --cc=dcbw@redhat.com \
    --cc=dwmw2@infradead.org \
    --cc=hs4233@mail.mn-solutions.de \
    --cc=libertas-dev@lists.infradead.org \
    --cc=linux-wireless@vger.kernel.org \
    /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).