public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Greg KH <gregkh@suse.de>, Ingo Molnar <mingo@elte.hu>,
	Andrew Morton <akpm@linux-foundation.org>,
	Chris Wright <chrisw@sous-sol.org>,
	linux-kernel@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>
Subject: Re: [RFC] new -stable tag variant, Git workflow question
Date: Wed, 11 Nov 2009 14:06:50 -0600	[thread overview]
Message-ID: <1257970010.11985.17.camel@mulgrave.site> (raw)
In-Reply-To: <alpine.LFD.2.01.0911111153390.31845@localhost.localdomain>

On Wed, 2009-11-11 at 12:00 -0800, Linus Torvalds wrote:
> 
> On Wed, 11 Nov 2009, James Bottomley wrote:
> > 
> > The slight problem is that further down, to generate the patch the
> > script uses git format-patch -k --stdout commit^..commit.  For a merge
> > commit, this will generate a patch equivalent to the entire branch that
> > was merged, even though the commit message will only pick out some of
> > these ... is this OK?
> 
> Don't do that.
> 
> Since you want to show a single commit, not a commit range, don't use 
> format-patch, use something like
> 
> 	git show --pretty=email -M --cc --stat $commit
> 
> instead. That will not show the difference between a commit and its 
> first parent (which for a merge diff is more than one commit, and can be 
> absolutely _huge_), but will show just the named commit (which for a merge 
> commit will usually be an empty diff, but will show how conflicts were 
> resolved if they weren't just taken from one or the other side).
> 
> (Of course, maybe you'll want to change the exact flags in question. For 
> example, '--stat' for merge commits is often useful, but only if the merge 
> was done by an upper-level maintainer. Anybody who does reverse merges 
> will just get totally meaningless diffstats, since the diffstat is always 
> done against the first parent, so anybody who does back-merges will see 
> the stat of everthing _I_ have merged in the meantime, which is generally 
> not useful)

Right ... that's why I was wondering if Greg still needs the diff.  If
not, I'll just send standard git log output with no diff.  If he does,
I'll use something like the above.

So, now that you're showing an interest in all of this, how about I send
you the final update hook to add to your tree?  It will produce less
latency than the cron job I run on kernel.org to pull your tree into one
I have here ever twenty minutes or so and run the hooks.

James



  reply	other threads:[~2009-11-11 20:06 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-10  3:48 [RFC] new -stable tag variant, Git workflow question Ingo Molnar
2009-11-10  4:14 ` Greg KH
2009-11-10  4:20   ` Ingo Molnar
2009-11-10 14:30     ` James Bottomley
2009-11-10 17:22       ` Ingo Molnar
2009-11-10 17:53         ` Linus Torvalds
2009-11-10 18:06           ` Ingo Molnar
2009-11-10 14:29   ` James Bottomley
2009-11-10 15:52     ` Stefan Richter
2009-11-10 19:12       ` Chris Friesen
2009-11-10 21:20         ` Ingo Molnar
2009-11-10 19:39       ` Greg KH
2009-11-10 20:45         ` Ingo Molnar
2009-11-10 21:11           ` Junio C Hamano
2009-11-10 21:25             ` Greg KH
2009-11-10 21:29             ` Ingo Molnar
2009-11-10 19:37     ` Greg KH
2009-11-10 20:39       ` Ingo Molnar
2009-11-11 18:50       ` James Bottomley
2009-11-11 20:00         ` Linus Torvalds
2009-11-11 20:06           ` James Bottomley [this message]
2009-11-11 20:14             ` Linus Torvalds
2009-11-11 21:43               ` H. Peter Anvin
2009-11-11 21:52                 ` Linus Torvalds
2009-11-12  7:45                   ` Ingo Molnar
2009-11-12 15:15                     ` H. Peter Anvin
2009-11-12 17:01                       ` David Dillow
2009-11-12 19:50                         ` H. Peter Anvin
2009-11-12 14:41                   ` James Bottomley
2009-11-12  4:41         ` Greg KH
2009-11-12 16:11           ` James Bottomley
2009-11-19 18:15             ` Greg KH

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=1257970010.11985.17.camel@mulgrave.site \
    --to=james.bottomley@hansenpartnership.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=chrisw@sous-sol.org \
    --cc=gregkh@suse.de \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.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