martin f krafft <madduck@xxxxxxxxxx> writes: > TopGit would need to make > a proper branch, merge the bases into it, merge that branch into the > topic branch, and the probably delete the branch pointer, as it's no > longer needed and would only pollute the refs/heads/* namespace. So it happens purely inside TopGit and the end user never sees a state that HEAD points outside refs/heads/, right? Why can't the base flipping operation you descibed be done on detached HEAD? Perhaps with a shell variable or two that hold commit object names you need to keep track of while it is doing is work? > Point being: I understand the reason behind the restriction, and > I wouldn't mind if it were default, but maybe there could be > a controlled way to circumvent it for cases like the one described > above, where it is safe to assume that the user^W^W the tool "knows" > what it is doing. Sure, the tool would know what it is doing, I wouldn't doubt that. But the end users don't. If TopGit dies (or killed) during the base flipping operation, doesn't the end user left in a funny state (granted, a detached HEAD is also a funny state, but it is already a known funny state they are familiar with. HEAD that is a symref but points outside refs/heads/ is a lot funnier). You did not actually answer a larger question. What other undocumented features/restrictions does the code depend on, that tightening them to help normal git users inadvertently may cause breakages similar to this one in TopGit? -- 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
