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

From: Jay Soffian <jaysoffian@gmail.com>
Date: Oct 5, 2011, 19:11 UTC
Message-ID: <CAG+J_Dzg2D+vmFRfLX01S2k98YZQBE0FFv76VAyPnXdetyWADQ@mail.gmail.com>
In-Reply-To: <7vzkhf713u.fsf@alter.siamese.dyndns.org>

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

Show 5 quoted lines

> 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. :-)

Show 12 quoted lines

> 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.

Show 10 quoted lines

> 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.