git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Vegard Nossum <vegard.nossum@oracle.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Johan Herland <johan@herland.net>,
	"Jason A. Donenfeld" <Jason@zx2c4.com>,
	Christian Hesse <mail@eworm.de>
Subject: Re: [RFC PATCH 1/2] notes: support fetching notes from an external repo
Date: Wed, 3 Aug 2022 10:09:03 +0200	[thread overview]
Message-ID: <69fd9dcf-7769-6c5c-ca0e-ea61e6d616d9@oracle.com> (raw)
In-Reply-To: <xmqqczdiirh8.fsf@gitster.g>


On 8/2/22 17:40, Junio C Hamano wrote:
> Vegard Nossum <vegard.nossum@oracle.com> writes:
> 
>> Notes are currently always fetched from the current repo. However, in
>> certain situations you may want to keep notes in a separate repository
>> altogether.
>>
>> In my specific case, I am using cgit to display notes for repositories
>> that are owned by others but hosted on a shared machine, so I cannot
>> really add the notes directly to their repositories.
> 
> My gut reaction is that I am not interested at all in the above
> approach, even though the problem you are trying to solve is
> interesting.  Mostly because notes are not the only decorations your
> users may want.  What if you want to "log --decorate" their
> repository contents with your own tags that annotate their commits?
> A notes-only approach to mix repositories is way too narrow.
> 
> A usable alternative _might_ be to introduce a way to "borrow" refs
> and objects from a different repository as if you cloned from and
> continuously fetching from them.  We already have a mechanism to
> borrow objects from another repository in the form of "alternate
> object database" that lets us pretend objects in their repository
> are locally available.  We can invent a similar mechanism that lets
> any of their ref as if it were our local ref, e.g. their "main"
> branch at their refs/heads/main might appear to exist at our
> refs/borrowed/X/heads/main.  

Hi Junio,

Thanks for the reply.

To be clear, are you saying there is no way you would ever take my
patches in their current form, even though they only rearrange internal
workings (and have no other user-observable effects) to solve a problem
I am currently facing?

The thing is, I personally have no use for displaying refs borrowed from
another repository at this time, and I'm not sure I have either the time
or the ability to provide what you are asking for.

I don't think my patches preclude adding "borrowed refs" as a feature at
a later time, so can we not do that when somebody actually has a use for it?

Just to provide a bit more background: These two patches are just the
first two in a bigger project to make extensive use of git notes to
provide added value to the whole Linux kernel community -- in other
words, this is not just for myself, I am trying here to upstream our
internal patches for the benefit of everybody. I have cgit patches as
well (but I'm waiting to submit them until git can support them) and
hundreds of thousands of notes annotating Linux kernel commits with
useful information.

Respectfully,


Vegard

  reply	other threads:[~2022-08-03  8:09 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-02  7:54 [RFC PATCH 1/2] notes: support fetching notes from an external repo Vegard Nossum
2022-08-02  7:54 ` [RFC PATCH 2/2] notes: create interface to iterate over notes for a given oid Vegard Nossum
2022-08-02 15:40 ` [RFC PATCH 1/2] notes: support fetching notes from an external repo Junio C Hamano
2022-08-03  8:09   ` Vegard Nossum [this message]
2022-08-03 22:32     ` Junio C Hamano
2022-08-30 14:17 ` Philip Oakley
2022-10-17 13:14   ` Vegard Nossum
2022-10-19  9:15     ` Philip Oakley

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=69fd9dcf-7769-6c5c-ca0e-ea61e6d616d9@oracle.com \
    --to=vegard.nossum@oracle.com \
    --cc=Jason@zx2c4.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=johan@herland.net \
    --cc=mail@eworm.de \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).