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
