Git development
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox