Allow to use a specific destination folder

[vonpupp]

Hello,

I will give you some background of what I am trying to achieve. I use gitlab, github and bitbucket historically. I would like to do a full backup of all of them into my nas and keep them all in sync, always. Some projects belong to different organizations. Maintain a manifest for each folder/organization is cumbersome. Furthermore there are projects that are archive and there are projects that are still in development.

My local home folder for my repos is ~/repos and my desired archive folder should be ~/repos/archive. I could have two manifest one for the archived projects and another for the current projects, that should work but I still need to maintain two repos for that. Furthermore, there are some times where I want to clone repos in other locations that are not within the local .tsrc folder. For instance, supose I am running a main tsrc project at my home folder but I want some repos to go at ~/org or ~/repos/websites/, or even ~/.homeshick/repos/. Currently this is not possible (or it is not documented)

What I thought of the following: allow a new yaml field "folder", something like this:

repos:
  - dest: org
    folder: ~/
    branch: main
    remotes:
    - name: origin
      url: git@gitlab.com:vonpupp-org/org.git
    - name: https
      url: https://vonpupp:<token>@gitlab.com/vonpupp-org/org.git
    - name: nas
      url: ssh://nas/share/repos/gitlab.com:vonpupp-org:org.git
  - dest: org-media
    folder: ~/repos/archive/
    branch: main
    remotes:
    - name: origin
      url: git@gitlab.com:vonpupp-org/org-media.git
    - name: https
      url: https://vonpupp:<token>@gitlab.com/vonpupp-org/org-media.git
    - name: nas
      url: ssh://nas/share/repos/gitlab.com:vonpupp-org:org-media.git
  - dest: albertdelafuente.com-hugo-refined
    folder: ~/repos/websites/
    branch: master
    remotes:
    - name: origin
      url: git@gitlab.com:albertdelafuentecom/albertdelafuente.com-hugo-refined.git
    - name: https
      url: https://vonpupp:<token>@gitlab.com/albertdelafuentecom/albertdelafuente.com-hugo-refined.git
    - name: nas
      url: ssh://nas/share/repos/gitlab.com:albertdelafuentecom:albertdelafuente.com-hugo-refined.git

I thought the dest field was originally for those purposes but it seems to be an alias. That was not straightforward to me at first, maybe it would makes sense to change the name o the current field dest to name or id and use dest in the future as the folder destination. I understand though that this could have major implications. this is why my original proposal is to just add a new yaml field.

Does it makes sense?

[dmerejkowsky]

Sorry, but I think you are simply not using right tool for the job

I would like to do a full backup of all of them into my nas and keep them all in sync, always.

Using something rsync, reltic or borg-backup looks much more simpler for the task at hand

[vonpupp]

Sorry, I explained myself poorly so I will try to rephrase what I said. I definitely need all the goodies of tsrp, my objective is twofold:

First, manage a large base o git repos all at once, get them all in sync with multiple remotes (sometimes I am on a network that do not allow git access other than https). This is terribly well covered by tsrc and it is the right tool for that mater. This is what I was referring as a "backup". Kind of a mirror with several remotes being one of them on my NAS device.

Second, have to possibility to place these repositories in an arbitrary location on the filesystem. I understand that this is why the link option exists, but... I guess there might be cases where symlinks cannot be used. For instance, I use homesick to manage my dotfiles, it is bash based and it will symlink files in a hardcoded path (~/.homesick/repos). If tsrc repos exists lets say in ~/repos and I symlink a dotfiles project to ~/.homesick/repos/, then when I use homesick to manage my dotfiles, it would symlink a symlink, which I am not sure if it will work, nor the side effects. I haven't tried it though.

An option to bypass this would be to create hardlinks in the filesystem rather than symlink. But I have to do these tests. Overall I thought it could be a nice idea to optimally be able to specify the location of the repo in the manifest, yet this could also bring other side effects.

I will try the lazy route first: symlink and hardlinks and if it doesn't work, I will try to submit a PR for this. I hope now my explanation makes more sense.