git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Nicolas Pitre <nico@fluxnic.net>
Cc: Sverre Rabbelier <srabbelier@gmail.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Junio C Hamano <gitster@pobox.com>,
	Juliusz Chroboczek <jch@pps.jussieu.fr>,
	git@vger.kernel.org
Subject: Re: git-format-patch should include a checksum
Date: Tue, 26 Jan 2010 17:25:44 -0800	[thread overview]
Message-ID: <7v4om8xrs7.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <alpine.LFD.2.00.1001262006150.1681@xanadu.home> (Nicolas Pitre's message of "Tue\, 26 Jan 2010 20\:13\:56 -0500 \(EST\)")

Nicolas Pitre <nico@fluxnic.net> writes:

> FWIW, I do manually edit both incoming and outgoing patches from time to 
> time as well.

Me three.

> I think what would be even more useful at first is to find out why 
> corrupted patches still apply.

Exactly.  That is why I asked that question at the very beginning.

> ... Just 
> applying the patch to that blob and confirming it matches the postimage 
> SHA1 should cover many cases already.

That would work when you are/have the sole authority (so contributors
won't send patches based on some other trees), you push out often (to keep
the length of the patch queue contributors keep short).

That would make it more likely that others base their work on what you
published, and send patches from their base version all the way (not
skipping "this is what I sent earlier but haven't been accepted nor pushed
out").  Otherwise it will be unlikely that you have the object recorded as
the preimage.  Often when I receive follow-up patches from people, some
are based on what was committed by me (possibly with tweaks), and some
others are based on what was seen on the list (lacking the tweaks), yet
some others are based on random other versions.  I'll have preimages only
in the first case.

Usually while editing incoming patch text (not log message), you mostly
touch postimage, but when fixing up a diff that was based on a bit stale
version, you need to touch preimage as well.  In these cases, the blob
object names recorded in the patch wouldn't be very useful.

  reply	other threads:[~2010-01-27  1:28 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-26 22:34 git-format-patch should include a checksum Juliusz Chroboczek
2010-01-26 23:15 ` Sverre Rabbelier
2010-01-26 23:21 ` Junio C Hamano
2010-01-26 23:26   ` Sverre Rabbelier
2010-01-27  0:45     ` Linus Torvalds
2010-01-27  0:50       ` Sverre Rabbelier
2010-01-27  1:13         ` Nicolas Pitre
2010-01-27  1:25           ` Junio C Hamano [this message]
2010-01-27  1:25   ` Juliusz Chroboczek
2010-01-27  1:35     ` Junio C Hamano
2010-01-27  3:01     ` Junio C Hamano

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=7v4om8xrs7.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=jch@pps.jussieu.fr \
    --cc=nico@fluxnic.net \
    --cc=srabbelier@gmail.com \
    --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;
as well as URLs for NNTP newsgroup(s).