Fossil Forum

fossil remote add does not work
Login

fossil remote add does not work

fossil remote add does not work

(1) By hanche on 2022-08-11 08:54:06 [source]

⬥ fossil remote --help
Usage: fossil remote ?SUBCOMMAND ...?
…
  fossil remote add NAME URL
…
⬥ fossil remote add default ssh://server/something.fossil
unknown repository: add

Clearly, the documentation is wrong. So what is the correct way to add a remote?

(Actual URL edited for privacy and security reasons. But the exact same URL works fine with fossil clone, so that is not the problem.)

I worked around the problem, since the remote and local repositories were identical. I just removed the local repo and clone the remote. Problem solved, but the question remains.

(2) By Stephan Beal (stephan) on 2022-08-11 09:20:32 in reply to 1 [link] [source]

So what is the correct way to add a remote?

Are you running this from outside of a checkout? If so, you need to add the global -R REPO flag to tell it which repo you want. That flag is not documented in every single command because it applies to all but a very small number of them.

If you're running this in a checkout and it errors out that way, it's definitely a bug.

(3.1) By hanche on 2022-08-11 09:44:46 edited from 3.0 in reply to 2 [link] [source]

Sorry, forgot to say, but I was indeed running it in a checkout. (I am well aware of the -R option.)

Also, in case it matters, there were no remotes at the time, since this was a locally created repository.

(4) By Stephan Beal (stephan) on 2022-08-11 10:05:42 in reply to 1 [link] [source]

So what is the correct way to add a remote?

Please try this fix and report back whether it resolves the problem and/or causes you additional grief. It "works for me" but is only very minimally tested. i'm not familiar with the ins and outs of multiple remotes, so it might have undesired side effects and other priorities keep me from going through all of the use cases/code paths in detail right now.

[stephan@nuc:~/tmp/x]$ fossil remote add default ssh://server/something.fossil
[stephan@nuc:~/tmp/x]$ f remote ls
default            ssh://server/something.fossil

(5) By hanche on 2022-08-11 13:08:15 in reply to 4 [link] [source]

That fixed it for me, but like you, I haven't tried hard to break it.

(6) By Martin Gagnon (mgagnon) on 2022-08-11 17:54:39 in reply to 5 [link] [source]

Are use that often at my company, I will give it a try.

(7) By Stephan Beal (stephan) on 2022-08-11 19:38:51 in reply to 6 [link] [source]

Are use that often at my company, I will give it a try.

Thank you. It seems very possible that other cases will be affected broken by the last line of that change. If so, such cases should probably be modified like the first change: set zArg to the URL before doing the goto.

(8) By Martin Gagnon (mgagnon) on 2022-08-12 12:13:39 in reply to 7 [link] [source]

Up to now, it seems to works well.

The only reserve (but not really a strong one) I have is a potential little confusion. "default" remote alias is special and is not really an alias like any other name.

fossil remote add default <something> is equivalent to fossil remote <something>, which is not really adding a remote, it's setting the currently active remote, the one currently in use.

Example, if you do:

$ fossil remote add default http://foo.bar/baz
   ...
$ fossil pull http://another-foo.bar/baz

Will overwrite the remote you supposedly add, now you cannot re-use this remote using a short name.

While if you do:

$ fossil remote add reponame http://foo.bar/baz
   ...
$ fossil pull http://another-foo.bar/baz

Yes, the default (or I prefer to say the currently active remote) change, but my remote named "reponame" still exist, I didn't loose it.

However, the original behaviour was to print an error telling that "add" is an invalid repository, which was kind of confusing too.

(9) By mark on 2022-08-12 14:48:13 in reply to 8 [link] [source]

I agree with mgagnon@; "default" is a special term according to fossil help remote:

The "default" remote is the URL used in the most recent "sync", "push", "pull", "clone", or similar command. The default remote can change with each sync command. Other named remotes are persistent.

Such that it's not intended to be assigned a URL via the fossil remote interface but is managed internally by Fossil.

I do agree that the error is not overly helpful, however, and it could be improved, but I don't think that this should be changed to overwrite the "default" remote with fossil remote add. Instead, as I understand it was intended, named remotes are to be added with fossil remote add and if then used it will become the new default; for example:

00:40 ✔ ~/src/fnc » fossil remote ls          
default            https://cvs.bsdbox.org/fnc
00:40 ✔ ~/src/fnc » fossil remote add new https://fnc.bsdbox.org
00:41 ✔ ~/src/fnc » fossil remote ls                                 
default            https://cvs.bsdbox.org/fnc
new                https://fnc.bsdbox.org
00:41 ✔ ~/src/fnc » fossil pull new
<snip>
Pull done, wire bytes sent: 615  received: 1055  ip: 45.76.197.39
00:41 ✔ ~/src/fnc » fossil remote ls 
default                https://fnc.bsdbox.org
new                    https://fnc.bsdbox.org

(10) By mark on 2022-09-25 13:53:38 in reply to 9 [link] [source]

This has been tweaked on trunk in an effort to make updating the special
"default" remote-url easier.

To update "default":

fossil remote REF

where REF is either a URL or existing remote-url symbolic name.

This has always been available to users to define the default remote.
It's just been emphasised in the help text, and how we handle invalid
fossil remote add default URL commands has been improved.