From: Junio C Hamano Date: Thu, 12 Feb 2009 23:14:50 GMT Subject: Re: [topgit] tg update error Message-ID: <7vocx7i6xh.fsf@gitster.siamese.dyndns.org> In-Reply-To: <20090212214106.GC26573@piper.oerlikon.madduck.net> martin f krafft 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?