On Wed, Oct 5, 2011 at 5:29 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> 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.
Is it a regression to your workflow that you have to now use "checkout
-f" instead of "checkout" to checkout the same branch in more than one
location?
> 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.
Perhaps:
core.multipleCheckouts = {true,false}
- false prevents multiple checkouts without -f
advice.multipleCheckouts = {true,false}
- false disables multiple-checkout notice
And when there are multiple checkouts, warn on committing about other
workdirs that now need reset --hard.
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