add option to keep projects in nested directories

[LordMZTE]

I personally like keeping my projects in a nested directory.
For example, if I'm working on a project foo, then the git repo would be cloned at ~/dev/foo/foo.
With this structure, I can keep additional things needed (such as testing environments) for foo in the outer foo directory, without interfering with the repo.
However, fw doesn't seem to support this. It would be really awesome to have this, as fw currently wouldn't work with some of my projects for that reason.

[LordMZTE]

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.

[bomgar]

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

[LordMZTE]

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

[mriehl]

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]

This breaks fw sync.

On Mon, Jun 14, 2021, at 07:07, Maximilien Riehl wrote: Yeah I also agree this is something #23 <#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 ***@***.***: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. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#187 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADCFBD2L6AZSJRKHPO6DVLTSWFAXANCNFSM46RN6IQA>.

[mriehl]

@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?

[bomgar]

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

[bomgar]

@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?

[LordMZTE]

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

[chevdor]

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.

[bomgar]

#23

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

[bomgar]

Also try fw import instead of fw add

[bomgar]

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

[chevdor]

@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

[bomgar]

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