Christian Couder <chriscool@xxxxxxxxxxxxx> writes: > It is strange and fragile that a mixed reset is disallowed in a bare > repo but is allowed in a .git dir. So this patch simplifies things > by only allowing soft resets when not in a working tree. I would not mind what you said were "I find the difference strange", as it is a fairly subjective word. But if you say "fragile", you would need to defend the use of the word better. What kind of misuse does it invite, and what grave consequences such misuses would cause? I do not see any fragility and I would want to understand it better so that I can write about it in the Release Note to warn people and encourage them to upgrade. More importantly, I think the difference between the two actually makes sense. A bare repository by definition does _not_ have any work tree so there is no point in having the index file in there. On the other hand, even though it is not necessary to "cd .git && git reset HEAD^", I don't see a strong reason why it needs to be disallowed. On the other hand, I don't see a strong reason why such a use needs to be supported, other than "we've allowed it for a long time, and people may have hooks (they typically start in $GIT_DIR) that rely on it", which by itself is not something strong enough to veto the change. It is only a minor incompatibility and I can be persuaded to listen to a pros-and-cons argument. An honest justification might have been "This change to disallow a mixed reset in $GIT_DIR of a repository with a work tree will break existing scripts, but I think it is not widely used _for such and such reasons_, and can easily be worked around. On the other hand, this change vastly simplifies the reimplementation of 'reset' _because X and Y and Z_". > This patch is also needed to speed up "git reset" by using > unpack_tree() directly (instead of execing "git read-tree"). It is very unclear _why_ it is "needed" from this description. -- 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