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

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.


Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to