Hello,
I wanted to know if concurrent command can "break" a repository, ie put
it in an inconsistent state.
I suppose that as long all commands are only querying the status (log,
reflog, status, ....) then such a thing will not happen.
I guess that if only one command changes the status (add, commit, pull,
fetch, push, ...) then the output might be "wrong", but the command that
queries the status does not interfere with the others.
But what if two commands that change the status?
For example a git fetch and git add or git commit at the same time?
A use-case I had recently was me doing "git commit -p" from one console,
and noticing a change I wanted to undo.
I skipped the change, and while "git commit -p" showed me the next diff,
I opened another console.
From there, I did a "git checkout", and reverted the change I just skipped.
Is such use-case supported?
Everything worked as I expected, but it would be nice to know that I did
not "risk" anything.
The use-cases I am most interested in is when working with worktrees.
What if I add a worktree, and "work concurrently" in two worktrees?
For example while git is switching branches in one worktree, doing a
commit in another worktree (assuming I'm not switching to the branch
where I am committing)
What if I am doing an automated "git bisect" in a worktree.
Can I work in another one (doing commits, fetch, rebase, reflog, stash,
...)?
What if I have a cron job that executes "git fetch" in one worktree.
Is it problematic if I happen to execute git fetch at the same time from
another worktree?
If those use-cases are not problematic, as all repositories are linked
together, what are possible issues (ignoring bugs).
Common sense tells me that those operations are supported, but I could
not find any reference, or if there are some guarantees that git wants
to hold, no matter what the current status is.
Best
Federico
