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