git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Eric Wong <e@80x24.org>
Cc: git@vger.kernel.org, Thomas Gummerer <t.gummerer@gmail.com>
Subject: Re: [RFC/WIP] range-diff: show old/new blob OIDs in comments
Date: Tue, 22 Oct 2019 21:18:35 +0200 (CEST)	[thread overview]
Message-ID: <nycvar.QRO.7.76.6.1910222111430.46@tvgsbejvaqbjf.bet> (raw)
In-Reply-To: <20191017121045.GA15364@dcvr>

Hi Eric,


On Thu, 17 Oct 2019, Eric Wong wrote:

> (WIP, mostly stream-of-concious notes + reasoning)
>
> When using "git format-patch --range-diff", the pre and
> post-image blob OIDs are in each email, while the exact
> commit OIDs are rarely shared via emails (only the tip
> commit from "git request-pull").
>
> These blob OIDs make it easy to search for or lookup the
> full emails which create them, or the blob itself once
> it's fetched via git.
>
> public-inbox indexes and allows querying specifically for blob
> OIDs via dfpre:/dfpost: since June 2017.  As of Jan 2019,
> public-inbox also supports recreating blobs out of patch emails
> (querying internally with dfpre:/dfpost: and doing "git apply")
>
> Searching on these blob OIDs also makes it easier to find
> previous versions of the patch sets using any mail search
> engine.
>
> Future changes to public-inbox may allow generating custom
> diffs out of any blobs it can find or recreate.
>
> Most of this is pretty public-inbox-specific and would've
> made some future changes to public-inbox much easier....
> (if we had this from the start of range-diff).
>
> Unfortunately, it won't help with cases where range-diffs
> are already published, but range-diff isn't too old.

I guess your patch won't hurt.

As to recreating blobs from mails: Wow. That's quite a length you're
going, and I think it is a shame that you have to. If only every
contribution came accompanied with a pullable branch in a public
repository.

Instead, we will have to rely on your centralized, non-distributed
service...

Ciao,
Dscho

>
> I'm also still learning my way around git's C internals, but
> using patch.{old,new}_oid_prefix seems alright...
>
> FIXME: tests, t3206 needs updating
>
> Not-signed-off-by: Eric Wong <e@80x24.org>
> ---
>  range-diff.c | 19 +++++++++++++++----
>  1 file changed, 15 insertions(+), 4 deletions(-)
>
> diff --git a/range-diff.c b/range-diff.c
> index 7fed5a3b4b..85d2f1f58f 100644
> --- a/range-diff.c
> +++ b/range-diff.c
> @@ -118,13 +118,24 @@ static int read_patches(const char *range, struct string_list *list)
>  				die(_("could not parse git header '%.*s'"), (int)len, line);
>  			strbuf_addstr(&buf, " ## ");
>  			if (patch.is_new > 0)
> -				strbuf_addf(&buf, "%s (new)", patch.new_name);
> +				strbuf_addf(&buf, "%s (new %s)",
> +						patch.new_name,
> +						patch.new_oid_prefix);
>  			else if (patch.is_delete > 0)
> -				strbuf_addf(&buf, "%s (deleted)", patch.old_name);
> +				strbuf_addf(&buf, "%s (deleted %s)",
> +						patch.old_name,
> +						patch.old_oid_prefix);
>  			else if (patch.is_rename)
> -				strbuf_addf(&buf, "%s => %s", patch.old_name, patch.new_name);
> +				strbuf_addf(&buf, "%s => %s (%s..%s)",
> +						patch.old_name,
> +						patch.new_name,
> +						patch.old_oid_prefix,
> +						patch.new_oid_prefix);
>  			else
> -				strbuf_addstr(&buf, patch.new_name);
> +				strbuf_addf(&buf, "%s (%s..%s)",
> +						patch.new_name,
> +						patch.old_oid_prefix,
> +						patch.new_oid_prefix);
>
>  			free(current_filename);
>  			if (patch.is_delete > 0)
>
>

  reply	other threads:[~2019-10-22 19:18 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-17 12:10 [RFC/WIP] range-diff: show old/new blob OIDs in comments Eric Wong
2019-10-22 19:18 ` Johannes Schindelin [this message]
2019-10-22 19:35   ` Konstantin Ryabitsev
2019-10-23  1:56   ` Eric Wong
2019-10-23  4:11     ` Junio C Hamano
2019-10-24 22:16       ` Johannes Schindelin
2019-10-25  0:12         ` Eric Wong
2019-10-25 13:43           ` Johannes Schindelin
2019-10-23 10:06     ` Eric Wong

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=nycvar.QRO.7.76.6.1910222111430.46@tvgsbejvaqbjf.bet \
    --to=johannes.schindelin@gmx.de \
    --cc=e@80x24.org \
    --cc=git@vger.kernel.org \
    --cc=t.gummerer@gmail.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 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).