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

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 5, 2011, 21:29 UTC
Message-ID: <7vy5wz5dql.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CAG+J_Dzg2D+vmFRfLX01S2k98YZQBE0FFv76VAyPnXdetyWADQ@mail.gmail.com>

Jay Soffian <jaysoffian@gmail.com> writes:

Show 18 quoted lines

> On Wed, Oct 5, 2011 at 2:19 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> 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. :-)
>
>> ...
>> 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.

You conveniently also forgot that you also said:

> Aside, there's nothing wrong with renaming a checked out branch.

With that lack of understanding, it wasn't "hadn't gotten there", but was actually "didn't even know it was needed".

But that is OK. We have discussions to find out what we missed by learning from others' insights.

Show 16 quoted lines

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

I am afraid to say, with that statement, that your knowledge about the way the tool can be used is not wide enough to judge if one policy restriction (e.g. "never check out the same branch in multiple places") is general enough to add to the tool. I do not claim mine is good enough, but I at least know better than proposing a rule that may be too restictive to negatively affect other people's workflows.

I always maintain four workdirs that I can use to build the tip of four integration branches while I work on other things in the primary branch, plus another that has a detached HEAD so that I can "reset --hard" around without having to worry about what I do there would negatively affect what I do elsewhere or vice versa. Of course, updating 'master' in my primary repository will require the "build master" workdir to be "reset --hard" before it is used, and that is part of my workflow already. I consider it is one of "people learned to work around the restriction of the tool so well already that they may not realize it" we discussed earlier.

Also, if your goal is to give a different semantics, like:

> In my mind, we're trying to make new-workdir usable for non-advanced
> users. I think it's conceptually simplest to allow a branch to be
> checked out only once.

you would really need to make sure that your changes would not harm other users of the same tool that you are not targetting for, and also the changes to the core part of the system that needs your specialized policy makes sense in the wider context. The former you can claim "the policy does not kick in when configuration is not set", but that is weak if the policy is too ad-hoc and not well thought out. I actually care about the latter more, as it is not worth having to spend maintenance effort to carry changes that only stop some but not other kind of mistakes in the core part to be more widely applicable.