Re: fixing workdirs
- From
- Jan Hudec <bulb@ucw.cz>
- Date
- Aug 17, 2010, 18:34 UTC
- Message-ID
- <20100817183435.GA2717@efreet.light.src>
- In-Reply-To
- <20100708110842.GC12789@madism.org>
On Thu, Jul 08, 2010 at 13:08:42 +0200, Pierre Habouzit wrote:
Show 12 quoted lines
> At work we (ab-)use workdirs a lot, though, workdirs aren't for > everybody, and as our company grows, not everybody uses them sanely. > > The two problems (that are well known to this list, and is the reason > why git new-workdir is in contrib afaict) with workdirs are: > > - the HEAD reflogs aren't shared, which means that pruning a working > directory may trash accessible stuff from the reflog of another one. > > - if two workdirs are on the same branch at the same time, really, > really, *REALLY* bad things may happen if one isn't aware of that > fact.
It should be possible to guard against those bad things. Basically the bad things happen when a symbolic HEAD's target is changed in a way the HEAD is not aware. But in those, and only those, cases the HEAD's reflog is not updated. So some operations could check whether HEAD@{0} resolves to the same commit as HEAD and if not they would either fail or automatically detach HEAD.
That would serve as a safeguard not just against one worktree commiting to a branch checked out in another worktree. It would also safeguard against pushing to the branch provided the code in update that updates HEAD's reflog was disabled for non-bare repositories.
Show 12 quoted lines
> I'm intending to adress those issues, though I would like to know how it > would be received. My current plan is this one. Have a git workdir > command, with a few subcommands (create, move, rename, ...), that > addresses both of the previous issues. > > for the first one, the fix is simple: workdirs have now a name, and > their HEAD reflog lives in the "master" git repository reflog namespace > under logs/workdir/$workdir_name/HEAD. The workdir HEAD reflog is then a > symlink to the masters. > > In this way, all workdirs see all the reflogs of every single workdir, > and pruning is safe again.
The problem with it is that it falls apart when somebody forgets to use the 'git worktree remove' command and deletes (or renames) the work-tree manually.
Alternative idea would be to add support for new layout with one repository and multiple worktrees. The worktrees would be restricted to siblings of the .git directory where the repository lives with the repository itself being marked as bare. So the layout would be:
somedir/ somedir/.git/ <- the repository, makred as bare somedir/worktree1/ <- a worktree somedir/worktree1/.git/ <- worktree's .git in current format somedir/worktree2/ <- another worktree somedir/worktree2/.git/ <- worktree's .git in current format ...
Such scheme would exchange some flexibility for more safety. The worktrees could be created with current new-workdir. They would be found as simply $GIT_DIR/../*/.git for purpose of solving the two problems above. On the other hand a method for preparing this layout (git init --multiple-trees, git clone --multiple-trees or something like that) would be needed.
IIRC bazaar uses scheme like this for it's multiple-worktree support.
Show 7 quoted lines
> For the second one, when a workdir is created, a [workdir "foo"] section > is added to the master directory, with a path configuration variable > pointing to the ... path of the working directory. My plan would be to > teach git checkout to lean about that, and when there are workdirs > set up, git checkout would check that no other workdir is currently "on > the same branch", and would refuse to checkout to a branch that is > already checkouted elsewhere.
Wait a second. Don't you have the HEADs and their reflogs for workdirs stored in the master? So you can just compare with all the other HEADs there, no?
The bookkeeping would break if you just deleted the workdir without telling git. The configuration will break even more readily as renaming also breaks it.
Kind regards, Jan
-- Jan 'Bulb' Hudec <bulb@ucw.cz>