Re: [RFC/PATCH] Add multiple workdir support to branch/checkout

[Jay Soffian <jaysoffian@gmail.com>]

On Wed, Oct 5, 2011 at 2:19 PM, Junio C Hamano <gitster@pobox.com> wrote:

> Careful. Git has survived without your patch series till now, as people
> learned to be careful when they use separate workdirs and avoid certain
> things, to the point that they are not necessarily aware that they are
> avoiding them (one good practice is to keep the HEADs of non-primary
> workdirs detached).

I think it's more likely the case that most people have avoided
new-workdir entirely.

Also, while I might recommend new-workdir to my coworkers with the
advice "don't checkout the same branch in multiple workdirs", never in
a million years would I say "use new-workdir, but make sure to only
use a detached HEAD in the workdirs." The latter would make their
actual HEADs explode. :-)

> For example, you checkout branch frotz in a workdir, and then in the
> primary repository that has nitfol branch checked out, you rename the
> frotz branch to xyzzy. The HEAD of workdir still says refs/heads/frotz
> that no longer exist. Of course you can break the same way by doing a
> "update-ref -d refs/heads/frotz" from the primary repository.
>
> Because you forgot that the high level operation "branch renaming" needs
> to be aware of that "this branch is checked out elsewhere" information,
> you allowed it to break the workdir. If you hooked into lower level
> machinery that is shared, you wouldn't have caused this breakage.
> Similarly, if delete_ref() were taught about the new requirement, you
> would have covered both "branch -d" and "update-ref -d".

I did not forget, I just hadn't gotten there yet while this was still
an RFC/PATCH.

Another issue to resolve is what happens when the workdir or repo are
moved in the filesystem. And making prune aware of HEAD reflogs in the
alternate workdirs.

> I do not necessarily think that it is a good approach to forbid the same
> branch to be checked out in two different places, by the way. One reason
> people would want to keep multiple workdirs is so that while they are
> still working on a branch and are not yet at a good "stop point" to even
> make a temporary commit to get interrupted, they find it sometimes
> necessary to be able to build the tip of that same branch and even make a
> small in-working-tree fixes (which later will be carried back to the
> primary branch). The problem arises only when one of the repositories try
> to update or delete the branch while it is checked out in another working
> tree.

That is not at all my experience of how workdirs are used.

> Can this series be extended/reworked so that:
>
>  - Each branch has multi-value configuration record to note the workdirs
>   that it is checked out;

This is a good idea in any case for when "checkout --force" is used
(see below), so that we can find all the workdirs for other operations
that may need to.

>  - Error out (or warn if forced) upon any attempt to update the tip of a
>   branch that is checked out in more than one place; and

I think that's a worse user experience. "Sorry, can't commit your
changes because you've checked out this branch elsewhere." Now the
user's choices are:

1. commit --force (and thus confusing the other workdirs)
2. checkout -b new_branch && commit

Both of which I think are worse than preventing the checkout in the first place.

>  - Similarly for renaming or deleting a branch that is checked out in more
>   than one place.

Yep.

j.