git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johan Herland <johan@herland.net>
To: Sverre Rabbelier <srabbelier@gmail.com>
Cc: git@vger.kernel.org, jrnieder@gmail.com, bebarino@gmail.com,
	avarab@gmail.com, gitster@pobox.com
Subject: Re: [PATCHv4 00/21] git notes merge
Date: Fri, 22 Oct 2010 17:41:25 +0200	[thread overview]
Message-ID: <201010221741.25390.johan@herland.net> (raw)
In-Reply-To: <AANLkTi=YJd023C3rX_G+NEM_0N-nZqd0uP7yyTSt1tHj@mail.gmail.com>

On Thursday 21 October 2010, Sverre Rabbelier wrote:
> On Wed, Oct 20, 2010 at 21:08, Johan Herland wrote:
> > - Fetching and pushing note refs:
> >  - Add refs/notes/* to default fetch refspec?
> >  - A way to specify (at clone time) which refspec(s) to set up?
> >  - A way for the remote repo to hint at which refspecs you might
> > want to set up (by default?)
>
> Didn't we already discuss this earlier? Can you summarize (or at
> least link to) that discussion?

Yes, sorry for not answering you earlier. Here's what you wrote in the 
previous thread:

On Saturday 09 October 2010, Sverre Rabbelier wrote:
> Heya,
>
> On Sat, Oct 9, 2010 at 03:08, Johan Herland <johan@herland.net> wrote:
> > - Fetching and pushing note refs:
> >  - Add refs/notes/* to default fetch refspec?
>
> Or at least add a '--notes[=<notes namespace>]' to fetch, pull, and
> push.

Agreed, at least that.

In order to promote sharing of notes, though, I'd like for it to be 
possible to configure the repo so that a vanilla 'git fetch' also 
updates your notes. In fact, I wonder if this should even be made the 
default.

> >  - A way to specify (at clone time) which refspec(s) to set up?
>
> How would that look like?

Maybe add an option to 'git clone' (and 'git remote add') that specifies 
the refspec you want to use in your config for that remote. Something 
like:

  git clone --fetch="+refs/heads/*:refs/remotes/origin/*" \
            --fetch="+refs/notes/*:refs/remotes/origin/notes/*" \
            <source_url> ...

...will set up the following config:

  [remote "origin"]
        url = <source_url>
        fetch = +refs/heads/*:refs/remotes/origin/*
        fetch = +refs/notes/*:refs/remotes/origin/notes/*

Obviously, we would probably want to provide shorthands for the most 
common refspecs, like:

  git clone --fetch=default,notes <source_url> ...

or

  git clone --fetch-heads --fetch-notes <source_url> ...

> >  - A way for the remote repo to hint at which refspecs you might
> > want to set up (by default?)
>
> I assume this would be a generic mechanism of sorts? Are there any
> other use cases for this other than notes?

Yes, I believe so (although I haven't thought much about this, yet). 
There's been earlier discussions on hiding certain branches from view. 
This could maybe be solved by the server suggesting a refspec that 
excludes the stuff you don't want to share (by default). Similary, the 
refspec could _include_ notes namespaces that you do want to share.

Of course (as today) the client should be free to demand a different 
refspec, e.g. if it wants access to everything, or if it's only 
interested in a subset of the "default" refs.


...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net

  parent reply	other threads:[~2010-10-22 15:47 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-21  2:08 [PATCHv4 00/21] git notes merge Johan Herland
2010-10-21  2:08 ` [PATCHv4 01/21] notes.c: Hexify SHA1 in die() message from init_notes() Johan Herland
2010-10-21  2:08 ` [PATCHv4 02/21] (trivial) notes.h: Minor documentation fixes to copy_notes() Johan Herland
2010-10-21  2:08 ` [PATCHv4 03/21] notes.h: Make default_notes_ref() available in notes API Johan Herland
2010-10-21  2:08 ` [PATCHv4 04/21] notes.c: Reorder functions in preparation for next commit Johan Herland
2010-10-21  2:08 ` [PATCHv4 05/21] notes.h/c: Clarify the handling of notes objects that are == null_sha1 Johan Herland
2010-10-21  5:12   ` Jonathan Nieder
2010-10-21 13:13     ` Johan Herland
2010-10-21 17:54       ` Jonathan Nieder
2010-10-22 13:32         ` Johan Herland
2010-10-21  2:08 ` [PATCHv4 06/21] notes.h/c: Propagate combine_notes_fn return value to add_note() and beyond Johan Herland
2010-10-21  5:21   ` Jonathan Nieder
2010-10-21 13:16     ` Johan Herland
2010-10-21  2:08 ` [PATCHv4 07/21] (trivial) t3303: Indent with tabs instead of spaces for consistency Johan Herland
2010-10-21  2:08 ` [PATCHv4 08/21] notes.c: Use two newlines (instead of one) when concatenating notes Johan Herland
2010-10-21  2:08 ` [PATCHv4 09/21] builtin/notes.c: Split notes ref DWIMmery into a separate function Johan Herland
2010-10-21  2:08 ` [PATCHv4 10/21] git notes merge: Initial implementation handling trivial merges only Johan Herland
2010-10-21  2:08 ` [PATCHv4 11/21] builtin/notes.c: Refactor creation of notes commits Johan Herland
2010-10-21  2:08 ` [PATCHv4 12/21] git notes merge: Handle real, non-conflicting notes merges Johan Herland
2010-10-21  2:08 ` [PATCHv4 13/21] git notes merge: Add automatic conflict resolvers (ours, theirs, union) Johan Herland
2010-10-21  2:08 ` [PATCHv4 14/21] Documentation: Preliminary docs on 'git notes merge' Johan Herland
2010-10-21  2:08 ` [PATCHv4 15/21] git notes merge: Manual conflict resolution, part 1/2 Johan Herland
2010-10-21  2:08 ` [PATCHv4 16/21] git notes merge: Manual conflict resolution, part 2/2 Johan Herland
2010-10-21  2:08 ` [PATCHv4 17/21] git notes merge: List conflicting notes in notes merge commit message Johan Herland
2010-10-21  2:08 ` [PATCHv4 18/21] git notes merge: --commit should fail if underlying notes ref has moved Johan Herland
2010-10-21  2:08 ` [PATCHv4 19/21] git notes merge: Add another auto-resolving strategy: "cat_sort_uniq" Johan Herland
2010-10-21  2:08 ` [PATCHv4 20/21] git notes merge: Add testcases for merging notes trees at different fanouts Johan Herland
2010-10-21  2:08 ` [PATCHv4 21/21] Provide 'git notes get-ref' to easily retrieve current notes ref Johan Herland
2010-10-21 21:00 ` [PATCHv4 00/21] git notes merge Sverre Rabbelier
2010-10-21 23:20   ` Junio C Hamano
2010-10-21 23:30     ` Jonathan Nieder
2010-10-22 14:11     ` git merge --abort? [was: Re: [PATCHv4 00/21] git notes merge] Johan Herland
2010-10-22 14:55       ` Jonathan Nieder
2010-10-22 15:12         ` Johan Herland
2010-10-22 15:20           ` Sverre Rabbelier
2010-10-22 15:48             ` Jonathan Nieder
2010-10-22 15:57               ` Sverre Rabbelier
2010-10-22 15:41   ` Johan Herland [this message]
2010-10-22 15:54     ` [PATCHv4 00/21] git notes merge Sverre Rabbelier
2010-10-23  0:47       ` Johan Herland
2010-10-23  1:44         ` Sverre Rabbelier
2010-10-22 22:28   ` Johan Herland
2010-10-23  1:38     ` Sverre Rabbelier

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=201010221741.25390.johan@herland.net \
    --to=johan@herland.net \
    --cc=avarab@gmail.com \
    --cc=bebarino@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jrnieder@gmail.com \
    --cc=srabbelier@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).