All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Michael Haggerty <mhagger@alum.mit.edu>,
	git@vger.kernel.org, Johan Herland <johan@herland.net>,
	Jonathan Nieder <jrnieder@gmail.com>
Subject: Re: Idea: "git format-patch" should get more information out of git
Date: Mon, 29 Aug 2011 14:55:46 -0400	[thread overview]
Message-ID: <20110829185546.GD756@sigill.intra.peff.net> (raw)
In-Reply-To: <7v1uw69h96.fsf@alter.siamese.dyndns.org>

On Sat, Aug 27, 2011 at 11:34:13PM -0700, Junio C Hamano wrote:

> Junio C Hamano <gitster@pobox.com> writes:
> 
> > Michael Haggerty <mhagger@alum.mit.edu> writes:
> >
> >> 4. There is no place to store the "additional information" (the part
> >> that comes in patch emails between the "---" and the diffstat) while
> >> working on the patch series;...
> >
> > I thought there was a RFC floating around to do this using notes and also
> > teach it to "commit -e" a few months ago? I vaguelly recall that Peff and
> > one of the J's were involved, so I am CC'ing them.
> 
> Also, when I prepare a commit to be sent with an additional piece of
> information, I often write "---" and the additional message after my
> S-o-b: line while preparing the commit log message. Unlike format-patch
> that strips that off, commit keeps it, which is handy.

After playing around a bit with my earlier series, I made the
realization (perhaps obvious to others :) ), that if you are in a
pure-patch workflow, keeping the "---" in your commit message locally is
much simpler. It follows the commit around through rebases
automatically, it gets put into format-patch output automatically, and
so forth.

The only real downside is that you can never tell git "don't show me the
cover letter cruft". Which is probably OK for your own local patches.
But the point of the "---" is that information should never make it into
a repo, which means in any workflow that involves pulling actual git
commits, it won't work (after reading Michael's response in another
thread, though, I think he would be interested in a hybrid
pull-or-apply-via-mail system).

-Peff

  reply	other threads:[~2011-08-29 18:55 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-27  5:12 Idea: "git format-patch" should get more information out of git Michael Haggerty
2011-08-27 18:46 ` Junio C Hamano
2011-08-27 20:35   ` Michael J Gruber
2011-08-28  6:21     ` Michael Haggerty
2011-08-28  6:34   ` Junio C Hamano
2011-08-29 18:55     ` Jeff King [this message]
2011-08-30 12:21       ` Michael J Gruber
2011-08-30 15:22         ` Jeff King
2011-08-30 15:41           ` Michael J Gruber
2011-08-30 17:39             ` Johan Herland
2011-09-01  4:32               ` Michael Haggerty
2011-09-01  6:44                 ` Michael J Gruber

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=20110829185546.GD756@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=johan@herland.net \
    --cc=jrnieder@gmail.com \
    --cc=mhagger@alum.mit.edu \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.