All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Philip Oakley" <philipoakley@iee.org>
To: "Junio C Hamano" <gitster@pobox.com>
Cc: "Jonathan Nieder" <jrnieder@gmail.com>, "GitList" <git@vger.kernel.org>
Subject: Re: [RFC/PATCH 2/2] doc: command line interface (cli) dot-repository dwimmery
Date: Tue, 21 May 2013 08:47:45 +0100	[thread overview]
Message-ID: <08847FEAFB00489695F31AA651F5EA2E@PhilipOakley> (raw)
In-Reply-To: 7v1u91uw95.fsf@alter.siamese.dyndns.org

From: "Junio C Hamano" <gitster@pobox.com>
Sent: Monday, May 20, 2013 11:22 PM
> "Philip Oakley" <philipoakley@iee.org> writes:
>
>> So we can have a branch whose remote is '.'
>> _and_ a remote whose URL is '.'
>
> Yes, and they are two separate concepts.
Thank you of the confirmation.

>
> "git fetch" while on "mywork" branch with this:
>
>    [branch "mywork"]
>        remote = git://git.k.org/pub/scm/git/git.git
>        merge = refs/heads/master
>
> without having any named remote whose remote.$name.url is set to
> that URL may happen to work but it is by accident as far as I know.
Interesting. Any thoughts on which way it should be 
documented/deprecated?

> As you do not copy to any remote tracking branches, @{u} would not
> work, so it is not something useful.  But on the other hand
>
>    [branch "mywork"]
>        remote = .
>        merge = refs/heads/master
>
> works _as if_ you have
Thank you of the confirmation.

>
>    [remote "."]
>        url = "."
> ;; no fetch refspec like +refs/heads/*:refs/heads/*
>        ;; no push refspec like +refs/heads/*:refs/heads/*
>
> so in that sense, you _could_ think of branch.$name.remote as a
> (generic) URL or a name of a (special) remote, but it is easier to
> think about it as the latter.
Yes.

>
> And remote.$name.url = "." for any name, e.g.
>
>    [remote "here"]
>        url = "."
>
> is a special case of local repository that is named with a relative
> filesystem path.
>
>> Can there be a clash with a named remote that is actually '.', where
>> the push/fetch is actually a no-op?
>
> Nobody sane would do it in the first place, so...

Oh I don't know. I don't think 'sanity' comes into it any more than 
'common sense' is common. It's easy to fall into the inverse 
Kruger-Dunning mode where those in the know don't realise how much they 
know, and how 'stupid' those that don't can be (that'd be me;-).

All this 'what's a dot-repo and where can I use it' came about because 
of an answer that give it's use as a 'trick'.

On Sat, May 4, 2013 at 2:51 PM, Jonathan Nieder <jrnieder@gmail.com>
wrote:
> Another trick is to use "git push":
>         git push . $production_sha1:refs/heads/master

and

Filipe gave 'git fetch .' in [PATCH 1/3] fetch: add --allow-local 
option, 16 May 2013

Philip 

  reply	other threads:[~2013-05-21  7:47 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-19 11:54 [RFC/PATCH 0/2] Extend dot repository documentation Philip Oakley
2013-05-19 11:54 ` [RFC/PATCH 1/2] config doc: add dot-repository note Philip Oakley
2013-05-19 17:43   ` Jonathan Nieder
2013-05-20 17:50     ` Junio C Hamano
2013-05-20 21:10       ` Philip Oakley
2013-05-19 11:54 ` [RFC/PATCH 2/2] doc: command line interface (cli) dot-repository dwimmery Philip Oakley
2013-05-19 17:39   ` Jonathan Nieder
2013-05-19 22:29     ` Philip Oakley
2013-05-20 17:55     ` Junio C Hamano
2013-05-20 21:09       ` Philip Oakley
2013-05-20 22:22         ` Junio C Hamano
2013-05-21  7:47           ` Philip Oakley [this message]
2013-05-21 16:23             ` Junio C Hamano
2013-05-21 21:21               ` Felipe Contreras
2013-05-21 22:33                 ` Philip Oakley
2013-05-21 23:03                   ` Felipe Contreras
2013-05-21 23:24                     ` Junio C Hamano
2013-05-22  0:27                       ` Felipe Contreras
2013-05-22  0:50                         ` Junio C Hamano
2013-05-22  2:57                           ` Felipe Contreras
2013-05-22 16:50                             ` Junio C Hamano
2013-05-22 22:12                               ` Felipe Contreras
2013-05-22 22:09                     ` Philip Oakley
2013-05-22 22:15                       ` Felipe Contreras
2013-09-13 21:23 ` [PATCH V2 0/3] Extend dot repository documentation Philip Oakley
2013-09-13 21:23   ` [PATCH V2 1/3] Doc URLs: relative paths imply the dot-respository Philip Oakley
2013-09-13 22:21     ` Junio C Hamano
2013-09-14 20:47       ` Philip Oakley
2013-09-13 21:23   ` [PATCH V2 2/3] config doc: update dot-repository notes Philip Oakley
2013-09-13 22:28     ` Junio C Hamano
2013-09-14 20:47       ` Philip Oakley
2013-09-13 21:23   ` [PATCH V2 3/3] doc: command line interface (cli) dot-repository dwimmery Philip Oakley
2013-09-13 22:31     ` 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=08847FEAFB00489695F31AA651F5EA2E@PhilipOakley \
    --to=philipoakley@iee.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jrnieder@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 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.