push: option to push to all remotes?

[jorgeorpinel]

To save time and avoid human error, a new option like dvc push --all|-A could be created to push to all remotes. Not sure it would make sense to also consider for fetch and pull.

I wish option --all-branches used letter -b instead -a so we could use lower case a here.

Somewhat related to #2095

[efiop]

@jorgeorpinel Not sure what is the scenario for this. Could you elaborate?

[jorgeorpinel]

If you have many remotes and want to push to all of them in a single command.

[jorgeorpinel]

For pull/fetch it could be to get the data from any remote where it exists, in case one or another remote has incomplete an cache backup.

[efiop]

If you have many remotes and want to push to all of them in a single command.

I don't understand why anyone would do that though. Am I missing some good scenario?

For pull/fetch it could be to get the data from any remote where it exists, in case one or another remote has incomplete an cache backup.

We've discussed it in another ticket, it would require some cascading logic for remotes to be able to retrieve whatever it can from whichever remote is available.

[jorgeorpinel]

why anyone would do that

I just wanted to recently when testing all kinds of GDrive URL types and formats (there's like 7 options haha). Not sure if there's an actual-use need for it but it's possible, say for a dataset registry repo that has a bunch of folders, each with it's own remote (for access permission purposes), but there's this one folder you want available in all remotes. It just increases the flexibility I think, but prob just a nice-to-have unless users actually request or imply the need for this. Up to you

[efiop]

@jorgeorpinel Good points, but that is quite a synthetic testing scenario :)

a bunch of folders, each with it's own remote

Sounds like a subrepo use case. They will simply have theirown default remote.

I would indeed wait for a user to ask for it, unless it is a blocker for you or significant improvement, of course.

[jorgeorpinel]

No, I agree with you. Thanks

[jorgeorpinel]

@efiop what do you think about renaming all-branches option -a -> -B since the other similar option (-T) stands for all tags? Or -b and -t (lower case), respectively. (Consistency)

[efiop]

@jorgeorpinel Not sure consistency there is worth so much trouble right now. Honestly, wouldn't bother right now with that.

[dbokan2]

Wouldn't the option of making a backup of the files from the main remote by pushing them to the main and backup remote make sense?

[efiop]

@dbokan2 Sure it makes sense for a backup, but it is out of scope for us right now and one could question if that kind of backup functionality is really in our focus (this seems more appropriate for a backup tool, which we are not really trying to be at this time).

[Evidlo]

Just a note that git supports pushing to multiple URLs (as opposed to multiple remotes). These urls can be marked as 'push' URLs.

git remote add origin https://[email protected]/myrepo 
git remote set-url --push --add origin https://[email protected]/myrepo 
git remote set-url --push --add origin https://[email protected]/myrepo
git push # <--- pushes to both URLs

This results in a .git/config that looks like:

[core]
	repositoryformatversion = 0
	filemode = true
	bare = false
	logallrefupdates = true
[remote "origin"]
	url = https://[email protected]/myrepo
	fetch = +refs/heads/*:refs/remotes/origin/*
	pushurl = https://[email protected]/myrepo
	pushurl = https://[email protected]/myrepo

This SO post has about 1000 upvotes, so I wouldn't exactly say this is an obscure feature.