All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <bonzini@gnu.org>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] patch-id: Add support for mbox format
Date: Fri, 16 Apr 2010 23:52:15 +0200	[thread overview]
Message-ID: <4BC8DC0F.5010007@gnu.org> (raw)
In-Reply-To: <7vochjay8a.fsf@alter.siamese.dyndns.org>

On 04/16/2010 11:23 PM, Junio C Hamano wrote:
>>>>   I have an alias that takes two arguments and compares their patch IDs.
>>>>   I would like to use to make sure I've tested exactly what I submit
>>>>   (patch by patch), like
>>>>
>>>>       git patch-cmp origin/master.. file-being-sent
>>>> ...
>>>
>>> I somehow have a feeling that this is solving a wrong problem.
>>
>> In what sense?
>
> Why does file-being-sent have anything from origin/master to begin with?
> Perhaps the --ignore-if-in-upstream mechanism needs to be updated so that
> you won't have duplicates that patch-id could easily find in the first
> place?

I think we're speaking about different things, --ignore-if-in-upstream 
doesn't have anything to do with this.  The git patch-cmp alias is just 
checking that

   git show origin/master.. | git patch-id | tac | awk '{print $1}'

and

   git patch-id < file-being-sent | awk '{print $1}'

produce the exact same output.

I use this when I had to edit the file-being-sent, e.g. to add cover 
letters or an introduction to a patch series.  Since some time passes 
between format-patch and send-email, I want to test that the file I'm 
sending is exactly what I have in the repository, and that I'm not 
submitting the wrong series.

Alternatively, I could apply file-being-sent to a detached HEAD and 
compare the trees, like

   topic=`git rev-parse HEAD`
   git checkout origin/master
   git am file-being-sent || echo bad
   mine=HEAD
   for i in `git rev-list origin/master..$topic`; do
     git diff-tree $i $mine || echo bad
     mine=${mine}^
   done

However, comparing the patch-id is faster and perfect for this job. 
What were your intended uses for the git-patch-id utility?

Paolo

  reply	other threads:[~2010-04-16 21:52 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-16 16:22 [PATCH] patch-id: Add support for mbox format Paolo Bonzini
2010-04-16 18:30 ` Junio C Hamano
2010-04-16 20:55   ` Paolo Bonzini
2010-04-16 21:23     ` Junio C Hamano
2010-04-16 21:52       ` Paolo Bonzini [this message]
2010-04-17  2:43         ` Junio C Hamano
2010-04-19  8:46           ` [PATCH 1/2] patch-id: extract parsing one diff out of generate_id_list Paolo Bonzini
2010-04-19  8:46             ` [PATCH 2/2] patch-id: Add support for mbox format Paolo Bonzini
2010-04-19 21:48               ` Junio C Hamano
2010-04-20  8:47                 ` Paolo Bonzini
2010-04-20 16:54                   ` 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=4BC8DC0F.5010007@gnu.org \
    --to=bonzini@gnu.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.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 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.