mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Browse source
This commit is contained in:
lh 2022-04-19 01:50:23 +00:00 committed by admin
parent 1c069dafb0
commit 76a739d243
1 changed files with 13 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

13
doc/forum/Issues_with_non-sync_workflow.mdwn Normal file
View file

@ -0,0 +1,13 @@
I recently stumbled across git-annex and quickly fell down the rabbit hole of possibilities. Thanks for creating it; it's exactly what I needed.
I started out with the sync command, but almost immediately realized it wasn't for me when I saw it was committing to my own branches. I discovered the config settings to limit these behaviors, but I decided I wanted to kick the tires and try git-annex without sync first, since I'm quite comfortable with and diligent about pulling, pushing, and rebasing across my machines, even with the extra branch to manage. I might end up sticking without sync even once I'm more familiar, since I don't really like the extra sync branches or the merge commits. I can definitely see why they're preferable for most users, though, since it does cost you some time to get a cleaner history.
My approach was to create a worktree for the git-annex branch via `git worktree add .git-annex; echo '/.git-annex/' >> .gitignore`. This makes browsing the git-annex internals and pushing, pulling, and rebasing the branch only a `cd` away.
Upon trying commands like `get` and `copy`, however, it became apparent that the worktree contents and index for the git-annex branch behaved strangely. I'm not 100% sure what's going on, but they usually look like what happens when you reset a branch to a future commit but use `--soft` instead of `--hard`, meaning all the changes it would require to take the branch from the new future commit on HEAD to the previous HEAD end up in the worktree and the staging area, which is rather disorienting. I don't think it ever caused a legitimate issue, at least. I'm guessing this is because git-annex does not expect its branch to ever be checked out, and so it operates purely on objects in `.git`, so the worktree just end up behind whenever a git-annex operation records state.
Is this by design? Would it affect normal git-annex operation to support worktrees more cleanly for when people do want to browse the branch (e.g. by checking if the git-annex branch has an active worktree and resetting it after recording state)? Otherwise, does anyone have any suggested alternatives for keeping track of what's going on with git-annex internals without having to constantly `git show` and `git log`? Worktrees are really nice for this. Checking out git-annex directly isn't great, because it means I temporarily lose access to my actual files.
Also, the copy command seems to record its state changes at both the source and the destination, meaning you always have to drop one of the resulting commits to the git-annex branch. Anything I can do to streamline that?
Can anyone who generally avoids the sync command offer advice? I'd love to flesh out [workflow 6](https://git-annex.branchable.com/workflow/) a bit.