On Fri, Oct 11, 2024 at 12:21 PM Rebecca Turner <rbt@xxxxxxxxxxxx> wrote:
>
> > Why would you move the `.git` directory? If you're trying to move the
> > repository, then wouldn't you just move the directory that contains the
> > `.git` directory?
>
> Ah, I should give some context here. I'm using worktrees with the layout you
> describe later in your email:
>
> my-repo/
> .git/ <- bare git directory
> main/ <- worktree for main branch
> feature1/ <- worktree for feature work
> ...
>
> I'm writing a tool to manage these layouts for you. I want to provide two
> features:
>
> 1. The ability to add a new worktree in a slightly more magical manner; in
> particular, I want to be able to do `git my-tool add feature2` and add a new
> worktree in the same directory as all the other worktrees.
>
> For a non-bare main worktree, that directory is the parent of the main
> worktree.
>
> For a bare main worktree named `.git`, it's the path of the main
> worktree. (Nothing in the `git worktree list` output indicates this is the
> case!)
>
> For other bare worktrees, it's the parent of the main worktree.
Rebecca,
I'm working on a tool to manage worktrees as well. Can we compare notes?
My directory structure separates repositories and worktrees in
separate directories, but the goals seem similar.
git documentation seems to treat the bare repository concept as if one
only uses bare repositories on a server, not locally in a development
environment.
But, I've found that local worktree-based development is possible for
multiple applications, libraries, toolchains, and CI, but it isn't
very easy to maintain by hand, so tooling is a must. With some
scripting, it works well for many bare repositories, numerous branch
worktrees, and multiple build-and-run scenarios. Switching between
tasks is almost instantaneous, with no need to stash or un-stash
anything.
I've managed to come up with a bash implementation with just three
commands for starting an editor/ide, building and running. Parameters
to these commands set the context for whatever it is I'm working on at
the moment. I'm working on separate commands to maintain the
environment. I need to do such things as clone an upstream repo,
clone
-Pat Callahan
Framingham, Ma
Here's the list of requirements I'm working with:
Overview
- Use only bare repositories and worktrees
- Start an Ide, a build, a run for whatever I'm working on at the moment
- Support development work on multiple applications, libraries, or tools
- No limit to the number of working contexts.
- Instant focus on a specific context: a set of repositories,
git-references. and worktrees
- Instant switch between different working contexts within the same
application or between different applications.
Repositories
- Bare clones of a set of official and forked repositories from
Github, Gitlab, or Sourceforge
- Local Bare Repos Only
- All Repos in one directory as repo-name.git
- Worktrees as needed for building
Worktrees
- All Worktrees in another single directory as repo-name.git-reference
(git reference being a branch, tag, or commit
- Worktree synchronization by git pull upstream, or git pull upstream --rebase
- Directories
- Hierarchy as flat as possible
- Automatic setup of out-of-tree builds using symbolic links to one or
more worktrees
IDE or Code Editor support
- Automatic setup of multiple multi-root workspaces based on the list
of worktrees used to build a specific branch.
Building and Running
- A default build script and custom build scripts where appropriate
- A default application run script with custom run scripts where appropriate
- Straightforward, flexible command line syntax
Example: Build four separate cmake build types: Debug,
RelWithDebInfo for each of two branches
b app-name branch-name1 branch-name-2 d rd r m
