Re: [git-users] Re: proper meaning of '.' dot in a git command?
On 2013-05-25 07:55, Philip Oakley wrote: > [...] > Plus the '.' represents 'the thing you are working on / thinking > about', so if the parameter is meant to be a remote repo, then it's > the current repo. If its a file path parameter then its the current > directory. > > I'm not sure if there are any command that include both a remote > parameter and a file parameter option that would get confusing (as if > it isn't confusing enough!) AFAIK there's only one command that takes a directory as a parameter--git add (e.g. git add .). And only the repo syncing commands (pull, push, fetch) take a repository argument. So I think that the `.' as a repo specifier v the `.' as a directory specifier are pretty safely segregated. That said, yes it's true that anyone who thinks of `.' as the current directory will be quite confused when they see it as a repo specifier. > Git does have a lot of instructions that sound like "turn left 300 > meters before where the old church used to be" (and they've relaid the > junction so it feels like a straight on) Yeah, pretty much all the ugly internals are laid bare for everyone to see. It does help to encourage people to use a subset--the newest plumbing commands--I think. > I don't use 'pull' because of the potential issues. It's easier to > fetch, and then fudge from there with forced fast forward etc > (transferring work from Windows netbook to a hack ubuntu laptop whose > graphics chip packs in every month or two) Sure there could be issues. I will say though that if you don't have a dirty working tree--if you've committed everything--before pulling, there's really not much that can go wrong. At worst you'll be a little inconvenienced and will have to run a git reset. Yawar signature.asc Description: OpenPGP digital signature
Re: [git-users] Re: proper meaning of '.' dot in a git command?
[sorry for top post - had to recondtruct the email] Much of the firestorm was about Filippe's use case, with a little bit of reluctance to actually document Git ;-) Plus the '.' represents 'the thing you are working on / thinking about', so if the parameter is meant to be a remote repo, then it's the current repo. If its a file path parameter then its the current directory. I'm not sure if there are any command that include both a remote parameter and a file parameter option that would get confusing (as if it isn't confusing enough!) Git does have a lot of instructions that sound like "turn left 300 meters before where the old church used to be" (and they've relaid the junction so it feels like a straight on) I don't use 'pull' because of the potential issues. It's easier to fetch, and then fudge from there with forced fast forward etc (transferring work from Windows netbook to a hack ubuntu laptop whose graphics chip packs in every month or two) Philip - Original Message - From: "Yawar Amin" To: Cc: "Philip Oakley" Sent: Friday, May 24, 2013 1:56 AM Subject: Re: [git-users] Re: proper meaning of '.' dot in a git command? Hi, On 2013-05-23 15:33, Philip Oakley wrote: [...] I did find part of the documentation hidden in git config as a special case for defining a remote, but the command line effect hadn't been noted. So I've submitted a documentation patch for comment to the main list. Indeed, it's set off quite a firestorm :-) FWIW I still believe that `.' means only `the local repository', and not `the current directory which may or may not contain a .git directory'. You can run a simple git push in a subdirectory of a repository root directory to prove this to yourself: (Assuming a throwaway test repo for the below commands) git checkout -b mybranch master mkdir mydir cd mydir echo myword >myword.txt git add myword.txt git commit -m"My message" git push .. mybranch:master # fatal: '..' does not appear to be a... git push . mybranch:master # Total 0 (delta 0), reused 0 (delta 0)... [...] True. Though often an extended discussion... in [PATCH 1/3] fetch: add --allow-local option, I tend to agree with Junio that the existing _default_ fetch behaviour shouldn't be changed. But disagreement can be vocal sometimes Regards, Yawar -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] Re: proper meaning of '.' dot in a git command?
Hi, On 2013-05-23 15:33, Philip Oakley wrote: > [...] > I did find part of the documentation hidden in git config as a special > case for defining a remote, but the command line effect hadn't been > noted. So I've submitted a documentation patch for comment to the main > list. Indeed, it's set off quite a firestorm :-) FWIW I still believe that `.' means only `the local repository', and not `the current directory which may or may not contain a .git directory'. You can run a simple git push in a subdirectory of a repository root directory to prove this to yourself: (Assuming a throwaway test repo for the below commands) git checkout -b mybranch master mkdir mydir cd mydir echo myword >myword.txt git add myword.txt git commit -m"My message" git push .. mybranch:master # fatal: '..' does not appear to be a... git push . mybranch:master # Total 0 (delta 0), reused 0 (delta 0)... > [...] > True. Though often an extended discussion... > > in [PATCH 1/3] fetch: add --allow-local option, I tend to agree with Junio that the existing _default_ fetch behaviour shouldn't be changed. But disagreement can be vocal sometimes Regards, Yawar signature.asc Description: OpenPGP digital signature
Re: [git-users] Re: proper meaning of '.' dot in a git command?
Hi Yawar, I'm more inclined to say everyone was right in their own way ;-) My first part of the question was asking if the shell itself changed the character, and that was 'No', the dot character is passed to the executable. [this compares to say blob expansion where the shell does change the characters] Then the second part was how did Git handle the dot, and if/where it was documented. I did find part of the documentation hidden in git config as a special case for defining a remote, but the command line effect hadn't been noted. So I've submitted a documentation patch for comment to the main list. regards Philip - Original Message - From: Yawar Amin To: git-users@googlegroups.com Cc: Philip Oakley Sent: Thursday, May 23, 2013 2:43 AM Subject: [git-users] Re: proper meaning of '.' dot in a git command? Hi Philip, On Thursday, May 16, 2013 6:42:03 PM UTC-4, Philip Oakley wrote: Recently there have been a couple of example commands that have a single dot '.' in the command line. In this case what is its proper meaning, that is, is it expanded by the bash shell, or by git it self, and what would its typical expanded version look like if it is the current dicetory e.g. fully qualified etc. ? I'm afraid none of the replies here have been correct. When used with fetch/push/pull, the dot means `this (the local) repository'. As I understand it, if Git is decoding a parameter as if it is a remote then we get that expansion. (bit not if we are creating/naming a remote as it's not allowed in that direction) [...] On Sat, May 4, 2013 at 2:51 PM, Jonathan Nieder wrote: > Another trick is to use "git push": > git push . $production_sha1:refs/heads/master This means push this repository's $production_sha1 to this (same) repository's master. This is a shortcut way of saying git checkout master git merge --ff-only $production_sha1 git checkout $production_sha1 Where $production_sha1 can be any branch, tag, or commit ID. Notice the `--ff-only', which forces $production_sha1 to be a descendant of master. Remember that this is how push behaves by default. True [...] 'git fetch .' This means fetch all refs from this repo into this repo as remote refs. As you are probably thinking, this doesn't make much sense. So I think the git devs are discussing adding an option here to clarify the use cases: True. Though often an extended discussion... in [PATCH 1/3] fetch: add --allow-local option, Regards, Yawar -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[git-users] Re: proper meaning of '.' dot in a git command?
Hi Philip, On Thursday, May 16, 2013 6:42:03 PM UTC-4, Philip Oakley wrote: > > Recently there have been a couple of example commands that have a single > dot '.' in the command line. > > In this case what is its proper meaning, that is, is it expanded by the > bash shell, or by git it self, and what would its typical expanded > version look like if it is the current dicetory e.g. fully qualified > etc. ? > I'm afraid none of the replies here have been correct. When used with fetch/push/pull, the dot means `this (the local) repository'. > [...] > On Sat, May 4, 2013 at 2:51 PM, Jonathan Nieder > > > > wrote: > > Another trick is to use "git push": > > git push . $production_sha1:refs/heads/master > This means push this repository's $production_sha1 to this (same) repository's master. This is a shortcut way of saying git checkout master git merge --ff-only $production_sha1 git checkout $production_sha1 Where $production_sha1 can be any branch, tag, or commit ID. Notice the `--ff-only', which forces $production_sha1 to be a descendant of master. Remember that this is how push behaves by default. > [...] > > 'git fetch .' > This means fetch all refs from this repo into this repo as remote refs. As you are probably thinking, this doesn't make much sense. So I think the git devs are discussing adding an option here to clarify the use cases: > in [PATCH 1/3] fetch: add --allow-local option, > Regards, Yawar -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
