Reorganize Colvars repo tree

[jhenin]

The root level contains a large number of directories that play different roles. Some directories, like python and C_fortran contain only experimental features.

One of the goals would be making user scripts easier to find, and generally separating user stuff and developer stuff.

[jhenin]

Partly done by #572

[jhenin]

[Converting this to a Discussion, because that's what it is]

I plan to add the Tinker-HP interface to this repo soon, however I am reluctant to creating yet another toplevel directory in the tree, which I think is quite crowded already. Eventually, I think all the interfaces would be better in a subdirectory. The change would certainly come at a (moderate) cost, but the repo would be clearer. Git is good at tracking files across moves, too, so the history would not be broken.

[giacomofiorin]

If the main purpose is finding user scripts more easily, how about placing them on the main webpage or similar resource that is dedicated exclusively to users? We are doing that for the documentation, which is nowhere near being readable in any given snapshot of the repository without being built first.

[jhenin]

No, the main purpose is to have a repo that looks clean and understandable to would-be users and contributors. The GROMACS repo is a good example of that, it has a very logical directory structure that looks designed from the ground up, which I'm sure it wasn't, but was refactored over the years to be cleaner.

[giacomofiorin]

Can you please try git log -S on a file that was moved from a folder to another? You will see that the previous history stops at the commit that moved those files around.

EDIT: I am aware of --follow, but that will imply that people searching through the history of a file will have to remember to always use it. The GitHub web UI is a little nicer because it shows you a link. But either way, it's a two-step procedure for each file that you want to see the history of.

When I look at a big repository that I'm very new to (i.e. taking the point of view of a contributor), this is something that I would like to work as smoothly as possible.

[jhenin]

If I'm interested in tracking content, I can use git log -S without specifying a file name, and that is not affected by moves.
If I'm interested specifically in a file's history, not its content's (a rather unusual situation), then git log --follow works.

If it didn't, the changes that break up existing files into smaller ones (as you did with colvarproxy.cpp) would be highly problematic, because they interrupt their history, but I didn't hear any complaints about those.

[giacomofiorin]

If I'm interested in tracking content, I can use git log -S without specifying a file name, and that is not affected by moves. If I'm interested specifically in a file's history, not its content's (a rather unusual situation), then git log --follow works.

I find if very rare where git log -S is useful without specifying a file or a folder to narrow down the matches. Which actually brings up something interesting: if you use git log -S <some text> --follow <some folder> the --follow flag has no effect...

If it didn't, the changes that break up existing files into smaller ones (as you did with colvarproxy.cpp) would be highly problematic, because they interrupt their history, but I didn't hear any complaints about those.

That was indeed not helpful toward keeping the history, but it has to be weighed against an alternative that is sometimes worse (i.e. keep maintaining an overblown single source file).

Again, this discussion still seems quite abstract to me, i.e. it feels like I'm missing a conversation with other users or developers, whose point of view you may be trying to describe?

[jhenin]

This is just my perspective, I don't have external feedback on this. Maybe I should ask for some :)