stg does not play well together with git-worktree

[Erik Carstensen]

Hi.

I have a repo with multiple worktrees, using git-worktree. I discovered that this does not play well with stg: Stack metadata for a branch are stored as files in a worktree-private directory (.git/worktrees/<worktree name>/patches/<branch name>), which effectively means that a patch stack is private for the worktree where 'stg init' was run. If you attempt to run stg on a branch that was initialized in a different worktree, then it will crash.

The problem can be worked around by manually adding symlinks for each branch into each other worktree-private directory, so that the patches/ directory is visible to other worktrees.

The attached script demonstrates the problem and the workaround.

[Karl Wiberg]

The best way to solve this is probably to put all the metadata in the foo.stgit branch, and not use the file system at all.

--
You received this message because you are subscribed to the Google Groups "StGit (Stacked Git)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stgit+unsubscribe@googlegroups.com.
To post to this group, send email to st...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/stgit/CALeBojS8vRXV8mjX8av4cD%2BHJZeqk9b_8ohuL_W1jeG_nwV45A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Catalin Marinas]

On 22 August 2017 at 11:35, Karl Wiberg <k...@treskal.com> wrote:
> The best way to solve this is probably to put all the metadata in the
> foo.stgit branch, and not use the file system at all.

Yes, that's the main blocker for calling a 1.0 release. There are a
few commands yet to be converted. Based on some old to-do file I had
around:

Stack (branch) commands:
branch
patches
pull
rebase
repair
unhide

Patch commands:
files
fold
import
mail
pick
rename
show
sync

Index/worktree commands:
diff

Some of them are simpler and may not need much work but I have to
re-understand Karl's design (some long haul flights coming up in
Semptember, so a good opportunity ;)).

--
Catalin

[Karl Wiberg]

Yeah, sorry about disappearing in a puff of smoke before finishing it all... :-/

[Erik Carstensen]

True. In the short term, we could consider detecting multiple worktrees and die gracefully, maybe with a hint on how to work around the problem. Or just writing something in the readme. But maybe that time is better spent solving the real problem instead.

On Tue, Aug 22, 2017 at 12:35 PM Karl Wiberg <k...@treskal.com> wrote:

The best way to solve this is probably to put all the metadata in the foo.stgit branch, and not use the file system at all.

On Tue, Aug 22, 2017 at 11:55 AM, Erik Carstensen <mando...@gmail.com> wrote:

Hi.

I have a repo with multiple worktrees, using git-worktree. I discovered that this does not play well with stg: Stack metadata for a branch are stored as files in a worktree-private directory (.git/worktrees/<worktree name>/patches/<branch name>), which effectively means that a patch stack is private for the worktree where 'stg init' was run. If you attempt to run stg on a branch that was initialized in a different worktree, then it will crash.

The problem can be worked around by manually adding symlinks for each branch into each other worktree-private directory, so that the patches/ directory is visible to other worktrees.

The attached script demonstrates the problem and the workaround.

--
You received this message because you are subscribed to the Google Groups "StGit (Stacked Git)" group.

To unsubscribe from this group and stop receiving emails from it, send an email to stgit+un...@googlegroups.com.

[Catalin Marinas]

On 22 August 2017 at 13:55, Karl Wiberg <k...@treskal.com> wrote:
> Yeah, sorry about disappearing in a puff of smoke before finishing it all...
> :-/

No worries. I also disappeared for a few years in the Linux kernel
maintainers land (where I have to deal more with "git pull" rather
than "stg new", though I always wanted to improve stgit to support
patches with more than one parent, a.k.a. a merge commit, and bring it
back in my workflow).

--
Catalin

[Mikhail Terekhov]

Is there anywhere a description of this design?