On Thu, Jul 08, 2010 at 13:08:42 +0200, Pierre Habouzit wrote:
> 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.
> 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.
> 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@xxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html