{"thread":{"id":"33870","subject":"[RFC/PATCH 1/2] config doc: add dot-repository note","startedAt":"2013-05-19T11:54:07Z","lastAt":"2013-09-14T20:47:40Z","messageCount":33,"participants":["Philip Oakley","Jonathan Nieder","Junio C Hamano","Felipe Contreras"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"217892","messageId":"1368964449-2724-1-git-send-email-philipoakley@iee.org","threadId":"33870","inReplyTo":null,"subject":"[RFC/PATCH 0/2] Extend dot repository documentation","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-05-19T11:54:07Z","receivedAt":"2013-05-19T11:54:07Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"The dot repository convention is not well know to users and its\ndocumenation is hidden as a note in an ancilliary config variable's\ndocumenation.\n\nDocument the dot repository 'do what I mean' convention in the\nconfig variable it is used in, and in the cli (command line interface)\ndocumenation page to give regular users a chance to find it.\n\nPhilip Oakley (2):\n config doc: add dot-repository note\n doc: command line interface (cli) dot-repository dwimmery\n\n Documentation/config.txt | 2 ++\n Documentation/gitcli.txt | 4 ++++\n 2 files changed, 6 insertions(+)\n\n-- \n1.8.1.msysgit.1\n"},{"id":"217890","messageId":"1368964449-2724-2-git-send-email-philipoakley@iee.org","threadId":"33870","inReplyTo":"1368964449-2724-1-git-send-email-philipoakley@iee.org","subject":"[RFC/PATCH 1/2] config doc: add dot-repository note","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-05-19T11:54:08Z","receivedAt":"2013-05-19T11:54:08Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"branch..remote can be set to '.' (period) as a dot repository\nas part of the remote name dwimmery. Tell the reader.\n\nSigned-off-by: Philip Oakley \n---\n Documentation/config.txt | 2 ++\n 1 file changed, 2 insertions(+)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 6e53fc5..fd42509 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -734,6 +734,8 @@ branch..remote::\n \toverridden by `branch..pushremote`. If no remote is\n \tconfigured, or if you are not on any branch, it defaults to\n \t`origin` for fetching and `remote.pushdefault` for pushing.\n+\tAdditionally, a `.` (period) means the current local repository\n+\t(a dot-repository), see `branch..merge`'s final note below.\n \n branch..pushremote::\n \tWhen on branch , it overrides `branch..remote` for\n-- \n1.8.1.msysgit.1\n"},{"id":"217891","messageId":"1368964449-2724-3-git-send-email-philipoakley@iee.org","threadId":"33870","inReplyTo":"1368964449-2724-1-git-send-email-philipoakley@iee.org","subject":"[RFC/PATCH 2/2] doc: command line interface (cli) dot-repository dwimmery","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-05-19T11:54:09Z","receivedAt":"2013-05-19T11:54:09Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"The Git cli will generally accept dot '.' (period) as equivalent\nto the current repository when appropriate. Tell the reader of this\n'do what I mean' (dwim)mery action.\n\nSigned-off-by: Philip Oakley \n---\n Documentation/gitcli.txt | 4 ++++\n 1 file changed, 4 insertions(+)\n\ndiff --git a/Documentation/gitcli.txt b/Documentation/gitcli.txt\nindex 9ac5088..64bb386 100644\n--- a/Documentation/gitcli.txt\n+++ b/Documentation/gitcli.txt\n@@ -59,6 +59,10 @@ working tree. After running `git add hello.c; rm hello.c`, you will _not_\n see `hello.c` in your working tree with the former, but with the latter\n you will.\n \n+Just as, by convention, the filesystem '.' refers to the current directory,\n+using a '.' (period) as a repository name in Git (a dot-repository) refers\n+to your local repository.\n+\n Here are the rules regarding the \"flags\" that you should follow when you are\n scripting Git:\n \n-- \n1.8.1.msysgit.1\n"},{"id":"217923","messageId":"20130519173924.GB3362@elie.Belkin","threadId":"33870","inReplyTo":"1368964449-2724-3-git-send-email-philipoakley@iee.org","subject":"Re: [RFC/PATCH 2/2] doc: command line interface (cli) dot-repository dwimmery","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-05-19T17:39:24Z","receivedAt":"2013-05-19T17:39:24Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nPhilip Oakley wrote:\n\n> The Git cli will generally accept dot '.' (period) as equivalent\n> to the current repository when appropriate. Tell the reader of this\n> 'do what I mean' (dwim)mery action.\n[...]\n> --- a/Documentation/gitcli.txt\n> +++ b/Documentation/gitcli.txt\n> @@ -59,6 +59,10 @@ working tree. After running `git add hello.c; rm hello.c`, you will _not_\n> see `hello.c` in your working tree with the former, but with the latter\n> you will.\n> \n> +Just as, by convention, the filesystem '.' refers to the current directory,\n> +using a '.' (period) as a repository name in Git (a dot-repository) refers\n> +to your local repository.\n\nGood idea, but I fear that no one would find it there.\n\nWould it make sense to put this in Documentation/urls.txt (aka the\n\"GIT URLS\" section of git-fetch(1) and git-clone(1)), where other URL\nschemes are documented?\n\nThanks,\nJonathan\n"},{"id":"217924","messageId":"20130519174307.GC3362@elie.Belkin","threadId":"33870","inReplyTo":"1368964449-2724-2-git-send-email-philipoakley@iee.org","subject":"Re: [RFC/PATCH 1/2] config doc: add dot-repository note","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-05-19T17:43:07Z","receivedAt":"2013-05-19T17:43:07Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Philip Oakley wrote:\n\n> --- a/Documentation/config.txt\n> +++ b/Documentation/config.txt\n> @@ -734,6 +734,8 @@ branch..remote::\n> \toverridden by `branch..pushremote`. If no remote is\n> \tconfigured, or if you are not on any branch, it defaults to\n> \t`origin` for fetching and `remote.pushdefault` for pushing.\n> +\tAdditionally, a `.` (period) means the current local repository\n> +\t(a dot-repository), see `branch..merge`'s final note below.\n\nDoes this accept an arbitrary git URL, or only remote names?\n\nThe current documentation makes it sound like the latter, which makes\nthis exception seem very weird. Is it actually the former?\n\nI think a cross-reference to the \"git urls\" or \"git remotes\"\ndocumentation would be a better way to go, instead of having to repeat\nthe rules of URL syntax everywhere they are used.\n\nThanks,\nJonathan\n"},{"id":"217949","messageId":"42E6711E441F4E7E92B65CC7CCFB897E@PhilipOakley","threadId":"33870","inReplyTo":"20130519173924.GB3362@elie.Belkin","subject":"Re: [RFC/PATCH 2/2] doc: command line interface (cli) dot-repository dwimmery","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-05-19T22:29:41Z","receivedAt":"2013-05-19T22:29:41Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Jonathan Nieder\" \nSent: Sunday, May 19, 2013 6:39 PM\n> Hi,\n>\n> Philip Oakley wrote:\n>\n>> The Git cli will generally accept dot '.' (period) as equivalent\n>> to the current repository when appropriate. Tell the reader of this\n>> 'do what I mean' (dwim)mery action.\n> [...]\n>> --- a/Documentation/gitcli.txt\n>> +++ b/Documentation/gitcli.txt\n>> @@ -59,6 +59,10 @@ working tree. After running `git add hello.c; rm \n>> hello.c`, you will _not_\n>> see `hello.c` in your working tree with the former, but with the \n>> latter\n>> you will.\n>>\n>> +Just as, by convention, the filesystem '.' refers to the current \n>> directory,\n>> +using a '.' (period) as a repository name in Git (a dot-repository) \n>> refers\n>> +to your local repository.\n>\n> Good idea, but I fear that no one would find it there.\n>\n> Would it make sense to put this in Documentation/urls.txt (aka the\n> \"GIT URLS\" section of git-fetch(1) and git-clone(1)), where other URL\n> schemes are documented?\n>\n> Thanks,\n> Jonathan\n\nSounds an interesting idea. I'll have a look.\nPhilip \n"},{"id":"217988","messageId":"7v7gitwneq.fsf@alter.siamese.dyndns.org","threadId":"33870","inReplyTo":"20130519174307.GC3362@elie.Belkin","subject":"Re: [RFC/PATCH 1/2] config doc: add dot-repository note","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-05-20T17:50:53Z","receivedAt":"2013-05-20T17:50:53Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder writes:\n\n> Philip Oakley wrote:\n>\n>> --- a/Documentation/config.txt\n>> +++ b/Documentation/config.txt\n>> @@ -734,6 +734,8 @@ branch..remote::\n>> \toverridden by `branch..pushremote`. If no remote is\n>> \tconfigured, or if you are not on any branch, it defaults to\n>> \t`origin` for fetching and `remote.pushdefault` for pushing.\n>> +\tAdditionally, a `.` (period) means the current local repository\n>> +\t(a dot-repository), see `branch..merge`'s final note below.\n>\n> Does this accept an arbitrary git URL, or only remote names?\n\nThe branch..remote variable refers to remote names, and '.'\noften appears as a special name to refer to the local repository.\n\nI think you can define it as URL and your \"git fetch\" (no args) will\ndo the right thing in that it would:\n\n (1) fetch the history leading to the tip branch..merge branch\n from there; and\n\n (2) leave the result in FETCH_HEAD, so that \"git merge FETCH_HEAD\"\n can conclude the \"git pull\" you split into two manually by\n running \"git fetch\" first,\n\nbut I do not think there is a \"while we create this branch\" side\neffect UI like \"--set-upstream-to\" for doing so, except for setting\nit to '.' when you set upstream to a branch in the local repository.\nI.e.\n\n\tgit checkout -t -b mywork master\n git branch --set-upstream-to master mywork\n\nAlso I think setting it to arbitrary URL would mean that you would\nnot see any remote tracking ref (they are to be defined as a\nproperty of named remote with remote..fetch refspecs), so it\nis unclear how @{u} would work. @{u} works when the variable is set\nto '.', though.\n\nFor the above reasons, describing '.' as a special value for the\nvariable that the end users are likely to see is a reasonable \"white\nlie\" for this part of the documentation.\n"},{"id":"217989","messageId":"7v38thwn6l.fsf@alter.siamese.dyndns.org","threadId":"33870","inReplyTo":"20130519173924.GB3362@elie.Belkin","subject":"Re: [RFC/PATCH 2/2] doc: command line interface (cli) dot-repository dwimmery","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-05-20T17:55:46Z","receivedAt":"2013-05-20T17:55:46Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder writes:\n\n>> --- a/Documentation/gitcli.txt\n>> +++ b/Documentation/gitcli.txt\n>> @@ -59,6 +59,10 @@ working tree. After running `git add hello.c; rm hello.c`, you will _not_\n>> see `hello.c` in your working tree with the former, but with the latter\n>> you will.\n>> \n>> +Just as, by convention, the filesystem '.' refers to the current directory,\n>> +using a '.' (period) as a repository name in Git (a dot-repository) refers\n>> +to your local repository.\n>\n> Good idea, but I fear that no one would find it there.\n\nAlso I think it would be better without \", by convention,\". If you\nsay '.' == current directory is \"a convention\", you have to start\nsaying that \"by convention\", \"hello.c\" refers to the file in the\ncurrent directory of that name, which may be technically correct but\nmake the phrase \"by convention\" meaningless. A dot \".\" is *the*\nname for the current directory, just like \"hello.c\" is the name for\nthat file.\n\n Just like '.' refers to the current directory in the filesystem, '.'\n refers to the current repository.\n\nwould be sufficient.\n\n> Would it make sense to put this in Documentation/urls.txt (aka the\n> \"GIT URLS\" section of git-fetch(1) and git-clone(1)), where other URL\n> schemes are documented?\n\nYes, the '.' described above is a special case of giving a\nrepository URL as a relative-path on the filesystem.\n"},{"id":"218002","messageId":"BDA138F1A58247F4A4940B3436A94485@PhilipOakley","threadId":"33870","inReplyTo":"7v38thwn6l.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC/PATCH 2/2] doc: command line interface (cli) dot-repository dwimmery","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-05-20T21:09:53Z","receivedAt":"2013-05-20T21:09:53Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Junio C Hamano\" \nSent: Monday, May 20, 2013 6:55 PM\n> Jonathan Nieder writes:\n>\n>>> --- a/Documentation/gitcli.txt\n>>> +++ b/Documentation/gitcli.txt\n>>> @@ -59,6 +59,10 @@ working tree. After running `git add hello.c; rm \n>>> hello.c`, you will _not_\n>>> see `hello.c` in your working tree with the former, but with the \n>>> latter\n>>> you will.\n>>>\n>>> +Just as, by convention, the filesystem '.' refers to the current \n>>> directory,\n>>> +using a '.' (period) as a repository name in Git (a dot-repository) \n>>> refers\n>>> +to your local repository.\n>>\n>> Good idea, but I fear that no one would find it there.\n>\n> Also I think it would be better without \", by convention,\". If you\n> say '.' == current directory is \"a convention\", you have to start\n> saying that \"by convention\", \"hello.c\" refers to the file in the\n> current directory of that name, which may be technically correct but\n> make the phrase \"by convention\" meaningless. A dot \".\" is *the*\n> name for the current directory, just like \"hello.c\" is the name for\n> that file.\n\nThe part I had previously needed clearing up was if the '.' was in some \nway expanded by the shell, or whether the file system commands \ninterpreted it by themselves for that specific purpose. So in this case \nGit sees the single character and has to decide what to do with it.\n\n>\n> Just like '.' refers to the current directory in the filesystem, \n> '.'\n> refers to the current repository.\n>\n> would be sufficient.\n>\n>> Would it make sense to put this in Documentation/urls.txt (aka the\n>> \"GIT URLS\" section of git-fetch(1) and git-clone(1)), where other URL\n>> schemes are documented?\n>\n> Yes, the '.' described above is a special case of giving a\n> repository URL as a relative-path on the filesystem.\n\nSo we can have a branch whose remote is '.'\n_and_ a remote whose URL is '.'\n\nHence we/one/I could declare a remote called 'home' whose URL is '.'\n(with my 'away' remote on Github - just thinking aloud of the upstream / \ndownstream / across-stream discussions!)\n\nCan there be a clash with a named remote that is actually '.', where the \npush/fetch is actually a no-op?\n\nPhilip \n"},{"id":"218003","messageId":"B010AA3E0D5C4FADBC22D43DA4C255D6@PhilipOakley","threadId":"33870","inReplyTo":"7v7gitwneq.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC/PATCH 1/2] config doc: add dot-repository note","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-05-20T21:10:37Z","receivedAt":"2013-05-20T21:10:37Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Junio C Hamano\" \nSent: Monday, May 20, 2013 6:50 PM\n> Jonathan Nieder writes:\n>\n>> Philip Oakley wrote:\n>>\n>>> --- a/Documentation/config.txt\n>>> +++ b/Documentation/config.txt\n>>> @@ -734,6 +734,8 @@ branch..remote::\n>>> overridden by `branch..pushremote`. If no remote is\n>>> configured, or if you are not on any branch, it defaults to\n>>> `origin` for fetching and `remote.pushdefault` for pushing.\n>>> + Additionally, a `.` (period) means the current local repository\n>>> + (a dot-repository), see `branch..merge`'s final note below.\n>>\n>> Does this accept an arbitrary git URL, or only remote names?\n>\n> The branch..remote variable refers to remote names, and '.'\n> often appears as a special name to refer to the local repository.\n\nInitially I thought that the '.' wasn't going to be acceptable as a URL, \nand that the '.' would only apply to the defined of the remote \nwithin the branch section.\n\n>\n> I think you can define it as URL and your \"git fetch\" (no args) will\n> do the right thing in that it would:\n>\n> (1) fetch the history leading to the tip branch..merge branch\n> from there; and\n>\n> (2) leave the result in FETCH_HEAD, so that \"git merge FETCH_HEAD\"\n> can conclude the \"git pull\" you split into two manually by\n> running \"git fetch\" first,\n>\n> but I do not think there is a \"while we create this branch\" side\n> effect UI like \"--set-upstream-to\" for doing so, except for setting\n> it to '.' when you set upstream to a branch in the local repository.\n> I.e.\n>\n> git checkout -t -b mywork master\n> git branch --set-upstream-to master mywork\n>\n> Also I think setting it to arbitrary URL would mean that you would\n> not see any remote tracking ref (they are to be defined as a\n> property of named remote with remote..fetch refspecs), so it\n> is unclear how @{u} would work. @{u} works when the variable is set\n> to '.', though.\n>\n> For the above reasons, describing '.' as a special value for the\n> variable that the end users are likely to see is a reasonable \"white\n> lie\" for this part of the documentation.\n>\n\nOK. \n"},{"id":"218007","messageId":"7v1u91uw95.fsf@alter.siamese.dyndns.org","threadId":"33870","inReplyTo":"BDA138F1A58247F4A4940B3436A94485@PhilipOakley","subject":"Re: [RFC/PATCH 2/2] doc: command line interface (cli) dot-repository dwimmery","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-05-20T22:22:46Z","receivedAt":"2013-05-20T22:22:46Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Philip Oakley\" writes:\n\n> So we can have a branch whose remote is '.'\n> _and_ a remote whose URL is '.'\n\nYes, and they are two separate concepts.\n\n\"git fetch\" while on \"mywork\" branch with this:\n\n [branch \"mywork\"]\n remote = git://git.k.org/pub/scm/git/git.git\n merge = refs/heads/master\n\nwithout having any named remote whose remote.$name.url is set to\nthat URL may happen to work but it is by accident as far as I know.\nAs you do not copy to any remote tracking branches, @{u} would not\nwork, so it is not something useful. But on the other hand\n\n [branch \"mywork\"]\n remote = .\n merge = refs/heads/master\n\nworks _as if_ you have\n\n [remote \".\"]\n url = \".\"\n\t;; no fetch refspec like +refs/heads/*:refs/heads/*\n ;; no push refspec like +refs/heads/*:refs/heads/*\n\nso in that sense, you _could_ think of branch.$name.remote as a\n(generic) URL or a name of a (special) remote, but it is easier to\nthink about it as the latter.\n\nAnd remote.$name.url = \".\" for any name, e.g.\n\n [remote \"here\"]\n url = \".\"\n\nis a special case of local repository that is named with a relative\nfilesystem path.\n\n> Can there be a clash with a named remote that is actually '.', where\n> the push/fetch is actually a no-op?\n\nNobody sane would do it in the first place, so...\n"},{"id":"218039","messageId":"08847FEAFB00489695F31AA651F5EA2E@PhilipOakley","threadId":"33870","inReplyTo":"7v1u91uw95.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC/PATCH 2/2] doc: command line interface (cli) dot-repository dwimmery","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-05-21T07:47:45Z","receivedAt":"2013-05-21T07:47:45Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Junio C Hamano\" \nSent: Monday, May 20, 2013 11:22 PM\n> \"Philip Oakley\" writes:\n>\n>> So we can have a branch whose remote is '.'\n>> _and_ a remote whose URL is '.'\n>\n> Yes, and they are two separate concepts.\nThank you of the confirmation.\n\n>\n> \"git fetch\" while on \"mywork\" branch with this:\n>\n> [branch \"mywork\"]\n> remote = git://git.k.org/pub/scm/git/git.git\n> merge = refs/heads/master\n>\n> without having any named remote whose remote.$name.url is set to\n> that URL may happen to work but it is by accident as far as I know.\nInteresting. Any thoughts on which way it should be \ndocumented/deprecated?\n\n> As you do not copy to any remote tracking branches, @{u} would not\n> work, so it is not something useful. But on the other hand\n>\n> [branch \"mywork\"]\n> remote = .\n> merge = refs/heads/master\n>\n> works _as if_ you have\nThank you of the confirmation.\n\n>\n> [remote \".\"]\n> url = \".\"\n> ;; no fetch refspec like +refs/heads/*:refs/heads/*\n> ;; no push refspec like +refs/heads/*:refs/heads/*\n>\n> so in that sense, you _could_ think of branch.$name.remote as a\n> (generic) URL or a name of a (special) remote, but it is easier to\n> think about it as the latter.\nYes.\n\n>\n> And remote.$name.url = \".\" for any name, e.g.\n>\n> [remote \"here\"]\n> url = \".\"\n>\n> is a special case of local repository that is named with a relative\n> filesystem path.\n>\n>> Can there be a clash with a named remote that is actually '.', where\n>> the push/fetch is actually a no-op?\n>\n> Nobody sane would do it in the first place, so...\n\nOh I don't know. I don't think 'sanity' comes into it any more than \n'common sense' is common. It's easy to fall into the inverse \nKruger-Dunning mode where those in the know don't realise how much they \nknow, and how 'stupid' those that don't can be (that'd be me;-).\n\nAll this 'what's a dot-repo and where can I use it' came about because \nof an answer that give it's use as a 'trick'.\n\nOn Sat, May 4, 2013 at 2:51 PM, Jonathan Nieder \nwrote:\n> Another trick is to use \"git push\":\n> git push . $production_sha1:refs/heads/master\n\nand\n\nFilipe gave 'git fetch .' in [PATCH 1/3] fetch: add --allow-local \noption, 16 May 2013\n\nPhilip \n"},{"id":"218053","messageId":"7vfvxgqp3m.fsf@alter.siamese.dyndns.org","threadId":"33870","inReplyTo":"08847FEAFB00489695F31AA651F5EA2E@PhilipOakley","subject":"Re: [RFC/PATCH 2/2] doc: command line interface (cli) dot-repository dwimmery","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-05-21T16:23:09Z","receivedAt":"2013-05-21T16:23:09Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Philip Oakley\" writes:\n\n> From: \"Junio C Hamano\" \n> Sent: Monday, May 20, 2013 11:22 PM\n>> \"Philip Oakley\" writes:\n>>\n>>> So we can have a branch whose remote is '.'\n>>> _and_ a remote whose URL is '.'\n>>\n>> Yes, and they are two separate concepts.\n> Thank you of the confirmation.\n>\n>>\n>> \"git fetch\" while on \"mywork\" branch with this:\n>>\n>> [branch \"mywork\"]\n>> remote = git://git.k.org/pub/scm/git/git.git\n>> merge = refs/heads/master\n>>\n>> without having any named remote whose remote.$name.url is set to\n>> that URL may happen to work but it is by accident as far as I know.\n> Interesting. Any thoughts on which way it should be\n> documented/deprecated?\n\nIf \"leave it as-is\" is not an option, I personally would prefer\nmentioning \"this happens to work, but do not rely on it\" in the\npassing. I do not see any immediate need to break things for people\ndiscovered that this happens to work and who decided that they have\nno need for a remote tracking branch for the particular remote this\nbranch happens to integrate with. By making that choice, they may\nbe forgoing the use of @{u}, but they won't be inconvenienced as\n\"git fetch\" will leave what they need @{u} for in FETCH_HEAD, i.e.\ninstead of doing\n\n\tgit fetch\n\tgit log [-p] ..@{u}\n git merge @{u} ;# or git rebase @{u}\n\nas a \"verify in the middle\" replacement for \"git pull [--rebase]\",\nthey can do\n\n\tgit fetch\n\tgit log [-p] ..FETCH_HEAD\n git merge FETCH_HEAD ;# or git rebase FETCH_HEAD\n\njust fine.\n\nThe \"do not rely on it\" is primarily because there are more familiar\nways invented later (namely, use a named remote instead of writing a\nreal URL, with remote tracking branches). I do not think we would\nwant to deliberately sabotage the people who currently use such a\nsetting, but I do not see a strong reason to recommend it to people\nwho are new to Git, either, *unless* they need to fetch from many\ndifferent places and do not want to have remote tracking branches\nbecause the only time they care about the state of their remotes is\nimmediately after they fetched.\n\n>>> Can there be a clash with a named remote that is actually '.', where\n>>> the push/fetch is actually a no-op?\n>>\n>> Nobody sane would do it in the first place, so...\n>\n> Oh I don't know. I don't think 'sanity' comes into it any more than\n> common sense' is common. It's easy to fall into the inverse\n> Kruger-Dunning mode where those in the know don't realise how much\n> they know, and how 'stupid' those that don't can be (that'd be me;-).\n\nHow would you even express such a remote named \".\" in the first\nplace? \"git remote add\" would not let you say:\n\n\t$ git remote add . git://some.where.xz/some/repo.git\n fatal: '.' is not a valid remote name\n\nand even if you add configuration variables by hand, it would not\nlook like this:\n\n\t[remote \".\"]\n \tfetch = +refs/heads/*:refs/remotes/./*\n\nYou would want some real token between \"refs/remotes/\" and the\ntrailing \"/*\" instead, so...\n\n> All this 'what's a dot-repo and where can I use it' came about because\n> of an answer that give it's use as a 'trick'.\n>\n> On Sat, May 4, 2013 at 2:51 PM, Jonathan Nieder \n> wrote:\n>> Another trick is to use \"git push\":\n>> git push . $production_sha1:refs/heads/master\n\nIt all falls out naturally from the \"Git is distributed and no\nrepository is special\" principle. I think that word \"trick\" merely\nrefers to \"those who do not realize that the local repository is not\nall that special and merely is _a_ repository just like anybody\nelse's may not realize they can do this\", nothing more.\n\n> Filipe gave 'git fetch .' in [PATCH 1/3] fetch: add --allow-local\n> option, 16 May 2013\n\nThat patch came from a mistaken suggestion from me that was\nretracted with\n\n http://article.gmane.org/gmane.comp.version-control.git/224729\n"},{"id":"218097","messageId":"CAMP44s3G5BPbw3MO8W3rmDabJ-ewf-C5FH8HHO_o0cPf0f55BA@mail.gmail.com","threadId":"33870","inReplyTo":"7vfvxgqp3m.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC/PATCH 2/2] doc: command line interface (cli) dot-repository dwimmery","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-05-21T21:21:53Z","receivedAt":"2013-05-21T21:21:53Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, May 21, 2013 at 11:23 AM, Junio C Hamano wrote:\n> \"Philip Oakley\" writes:\n\n>> On Sat, May 4, 2013 at 2:51 PM, Jonathan Nieder \n>> wrote:\n>>> Another trick is to use \"git push\":\n>>> git push . $production_sha1:refs/heads/master\n>\n> It all falls out naturally from the \"Git is distributed and no\n> repository is special\" principle. I think that word \"trick\" merely\n> refers to \"those who do not realize that the local repository is not\n> all that special and merely is _a_ repository just like anybody\n> else's may not realize they can do this\", nothing more.\n\nNobody cares.\n\n>> Filipe gave 'git fetch .' in [PATCH 1/3] fetch: add --allow-local\n>> option, 16 May 2013\n>\n> That patch came from a mistaken suggestion from me that was\n> retracted with\n\nYou say it's \"mistaken\", but you are not the arbiter of truth; the\nfact that you say it's so doesn't make it so. It's just rhetoric.\n\nYou haven't shown that it's indeed mistaken.\n\n-- \nFelipe Contreras\n"},{"id":"218104","messageId":"7C4B7B2B8AD949F0833D1919EEACD224@PhilipOakley","threadId":"33870","inReplyTo":"CAMP44s3G5BPbw3MO8W3rmDabJ-ewf-C5FH8HHO_o0cPf0f55BA@mail.gmail.com","subject":"Re: [RFC/PATCH 2/2] doc: command line interface (cli) dot-repository dwimmery","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-05-21T22:33:54Z","receivedAt":"2013-05-21T22:33:54Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Felipe Contreras\" \nSent: Tuesday, May 21, 2013 10:21 PM\n> On Tue, May 21, 2013 at 11:23 AM, Junio C Hamano \n> wrote:\n>> \"Philip Oakley\" writes:\n>\n>>> On Sat, May 4, 2013 at 2:51 PM, Jonathan Nieder \n>>> wrote:\n>>>> Another trick is to use \"git push\":\n>>>> git push . $production_sha1:refs/heads/master\n>>\n>> It all falls out naturally from the \"Git is distributed and no\n>> repository is special\" principle. I think that word \"trick\" merely\n>> refers to \"those who do not realize that the local repository is not\n>> all that special and merely is _a_ repository just like anybody\n>> else's may not realize they can do this\", nothing more.\n>\n> Nobody cares.\n\nThe value of the trick was acknowledged as now being in use\nhttp://article.gmane.org/gmane.comp.version-control.git/223572\nNot sure if that was the caring you were commenting on.\n\nMy patch was to make it better known and that it (the dot repository) \nisn't a 'trick'.\n\nI'll refresh them after v1.8.3.\n\n>\n>>> Filipe gave 'git fetch .' in [PATCH 1/3] fetch: add --allow-local\n>>> option, 16 May 2013\n>>\n>> That patch came from a mistaken suggestion from me that was\n>> retracted with\n>\n> You say it's \"mistaken\", but you are not the arbiter of truth; the\n> fact that you say it's so doesn't make it so. It's just rhetoric.\n>\n> You haven't shown that it's indeed mistaken.\n\nAn aside: in some domains (e.g. Human Error taxonomy) a 'mistake' is a \nplanned action which later turns out to not be the action that would now \nhave, in retrospect, been chosen. The intent was good, but is later \nclassed (within the taxonomy) as a 'mistake'. (It is not related to \n'blame').\n\nIf I understand the extended thread correctly, the approach moved on and \nalternatives were found, so in that sense the intent was good.\n\n>\n> -- \n> Felipe Contreras\n"},{"id":"218108","messageId":"CAMP44s3rpS==ANz_OEVyVeUWXFNBu7RZaxJ5k-b7N5k9WFFhVw@mail.gmail.com","threadId":"33870","inReplyTo":"7C4B7B2B8AD949F0833D1919EEACD224@PhilipOakley","subject":"Re: [RFC/PATCH 2/2] doc: command line interface (cli) dot-repository dwimmery","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-05-21T23:03:10Z","receivedAt":"2013-05-21T23:03:10Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, May 21, 2013 at 5:33 PM, Philip Oakley wrote:\n> From: \"Felipe Contreras\" \n> Sent: Tuesday, May 21, 2013 10:21 PM\n>\n>> On Tue, May 21, 2013 at 11:23 AM, Junio C Hamano \n>> wrote:\n>>>\n>>> \"Philip Oakley\" writes:\n>>\n>>\n>>>> On Sat, May 4, 2013 at 2:51 PM, Jonathan Nieder \n>>>> wrote:\n>>>>>\n>>>>> Another trick is to use \"git push\":\n>>>>> git push . $production_sha1:refs/heads/master\n>>>\n>>>\n>>> It all falls out naturally from the \"Git is distributed and no\n>>> repository is special\" principle. I think that word \"trick\" merely\n>>> refers to \"those who do not realize that the local repository is not\n>>> all that special and merely is _a_ repository just like anybody\n>>> else's may not realize they can do this\", nothing more.\n>>\n>> Nobody cares.\n>\n> The value of the trick was acknowledged as now being in use\n> http://article.gmane.org/gmane.comp.version-control.git/223572\n\nHow is that more useful than 'git branch -f master $sha1'?\n\n> Not sure if that was the caring you were commenting on.\n\nMy point is that nobody uses '.' as a remote. Yes, you can find the\noccasional esoteric person in the Git mailing list that might find\nsome weird command useful, but that's the fringe user-base.\n\n>> You say it's \"mistaken\", but you are not the arbiter of truth; the\n>> fact that you say it's so doesn't make it so. It's just rhetoric.\n>>\n>> You haven't shown that it's indeed mistaken.\n>\n>\n> An aside: in some domains (e.g. Human Error taxonomy) a 'mistake' is a\n> planned action which later turns out to not be the action that would now\n> have, in retrospect, been chosen. The intent was good, but is later classed\n> (within the taxonomy) as a 'mistake'. (It is not related to 'blame').\n\nYeah, that's what a mistake is, in my mind.\n\n> If I understand the extended thread correctly, the approach moved on and\n> alternatives were found, so in that sense the intent was good.\n\nNo, the approach didn't move on, there are no better alternatives, the\n\"intent\" is irrelevant, the approach is good, there is no mistake.\n\nJunio simply ignored the fact that he was proven wrong.\n\nI still haven't received a response: which makes more sense?\n\na)\n\n\t% git checkout svn-ext\n\t% git fetch\n\tFrom .\n\t * branch master -> FETCH_HEAD\n\t# oops\n\t% git fetch git-svn\n\t% git log ..FETCH_HEAD\n\t% git merge FETCH_HEAD\n\nb)\n\n\t% git checkout svn-ext\n\t% git fetch\n\tFrom git://git.kernel.org/pub/scm/git/git\n\t 680ed3e..de3a5c6 master -> origin/master\n\t# oops\n\t% git fetch svn-ext\n\t% git log ..FETCH_HEAD\n\t% git merge FETCH_HEAD\n\n-- \nFelipe Contreras\n"},{"id":"218110","messageId":"7vr4gzlxvx.fsf@alter.siamese.dyndns.org","threadId":"33870","inReplyTo":"CAMP44s3rpS==ANz_OEVyVeUWXFNBu7RZaxJ5k-b7N5k9WFFhVw@mail.gmail.com","subject":"Re: [RFC/PATCH 2/2] doc: command line interface (cli) dot-repository dwimmery","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-05-21T23:24:34Z","receivedAt":"2013-05-21T23:24:34Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> I still haven't received a response: which makes more sense?\n>\n> a)\n>\n> \t% git checkout svn-ext\n> \t% git fetch\n> \tFrom .\n> \t * branch master -> FETCH_HEAD\n> \t# oops\n> \t% git fetch git-svn\n> \t% git log ..FETCH_HEAD\n> \t% git merge FETCH_HEAD\n>\n> b)\n>\n> \t% git checkout svn-ext\n> \t% git fetch\n> \tFrom git://git.kernel.org/pub/scm/git/git\n> \t 680ed3e..de3a5c6 master -> origin/master\n> \t# oops\n> \t% git fetch svn-ext\n> \t% git log ..FETCH_HEAD\n> \t% git merge FETCH_HEAD\n\nI think with the scenario you are following, a) would prepare the\nFETCH_HEAD with her local git-svn branch which is her svn-ext topic\nis based on, but you illustrated it to fetch 'master', which I think\nis a minor typo.\n\nModulo that typo, the step before the #oops makes perfect sense. It\nfetched where she told Git her work on svn-ext is based on.\n\nBut the step after that does not make much sense in that flow.\n\n\"git fetch git-svn\" to get from Eric might make sense but running\nlog with FETCH_HEAD while she is on her svn-ext does not make any\nsense, let alone merging with it. Her svn-ext is based on her local\ngit-svn branch for a reason---her branches are cascaded this way:\n\n Eric --> her local git-svn --> her local svn-ext\n\nHecking out her git-svn to update/rebase it on top of Eric's latest\nand then update her svn-ext that is based on her git-svn may make\nsense. But fetching from Eric and merging it into her svn-ext\ndirectly does not.\n\nAnd what happens before #oops in b) is an utter nonsense. Her\nsvn-ext is not even related to my tree. I think the step after that\nis a typo of \"git fetch git-svn\" to fetch from Eric, but again,\nbecause svn-ext is fork from her local git-svn (which is ahead of\nEric's tree with her own changes, but the changes are not related\nto her svn-ext work), these \"fetch from Eric, integrate svn-ext directly\nwith it\" makes no sense. \n\nSo, the short answer is neither, but a) can be fixed (not in code\nbut in the typescript) to make more sense, perhaps like this:\n\n % git checkout svn-ext\n % git fetch\n % git log ..FETCH_HEAD\n % git rebase FETCH_HEAD\n # The last three can be \"git pull --rebase\".\n\n # ok, did Eric do something in the meantime?\n % git checkout git-svn\n % git fetch\n From git://git.bogomips.org/git-svn.git/\n * branch master -> git-svn/master\n % git rebase FETCH_HEAD\n\n # now let's rebuild the svn-ext on top\n % git checkout svn-ext\n % git pull --rebase\n\nThe last step can be \"git rebase git-svn\", and the step to update\ngit-svn from Eric after checking it out can be \"git pull --rebase\",\nbut the whole point of having @{u}, even for branches that fork from\na local branch, is so that the user does not have to remember what\nforks from what, so I did not force her to say \"git rebase git-svn\"\nin that step.\n"},{"id":"218116","messageId":"CAMP44s2hH63rM++bG-aGeEyaL3tvF8yZYmcO7K1J66KVxyOutQ@mail.gmail.com","threadId":"33870","inReplyTo":"7vr4gzlxvx.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC/PATCH 2/2] doc: command line interface (cli) dot-repository dwimmery","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-05-22T00:27:12Z","receivedAt":"2013-05-22T00:27:12Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, May 21, 2013 at 6:24 PM, Junio C Hamano wrote:\n> Felipe Contreras writes:\n>\n>> I still haven't received a response: which makes more sense?\n>>\n>> a)\n>>\n>> % git checkout svn-ext\n>> % git fetch\n>> From .\n>> * branch master -> FETCH_HEAD\n>> # oops\n>> % git fetch git-svn\n>> % git log ..FETCH_HEAD\n>> % git merge FETCH_HEAD\n>>\n>> b)\n>>\n>> % git checkout svn-ext\n>> % git fetch\n>> From git://git.kernel.org/pub/scm/git/git\n>> 680ed3e..de3a5c6 master -> origin/master\n>> # oops\n>> % git fetch svn-ext\n>> % git log ..FETCH_HEAD\n>> % git merge FETCH_HEAD\n>\n> I think with the scenario you are following, a) would prepare the\n> FETCH_HEAD with her local git-svn branch which is her svn-ext topic\n> is based on, but you illustrated it to fetch 'master', which I think\n> is a minor typo.\n>\n> Modulo that typo, the step before the #oops makes perfect sense. It\n> fetched where she told Git her work on svn-ext is based on.\n>\n> But the step after that does not make much sense in that flow.\n\nYou don't get to decide what Sally (I'm naming her) does, all you get\nto decide is what Git does.\n\nSally wants to fetch from the true upstream: svn-ext, but in the\nprocess does by mistake a 'git fetch' *without arguments* (WHICH IS\nWHAT THIS WHOLE DISCUSSION IS ABOUT). So now is the time you answer:\na) or b).\n\nYou whole argument resides on this question, because you assumed the\nanswer is a), but that's an *assumption*, answer the question and\nyou'll see why. But your solution to a question that would undermine\nyour argument is to just ditch it. Great.\n\n> So, the short answer is neither, but a) can be fixed (not in code\n> but in the typescript) to make more sense, perhaps like this:\n\nDo not avoid the question.\n\n> % git checkout svn-ext\n> % git fetch\n> % git log ..FETCH_HEAD\n> % git rebase FETCH_HEAD\n> # The last three can be \"git pull --rebase\".\n\nIf she does 'git pull --rebase', then the whole thing is irrelevant\nfor the disunion about GIT FETCH WITHOUT ARGUMENTS.\n\nShe didn't want to fetch '.', nobody does; she wanted to fetch a real\nremote repository.\n\n> # ok, did Eric do something in the meantime?\n> % git checkout git-svn\n> % git fetch\n> From git://git.bogomips.org/git-svn.git/\n> * branch master -> git-svn/master\n> % git rebase FETCH_HEAD\n\nThis 'git fetch' is irrelevant, because it's not fetching from '.'.\n\n> # now let's rebuild the svn-ext on top\n> % git checkout svn-ext\n> % git pull --rebase\n\nNo fetch without arguments here either.\n\nAll these commands are red herrings.\n\nIs it a) or b) or are you just going to never allow your argument to\nbe challenged? That's a great way to \"win\" arguments, but a bad one to\narrive to good solutions.\n\n-- \nFelipe Contreras\n"},{"id":"218120","messageId":"7vehczltwu.fsf@alter.siamese.dyndns.org","threadId":"33870","inReplyTo":"CAMP44s2hH63rM++bG-aGeEyaL3tvF8yZYmcO7K1J66KVxyOutQ@mail.gmail.com","subject":"Re: [RFC/PATCH 2/2] doc: command line interface (cli) dot-repository dwimmery","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-05-22T00:50:25Z","receivedAt":"2013-05-22T00:50:25Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> On Tue, May 21, 2013 at 6:24 PM, Junio C Hamano wrote:\n>> Felipe Contreras writes:\n>>\n>>> I still haven't received a response: which makes more sense?\n>>>\n>>> a)\n>>>\n>>> % git checkout svn-ext\n>>> % git fetch\n>>> From .\n>>> * branch master -> FETCH_HEAD\n>>> # oops\n>>> % git fetch git-svn\n>>> % git log ..FETCH_HEAD\n>>> % git merge FETCH_HEAD\n>>>\n>>> b)\n>>>\n>>> % git checkout svn-ext\n>>> % git fetch\n>>> From git://git.kernel.org/pub/scm/git/git\n>>> 680ed3e..de3a5c6 master -> origin/master\n>>> # oops\n>>> % git fetch svn-ext\n>>> % git log ..FETCH_HEAD\n>>> % git merge FETCH_HEAD\n>>\n>> I think with the scenario you are following, a) would prepare the\n>> FETCH_HEAD with her local git-svn branch which is her svn-ext topic\n>> is based on, but you illustrated it to fetch 'master', which I think\n>> is a minor typo.\n>>\n>> Modulo that typo, the step before the #oops makes perfect sense. It\n>> fetched where she told Git her work on svn-ext is based on.\n>>\n>> But the step after that does not make much sense in that flow.\n>\n> You don't get to decide what Sally (I'm naming her) does, all you get\n> to decide is what Git does.\n>\n> Sally wants to fetch from the true upstream: svn-ext, but in the\n> process does by mistake a 'git fetch' *without arguments* (WHICH IS\n> WHAT THIS WHOLE DISCUSSION IS ABOUT). So now is the time you answer:\n> a) or b).\n\nHeh, that was my example.\n\nIn any case, my pick is still a). She *TOLD* Git that her local\ngit-svn branch is what forms the base of her local svn-ext work.\n\nI won't even read the remainder. You are not even worth wasting\ntime on discussing this.\n"},{"id":"218139","messageId":"CAMP44s3cvCuOJfm4HhqOiwm=63wGiTMx7LO8Y5F+SAu=E0tN9Q@mail.gmail.com","threadId":"33870","inReplyTo":"7vehczltwu.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC/PATCH 2/2] doc: command line interface (cli) dot-repository dwimmery","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-05-22T02:57:18Z","receivedAt":"2013-05-22T02:57:18Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, May 21, 2013 at 7:50 PM, Junio C Hamano wrote:\n> Felipe Contreras writes:\n>\n>> On Tue, May 21, 2013 at 6:24 PM, Junio C Hamano wrote:\n>>> Felipe Contreras writes:\n>>>\n>>>> I still haven't received a response: which makes more sense?\n>>>>\n>>>> a)\n>>>>\n>>>> % git checkout svn-ext\n>>>> % git fetch\n>>>> From .\n>>>> * branch master -> FETCH_HEAD\n>>>> # oops\n>>>> % git fetch git-svn\n>>>> % git log ..FETCH_HEAD\n>>>> % git merge FETCH_HEAD\n>>>>\n>>>> b)\n>>>>\n>>>> % git checkout svn-ext\n>>>> % git fetch\n>>>> From git://git.kernel.org/pub/scm/git/git\n>>>> 680ed3e..de3a5c6 master -> origin/master\n>>>> # oops\n>>>> % git fetch svn-ext\n>>>> % git log ..FETCH_HEAD\n>>>> % git merge FETCH_HEAD\n>>>\n>>> I think with the scenario you are following, a) would prepare the\n>>> FETCH_HEAD with her local git-svn branch which is her svn-ext topic\n>>> is based on, but you illustrated it to fetch 'master', which I think\n>>> is a minor typo.\n>>>\n>>> Modulo that typo, the step before the #oops makes perfect sense. It\n>>> fetched where she told Git her work on svn-ext is based on.\n>>>\n>>> But the step after that does not make much sense in that flow.\n>>\n>> You don't get to decide what Sally (I'm naming her) does, all you get\n>> to decide is what Git does.\n>>\n>> Sally wants to fetch from the true upstream: svn-ext, but in the\n>> process does by mistake a 'git fetch' *without arguments* (WHICH IS\n>> WHAT THIS WHOLE DISCUSSION IS ABOUT). So now is the time you answer:\n>> a) or b).\n>\n> Heh, that was my example.\n>\n> In any case, my pick is still a). She *TOLD* Git that her local\n> git-svn branch is what forms the base of her local svn-ext work.\n\nShe told Git that her local svn-branch was the basis for svn-next. She\nDIT NOT TELL Git to fetch from there. She told Git to fetch from any\nlocation Git thought best to fetch from, either a) or b) would fetch\nfrom the wrong location, but a) would be wronger, you just don't want\nto admit it.\n\nYou are, once again, *assuming* that if a user sets up an upstream, he\nwants to fetch from there. All you answers are based on assumptions.\n\n-- \nFelipe Contreras\n"},{"id":"218192","messageId":"7vtxlvj6vq.fsf@alter.siamese.dyndns.org","threadId":"33870","inReplyTo":"CAMP44s3cvCuOJfm4HhqOiwm=63wGiTMx7LO8Y5F+SAu=E0tN9Q@mail.gmail.com","subject":"Re: [RFC/PATCH 2/2] doc: command line interface (cli) dot-repository dwimmery","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-05-22T16:50:49Z","receivedAt":"2013-05-22T16:50:49Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> She told Git that her local svn-branch was the basis for svn-next. She\n> DIT NOT TELL Git to fetch from there. She told Git to fetch from any\n> location Git thought best to fetch from, either a) or b) would fetch\n> from the wrong location, but a) would be wronger, you just don't want\n> to admit it.\n\n\"(a) is more wrong\" is just your opinion, and you are simply wrong.\n\nShe is working on svn-ext based on her local git-svn the latter of\nwhich has some changes of her own on top of Eric's tree.\n\nWhen working on _any_ branch that bases its work on something else,\nyou have @{u} available, but that @{u} will not stay up-to-date if\nyou forked from work that is done outside your repository. That is\nwhat an unqualified \"git fetch\" is designed to help when run on a\nbranch that bases its work on something else. If you happen to know\nthat yoru current branch is forked from git-svn that is a local\nbranch, then running \"git fetch\" becomes unnecessary for the purpose\nof updating @{u} (it already and always is up to date), so doing no\nobject transfer and no ref update is absolutely the right thing to\ndo. That is what \"remote = .\" gives you.\n\nIn addition, that does not break the \"pull = fetch + merge\"\nequivalence you seem to be ignoring.\n\nIf she wants to check what Eric has been doing, she can do \"git\nfetch git-svn\", giving the remote name she calls Eric's tree with.\nAt that point, she is not saying \"I want to check what is happening\nto the upstream of my _current_ branch\" (and the fetched result is\nnot something she can immediately use while on her current branch).\n\nOn the other hand, an unqualified \"git fetch\" that slurps from my\ntree, which is your (b), is just plain wrong. My tree is not even\nrelated to what she is working on.\n\nOf course, when she is interested in what have been happening in my\ntree, she can say \"git fetch origin\".\n"},{"id":"218212","messageId":"6B51848E2F9A40078A2E42CE4BB499DA@PhilipOakley","threadId":"33870","inReplyTo":"CAMP44s3rpS==ANz_OEVyVeUWXFNBu7RZaxJ5k-b7N5k9WFFhVw@mail.gmail.com","subject":"Re: [RFC/PATCH 2/2] doc: command line interface (cli) dot-repository dwimmery","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-05-22T22:09:00Z","receivedAt":"2013-05-22T22:09:00Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Felipe Contreras\" \nSent: Wednesday, May 22, 2013 12:03 AM\n> On Tue, May 21, 2013 at 5:33 PM, Philip Oakley \n> wrote:\n>> From: \"Felipe Contreras\" \n>> Sent: Tuesday, May 21, 2013 10:21 PM\n>>\n>>> On Tue, May 21, 2013 at 11:23 AM, Junio C Hamano \n>>> wrote:\n>>>>\n>>>> \"Philip Oakley\" writes:\n>>>\n>>>\n>>>>> On Sat, May 4, 2013 at 2:51 PM, Jonathan Nieder \n>>>>> \n>>>>> wrote:\n>>>>>>\n>>>>>> Another trick is to use \"git push\":\n>>>>>> git push . $production_sha1:refs/heads/master\n>>>>\n>>>>\n>>>> It all falls out naturally from the \"Git is distributed and no\n>>>> repository is special\" principle. I think that word \"trick\" merely\n>>>> refers to \"those who do not realize that the local repository is \n>>>> not\n>>>> all that special and merely is _a_ repository just like anybody\n>>>> else's may not realize they can do this\", nothing more.\n>>>\n>>> Nobody cares.\n>>\n>> The value of the trick was acknowledged as now being in use\n>> http://article.gmane.org/gmane.comp.version-control.git/223572\n>\n> How is that more useful than 'git branch -f master $sha1'?\n\nThe 'trick' checks for a fast forward, while the branch update is \nforced. It depends on what checks are desired.\n\nMy original patch was to simply document Git's dot repository capability \nthat does not appear to be that well known. Let's not keep it as an \nEaster Egg.\n\n>\n>> Not sure if that was the caring you were commenting on.\n>\n> My point is that nobody uses '.' as a remote. Yes, you can find the\n> occasional esoteric person in the Git mailing list that might find\n> some weird command useful, but that's the fringe user-base.\n>\n>>> You say it's \"mistaken\", but you are not the arbiter of truth; the\n>>> fact that you say it's so doesn't make it so. It's just rhetoric.\n>>>\n>>> You haven't shown that it's indeed mistaken.\n>>\n>>\n>> An aside: in some domains (e.g. Human Error taxonomy) a 'mistake' is \n>> a\n>> planned action which later turns out to not be the action that would \n>> now\n>> have, in retrospect, been chosen. The intent was good, but is later \n>> classed\n>> (within the taxonomy) as a 'mistake'. (It is not related to 'blame').\n>\n> Yeah, that's what a mistake is, in my mind.\n>\n>> If I understand the extended thread correctly, the approach moved on \n>> and\n>> alternatives were found, so in that sense the intent was good.\n>\n> No, the approach didn't move on, there are no better alternatives, the\n> \"intent\" is irrelevant, the approach is good, there is no mistake.\n>\n> Junio simply ignored the fact that he was proven wrong.\n>\n> I still haven't received a response: which makes more sense?\n>\n> a)\n>\n> % git checkout svn-ext\n> % git fetch\n> From .\n> * branch master -> FETCH_HEAD\n> # oops\n> % git fetch git-svn\n> % git log ..FETCH_HEAD\n> % git merge FETCH_HEAD\n>\n> b)\n>\n> % git checkout svn-ext\n> % git fetch\n> From git://git.kernel.org/pub/scm/git/git\n> 680ed3e..de3a5c6 master -> origin/master\n> # oops\n> % git fetch svn-ext\n> % git log ..FETCH_HEAD\n> % git merge FETCH_HEAD\n>\n> -- \n> Felipe Contreras\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n>\n>\n> -----\n> No virus found in this message.\n> Checked by AVG - www.avg.com\n> Version: 2013.0.3343 / Virus Database: 3162/6344 - Release Date: \n> 05/21/13\n> \n"},{"id":"218213","messageId":"CAMP44s3jJRt8Jd6_oMwGBEj31ddQvHJukfYr8ySrk_zBaTjCPA@mail.gmail.com","threadId":"33870","inReplyTo":"7vtxlvj6vq.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC/PATCH 2/2] doc: command line interface (cli) dot-repository dwimmery","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-05-22T22:12:12Z","receivedAt":"2013-05-22T22:12:12Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Wed, May 22, 2013 at 11:50 AM, Junio C Hamano wrote:\n> Felipe Contreras writes:\n>\n>> She told Git that her local svn-branch was the basis for svn-next. She\n>> DIT NOT TELL Git to fetch from there. She told Git to fetch from any\n>> location Git thought best to fetch from, either a) or b) would fetch\n>> from the wrong location, but a) would be wronger, you just don't want\n>> to admit it.\n>\n> \"(a) is more wrong\" is just your opinion, and you are simply wrong.\n\nMy opinion based on very solid grounds; the whole purpose of 'git\nfetch; is to FETCH from a REMOTE. a) is not doing that at all.\n\nIn addition, the vast majority of users don't have a clue as to what the hell\n\n>From .\n * branch master -> FETCH_HEAD\n\nmeans.\n\na) is wronger. Period.\n\nYou say it's not, but give no explanation at all. This is no way to argue.\n\n> She is working on svn-ext based on her local git-svn the latter of\n> which has some changes of her own on top of Eric's tree.\n>\n> When working on _any_ branch that bases its work on something else,\n> you have @{u} available, but that @{u} will not stay up-to-date if\n> you forked from work that is done outside your repository. That is\n> what an unqualified \"git fetch\" is designed to help when run on a\n> branch that bases its work on something else.\n\nThe fact that it's designed that way doesn't mean it's a good design,\nand it doesn't mean the user expects that.\n\n> If you happen to know\n> that yoru current branch is forked from git-svn that is a local\n> branch,\n\nThat's a very big *IF*.\n\n> then running \"git fetch\" becomes unnecessary for the purpose\n> of updating @{u} (it already and always is up to date), so doing no\n> object transfer and no ref update is absolutely the right thing to\n> do. That is what \"remote = .\" gives you.\n\nJumping to conclusions based on assumptions again.\n\nSally doesn't know what the designers intended, Sally doesn't remember\nwhat is the upstream of the current branch, of it has any upstream at\nall. Sally does 'git fetch' instinctively, and expects Git to do the\nright thing, but it doesn't, it does an utterly irrelevant and useless\naction; non-fetching from a local-remote.\n\n> In addition, that does not break the \"pull = fetch + merge\"\n> equivalence you seem to be ignoring.\n\nDo you want me to count to you the many times I've proved to you that\npull is NOT fetch + merge?\n\nYOU are the one ignoring the fact that it's not: it's only that way in\nvery specific circumstances, certaily ver far from being a universal\ntruth.\n\n> If she wants to check what Eric has been doing, she can do \"git\n> fetch git-svn\", giving the remote name she calls Eric's tree with.\n> At that point, she is not saying \"I want to check what is happening\n> to the upstream of my _current_ branch\" (and the fetched result is\n> not something she can immediately use while on her current branch).\n\nIrrelevant.\n\n> On the other hand, an unqualified \"git fetch\" that slurps from my\n> tree, which is your (b), is just plain wrong.\n\nBut that's *EXACTLY* what we do when there's no upstream branch, is it not?\n\n> My tree is not even\n> related to what she is working on.\n\nUnless you are prepared to say fetching from any other tree that @{u}\nis wrong, and 'git fetch' should forbit it, this is irrelevant.\n\nThe user can fetch from wherever they want.\n\n> Of course, when she is interested in what have been happening in my\n> tree, she can say \"git fetch origin\".\n\nIrrelevant. We are not changing that behavior.\n\n-- \nFelipe Contreras\n"},{"id":"218214","messageId":"CAMP44s0mKAtTy=B09ZGGx6XqVEpJtgXqs57ybWf71H9LYDpMhQ@mail.gmail.com","threadId":"33870","inReplyTo":"6B51848E2F9A40078A2E42CE4BB499DA@PhilipOakley","subject":"Re: [RFC/PATCH 2/2] doc: command line interface (cli) dot-repository dwimmery","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-05-22T22:15:29Z","receivedAt":"2013-05-22T22:15:29Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Wed, May 22, 2013 at 5:09 PM, Philip Oakley wrote:\n> From: \"Felipe Contreras\" \n> Sent: Wednesday, May 22, 2013 12:03 AM\n\n>>> The value of the trick was acknowledged as now being in use\n>>> http://article.gmane.org/gmane.comp.version-control.git/223572\n>>\n>>\n>> How is that more useful than 'git branch -f master $sha1'?\n>\n>\n> The 'trick' checks for a fast forward, while the branch update is forced. It\n> depends on what checks are desired.\n\nIf that was truly useful, surely we could add an option for 'git\nbranch' to do just that.\n\n> My original patch was to simply document Git's dot repository capability\n> that does not appear to be that well known. Let's not keep it as an Easter\n> Egg.\n\nI know, all I said is that I think nobody cares about that\nimplementation detail. Instead of explaining to the user why Git has\nso many quirks, we should get rid of them and make it work more in\nline with users' expectations.\n\n-- \nFelipe Contreras\n"},{"id":"227651","messageId":"1379107397-964-1-git-send-email-philipoakley@iee.org","threadId":"33870","inReplyTo":"1368964449-2724-1-git-send-email-philipoakley@iee.org","subject":"[PATCH V2 0/3] Extend dot repository documentation","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-09-13T21:23:14Z","receivedAt":"2013-09-13T21:23:14Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"This is an update to my patch series on 19 May documenting the\ndot repository notation.\n\nThe earlier threads start at:\n$gmane/224870/ [0/2] Extend dot repository documentation\n$gmane/224868/ [1/2] config doc: add dot-repository note\n$gmane/224869/ [2/2] doc: command line interface (cli) dot-repository\ndwimmery\n\nThe base documentation is now the URLs section (first patch) as suggested by Jonathan,\nwith a clarification in config(1) branch..remote, and finally a note in cli(7).\n\nThe patches can be squashed together if appropriate.\n\nPhilip\n--\n\nPhilip Oakley (3):\n Doc URLs: relative paths imply the dot-respository\n config doc: update dot-repository notes\n doc: command line interface (cli) dot-repository dwimmery\n\n Documentation/config.txt | 6 ++++--\n Documentation/gitcli.txt | 4 ++++\n Documentation/urls.txt | 7 +++++++\n 3 files changed, 15 insertions(+), 2 deletions(-)\n\n-- \n1.8.1.msysgit.1\n"},{"id":"227652","messageId":"1379107397-964-2-git-send-email-philipoakley@iee.org","threadId":"33870","inReplyTo":"1379107397-964-1-git-send-email-philipoakley@iee.org","subject":"[PATCH V2 1/3] Doc URLs: relative paths imply the dot-respository","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-09-13T21:23:15Z","receivedAt":"2013-09-13T21:23:15Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"Signed-off-by: Philip Oakley \n---\n Documentation/urls.txt | 7 +++++++\n 1 file changed, 7 insertions(+)\n\ndiff --git a/Documentation/urls.txt b/Documentation/urls.txt\nindex 9ccb246..5350a63 100644\n--- a/Documentation/urls.txt\n+++ b/Documentation/urls.txt\n@@ -55,6 +55,13 @@ These two syntaxes are mostly equivalent, except the former implies\n --local option.\n endif::git-clone[]\n \n+Relative paths are relative to the `$GIT_DIR`, thus the path:\n+\n+- '.'\n+\n+is the current repository and acts as if it were a repository\n+named `'.'`.\n+\n When Git doesn't know how to handle a certain transport protocol, it\n attempts to use the 'remote-' remote helper, if one\n exists. To explicitly request a remote helper, the following syntax\n-- \n1.8.1.msysgit.1\n"},{"id":"227653","messageId":"1379107397-964-3-git-send-email-philipoakley@iee.org","threadId":"33870","inReplyTo":"1379107397-964-1-git-send-email-philipoakley@iee.org","subject":"[PATCH V2 2/3] config doc: update dot-repository notes","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-09-13T21:23:16Z","receivedAt":"2013-09-13T21:23:16Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"branch..remote can be set to '.' (period) as the repository\npath (URL) as part of the remote name dwimmery. Tell the reader.\n\nSuch relative paths are not 'special'. Correct the branch..merge\nnote.\n\nSigned-off-by: Philip Oakley \n---\n Documentation/config.txt | 6 ++++--\n 1 file changed, 4 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 599ca52..da63043 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -718,6 +718,8 @@ branch..remote::\n \toverridden by `branch..pushremote`. If no remote is\n \tconfigured, or if you are not on any branch, it defaults to\n \t`origin` for fetching and `remote.pushdefault` for pushing.\n+\tAdditionally, `.` (a period) is the current local repository\n+\t(a dot-repository), see `branch..merge`'s final note below.\n \n branch..pushremote::\n \tWhen on branch , it overrides `branch..remote` for\n@@ -743,8 +745,8 @@ branch..merge::\n \tSpecify multiple values to get an octopus merge.\n \tIf you wish to setup 'git pull' so that it merges into from\n \tanother branch in the local repository, you can point\n-\tbranch..merge to the desired branch, and use the special setting\n-\t`.` (a period) for branch..remote.\n+\tbranch..merge to the desired branch, and use the relative path\n+\tsetting `.` (a period) for branch..remote.\n \n branch..mergeoptions::\n \tSets default options for merging into branch . The syntax and\n-- \n1.8.1.msysgit.1\n"},{"id":"227650","messageId":"1379107397-964-4-git-send-email-philipoakley@iee.org","threadId":"33870","inReplyTo":"1379107397-964-1-git-send-email-philipoakley@iee.org","subject":"[PATCH V2 3/3] doc: command line interface (cli) dot-repository dwimmery","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-09-13T21:23:17Z","receivedAt":"2013-09-13T21:23:17Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"The Git cli will accept dot '.' (period) as the relative path\nto the current repository. Explain this action.\n\nSigned-off-by: Philip Oakley \n---\n Documentation/gitcli.txt | 4 ++++\n 1 file changed, 4 insertions(+)\n\ndiff --git a/Documentation/gitcli.txt b/Documentation/gitcli.txt\nindex 7d54b77..b065c0e 100644\n--- a/Documentation/gitcli.txt\n+++ b/Documentation/gitcli.txt\n@@ -58,6 +58,10 @@ the paths in the index that match the pattern to be checked out to your\n working tree. After running `git add hello.c; rm hello.c`, you will _not_\n see `hello.c` in your working tree with the former, but with the latter\n you will.\n++\n+Just as the filesystem '.' (period) refers to the current directory,\n+using a '.' as a repository name in Git (a dot-repository) is a relative\n+path for your current repository.\n \n Here are the rules regarding the \"flags\" that you should follow when you are\n scripting Git:\n-- \n1.8.1.msysgit.1\n"},{"id":"227661","messageId":"xmqq7gekicqq.fsf@gitster.dls.corp.google.com","threadId":"33870","inReplyTo":"1379107397-964-2-git-send-email-philipoakley@iee.org","subject":"Re: [PATCH V2 1/3] Doc URLs: relative paths imply the dot-respository","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-09-13T22:21:49Z","receivedAt":"2013-09-13T22:21:49Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Philip Oakley writes:\n\n> Signed-off-by: Philip Oakley \n> ---\n> Documentation/urls.txt | 7 +++++++\n> 1 file changed, 7 insertions(+)\n>\n> diff --git a/Documentation/urls.txt b/Documentation/urls.txt\n> index 9ccb246..5350a63 100644\n> --- a/Documentation/urls.txt\n> +++ b/Documentation/urls.txt\n> @@ -55,6 +55,13 @@ These two syntaxes are mostly equivalent, except the former implies\n> --local option.\n> endif::git-clone[]\n> \n> +Relative paths are relative to the `$GIT_DIR`, thus the path:\n\nIs it?\n\n\tgit init src dst\n cd src\n git commit --allow-empty -m initial\n cd ../dst\n git fetch ../src HEAD:refs/heads/copy\n\nwould work, but if it is relative to $GIT_DIR, the last one would\nneed to be written as\n\n\tgit fetch ../../src HEAD:refs/heads/copy\n\nwouldn't it?\n\n> +\n> +- '.'\n> +\n> +is the current repository and acts as if it were a repository\n> +named `'.'`.\n> +\n> When Git doesn't know how to handle a certain transport protocol, it\n> attempts to use the 'remote-' remote helper, if one\n> exists. To explicitly request a remote helper, the following syntax\n"},{"id":"227662","messageId":"xmqq38p8icf3.fsf@gitster.dls.corp.google.com","threadId":"33870","inReplyTo":"1379107397-964-3-git-send-email-philipoakley@iee.org","subject":"Re: [PATCH V2 2/3] config doc: update dot-repository notes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-09-13T22:28:48Z","receivedAt":"2013-09-13T22:28:48Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Philip Oakley writes:\n\n> branch..remote can be set to '.' (period) as the repository\n> path (URL) as part of the remote name dwimmery. Tell the reader.\n>\n> Such relative paths are not 'special'. Correct the branch..merge\n> note.\n\nLooks good.\n\nIt naturally follows that this is also valid:\n\n\t[branch \"master\"]\n \tmerge = refs/heads/master\n\t remote = git://git.kernel.org/pub/scm/git/git.git\n\nand running \"git pull\" while on your 'master'.\n\nThis is because branch..remote usually is spelled with a\nnickname that refers to the [remote ] section, but it does\nnot have to be; it can use a URL to refer to the remote repository.\n\n>\n> Signed-off-by: Philip Oakley \n> ---\n> Documentation/config.txt | 6 ++++--\n> 1 file changed, 4 insertions(+), 2 deletions(-)\n>\n> diff --git a/Documentation/config.txt b/Documentation/config.txt\n> index 599ca52..da63043 100644\n> --- a/Documentation/config.txt\n> +++ b/Documentation/config.txt\n> @@ -718,6 +718,8 @@ branch..remote::\n> \toverridden by `branch..pushremote`. If no remote is\n> \tconfigured, or if you are not on any branch, it defaults to\n> \t`origin` for fetching and `remote.pushdefault` for pushing.\n> +\tAdditionally, `.` (a period) is the current local repository\n> +\t(a dot-repository), see `branch..merge`'s final note below.\n> \n> branch..pushremote::\n> \tWhen on branch , it overrides `branch..remote` for\n> @@ -743,8 +745,8 @@ branch..merge::\n> \tSpecify multiple values to get an octopus merge.\n> \tIf you wish to setup 'git pull' so that it merges into from\n> \tanother branch in the local repository, you can point\n> -\tbranch..merge to the desired branch, and use the special setting\n> -\t`.` (a period) for branch..remote.\n> +\tbranch..merge to the desired branch, and use the relative path\n> +\tsetting `.` (a period) for branch..remote.\n> \n> branch..mergeoptions::\n> \tSets default options for merging into branch . The syntax and\n"},{"id":"227663","messageId":"xmqqy570gxpl.fsf@gitster.dls.corp.google.com","threadId":"33870","inReplyTo":"1379107397-964-4-git-send-email-philipoakley@iee.org","subject":"Re: [PATCH V2 3/3] doc: command line interface (cli) dot-repository dwimmery","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-09-13T22:31:50Z","receivedAt":"2013-09-13T22:31:50Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Philip Oakley writes:\n\n> The Git cli will accept dot '.' (period) as the relative path\n> to the current repository. Explain this action.\n>\n> Signed-off-by: Philip Oakley \n> ---\n> Documentation/gitcli.txt | 4 ++++\n> 1 file changed, 4 insertions(+)\n>\n> diff --git a/Documentation/gitcli.txt b/Documentation/gitcli.txt\n> index 7d54b77..b065c0e 100644\n> --- a/Documentation/gitcli.txt\n> +++ b/Documentation/gitcli.txt\n> @@ -58,6 +58,10 @@ the paths in the index that match the pattern to be checked out to your\n> working tree. After running `git add hello.c; rm hello.c`, you will _not_\n> see `hello.c` in your working tree with the former, but with the latter\n> you will.\n> ++\n> +Just as the filesystem '.' (period) refers to the current directory,\n> +using a '.' as a repository name in Git (a dot-repository) is a relative\n> +path for your current repository.\n\nLooks good to me. Thanks.\n"},{"id":"227686","messageId":"1ADD7BEB330F4246983C461C9B1018FF@PhilipOakley","threadId":"33870","inReplyTo":"xmqq7gekicqq.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH V2 1/3] Doc URLs: relative paths imply the dot-respository","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-09-14T20:47:14Z","receivedAt":"2013-09-14T20:47:14Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Junio C Hamano\" \nSent: Friday, September 13, 2013 11:21 PM\n> Philip Oakley writes:\n>\n>> Signed-off-by: Philip Oakley \n>> ---\n>> Documentation/urls.txt | 7 +++++++\n>> 1 file changed, 7 insertions(+)\n>>\n>> diff --git a/Documentation/urls.txt b/Documentation/urls.txt\n>> index 9ccb246..5350a63 100644\n>> --- a/Documentation/urls.txt\n>> +++ b/Documentation/urls.txt\n>> @@ -55,6 +55,13 @@ These two syntaxes are mostly equivalent, except \n>> the former implies\n>> --local option.\n>> endif::git-clone[]\n>>\n>> +Relative paths are relative to the `$GIT_DIR`, thus the path:\n>\n> Is it?\n>\n> git init src dst\n\nI didn't think you could do that. It's not documented (initialise \nmultiple dirctories with the same command) and on msysgit if fails with \n`usage:`. But I know what you mean.\n\n> cd src\n> git commit --allow-empty -m initial\n> cd ../dst\n> git fetch ../src HEAD:refs/heads/copy\n>\n> would work, but if it is relative to $GIT_DIR, the last one would\n> need to be written as\n>\n> git fetch ../../src HEAD:refs/heads/copy\n>\n> wouldn't it?\n\nAh but... we are specifying a repository here, not a file path, so the \n`$GIT_DIR` / '.git' discovery comes into it, I think. It's the \ndiscovery of the relevant repository that I now realise I've not \nincluded, which can be confusing in the various special cases. So the \nrelative paths comment will be incomplete [your point], and needs \nsomething extra between \"relative to\" and \"the $GIT_DIR\".\n\n>\n>> +\n>> +- '.'\n>> +\n>> +is the current repository and acts as if it were a repository\n>> +named `'.'`.\n>> +\n>> When Git doesn't know how to handle a certain transport protocol, it\n>> attempts to use the 'remote-' remote helper, if one\n>> exists. To explicitly request a remote helper, the following syntax\n"},{"id":"227687","messageId":"001CC3ED329149C1B6BB9E3F271768C2@PhilipOakley","threadId":"33870","inReplyTo":"xmqq38p8icf3.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH V2 2/3] config doc: update dot-repository notes","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-09-14T20:47:40Z","receivedAt":"2013-09-14T20:47:40Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Junio C Hamano\" \nSent: Friday, September 13, 2013 11:28 PM\nSubject: Re: [PATCH V2 2/3] config doc: update dot-repository notes\n\n\n> Philip Oakley writes:\n>\n>> branch..remote can be set to '.' (period) as the repository\n>> path (URL) as part of the remote name dwimmery. Tell the reader.\n>>\n>> Such relative paths are not 'special'. Correct the \n>> branch..merge\n>> note.\n>\n> Looks good.\n>\n> It naturally follows that this is also valid:\n>\n> [branch \"master\"]\n> merge = refs/heads/master\n> remote = git://git.kernel.org/pub/scm/git/git.git\n>\n> and running \"git pull\" while on your 'master'.\n>\n> This is because branch..remote usually is spelled with a\n> nickname that refers to the [remote ] section, but it does\n> not have to be; it can use a URL to refer to the remote repository.\n>\n>>\n>> Signed-off-by: Philip Oakley \n>> ---\n>> Documentation/config.txt | 6 ++++--\n>> 1 file changed, 4 insertions(+), 2 deletions(-)\n>>\n>> diff --git a/Documentation/config.txt b/Documentation/config.txt\n>> index 599ca52..da63043 100644\n>> --- a/Documentation/config.txt\n>> +++ b/Documentation/config.txt\n>> @@ -718,6 +718,8 @@ branch..remote::\n>> overridden by `branch..pushremote`. If no remote is\n>> configured, or if you are not on any branch, it defaults to\n>> `origin` for fetching and `remote.pushdefault` for pushing.\n>> + Additionally, `.` (a period) is the current local repository\n>> + (a dot-repository), see `branch..merge`'s final note below.\n>>\n>> branch..pushremote::\n>> When on branch , it overrides `branch..remote` for\n>> @@ -743,8 +745,8 @@ branch..merge::\n>> Specify multiple values to get an octopus merge.\n>> If you wish to setup 'git pull' so that it merges into from\n>> another branch in the local repository, you can point\n>> - branch..merge to the desired branch, and use the special \n>> setting\n>> - `.` (a period) for branch..remote.\n>> + branch..merge to the desired branch, and use the relative \n>> path\n>> + setting `.` (a period) for branch..remote.\n\nThis may need something extra because it doesn't say where it is \nrelative to, nor comment on git_dir discovery (see patch 1 comments, \nlikewise patch 3)\n\n>>\n>> branch..mergeoptions::\n>> Sets default options for merging into branch . The syntax and\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n> \n"}]}