I am aware that it is possible to do this by setting override_path, but it is really annoying doing this for every project, instead of it defaulting to that path when using the add command.

I think this is related to #23
@mriehl any other ideas?

Yeah, it seems to be related, if #23 were implemented that should fix my issue.

Yeah I also agree this is something #23 could tackle (along with a slew of other customizations).
I guess there is a workaround where you can "implement" your logic in a shell alias, by saying something like:

/usr/bin/fw-add-nested:

#!/bin/bash

REMOTE=${1:?"Usage: $0 <git remote>"}
NAME=$(echo "$REMOTE" | cut -d "/" -f2 | tr -d ".git")

fw add "$REMOTE" --override-path "/tmp/$NAME/$NAME"

and then you can just do fw-add-nested git@github.com:foo/bar.git

It isn't the sexiest but that would work with unlimited flexibility today and we won't break CLI backwards compatibility especially in the case of something like fw add.

@bomgar what do you mean it breaks fw sync? It's basically just a project with override path.
Do you mean there's a mkdir -p missing somewhere in the sync code because the parent dir basically doesn't exist?

A sorry I should no reply to threads after waking up.

@LordMZTE is the workaround working for you? Or are you planning on working on the issue yourself? Or should we implement something if we decide what to do and have the time to implement it?

I haven't tried the workaround yet, but once we decide what to do in #23 I'd be happy to contribute!

This is a short title but would be a huge feature.
As the project list grows, it is hard keeping a flat srtucture.
Moreover some (non monorepos) projects may require a parent folder to keep things organize.
Finally for archiving purpose, it would be sweet being able to sort out projects in folders with as 2024, 2025, etc...

I discovered override_path which is already pretty nice indeed.
It would be ideal if fw add . could work for an existing project and the path automatically set to the current dir using override_path if the value does not match the standard.

#23

this would solve a lot. I just don't have time to work at it at the moment.

Also try fw import instead of fw add

@chevdor I just looked at the code. Tags can define the workspace. Can you try if that solves your problem?

@bomgar happy new year 🎉 :)

I am not sure I can/want to use tags for the use case.

Honnestly I did not know about --override-path and it works pretty well already.
The only drawback being the required manual step to set it up. And option may be to check if the add/imported project is in the canonical folder and if not, set the --override-path automagically. I am not sure if importing an already imported folder is "legal" but if it is, that would be an option then to "fix" a folder/project that was moved.

So say:

• you have project under the canocial workspace => same as today
• if you add/import a project under another folder, --override-path is set
• importing again a project will check if --override-path still match and update the path (with confirmation maybe)

Do you think that would be possible ?

My main use case is that I have soo many projects under the canonical root and I now group them so I go from:

• /project1
• /project2
• /project3

to

• /topic1/project1
• /topic1/project2
• /project3

If you create a tag like this:

» cat ~/.config/fw/tags/default/2025

workspace = "~/development/2025"

Every project tagged with this tag will be synced to ~/development/2025

@chevdor

yes, for some subfolder per year, that seems to be a good option and that was indeed my exemple.
I take the trick about the tag too, I will help for the "archived" projects.

I may use it but I will likely sort also per "topic" or project and I find it too much to have a tag per project and having to move the project to the right place. I think it would be more convenient if fw could simply detect the folder's location and set the path accordingly.

Howver, I can foresee conflicts if say my ProjecXYZ is tagged as such and as well 2024. What would be the folder then ? In the end, the only right answer is that the folder is where the files actually are, not where they are supposed to be according to the tags.

fw import does set the override path
fw add has it as a cli arg

do you need fw move maybe?

tags have a priority.

@chevdor

fw import does set the override path, wait it does indeed !
I see that import creates a duplicate though. So indeed, a fw import --move or better fw move . that simply removes the older one would be awesome and solve the problem.

It will be more like fw mv <project-name> </new/path>

and fw will move the files. I already built something but i'm unsure about the move. It is only atomic if source and destination are on the same file system.

@chevdor can you try fw 2.20.0

So I just tested the following:

• I had a project already under /p/e
• I moved it (shell mv, not fw) to /tmp
• fw was obvioulsly confused at that point, OK
• i ran fw import . inside /tmp/e
• fw was happy again
• then fw mv /tmp/e /p/e
• here it failed with Error running command: error User error: project key e found but path /private/tmp/e does not exist
• from /p/e I ran another fw import and the issue was fixed.

The issue may be due to MacOS and its funky /tmp = /private/tmp per user.

if you already moved it you should use fw update --override-path
fw move is to move it for you.

AFAIC, with all those options, we are good regarding the topic. Thanks for the hard work @bomgar