martin f krafft <madduck@xxxxxxxxxx> writes: > also sprach Junio C Hamano <gitster@xxxxxxxxx> [2009.02.13.0014 +0100]: >> > 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? > > Yes. Now I am confused by your answers. This "Yes" means that setting HEAD outside refs/heads/ happens purely as an intermediate state to avoid setting HEAD to some branch ref. After the operation finishes correctly, HEAD will never be left outside refs/heads/. But this contradicts directly with what you say next. >> 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? > > I am not sure I understand. Isn't that what's currently happening? If you *are* setting HEAD to some ref that is outside refs/heads (or even inside refs/heads for that matter), at that point the HEAD is *not* detached, so no, it obviously is *not* what is happening. I am asking why you need to use a ref to do that, *if* it is a tentative state while the program is running. You are probably calling a git plumbing or Porcelain command that updates HEAD, and the reason why you point HEAD outside refs/heads/ is beause you would want the command you call to update one of the refs/top-bases/ ref through HEAD. I am asking why you are not running these commands on a normal detached HEAD, and then use update-ref (not symbolic-ref) plumbing to update the refs/top-bases/ ref you would want to update when it is done. >> You did not actually answer a larger question. > > It wasn't asked to me before... ;) Go back to the original message and read it again. > Up until now, however, > > git checkout -q "refs/top-bases/$name" > > was not really something undocmented or restricted. Giving checkout anything that is not "a branch name" meant detaching HEAD ever since detached HEAD was introduced, and that is a documented feature. git checkout "refs/heads/master" would behave the same way --- it won't check out the 'master' branch. > I can still call e.g. git update-ref (as opposed to e.g. git > _update-ref) and potentially turn my repository upside down > exemplifies this. The distinction between Porcelain and plumbing is unfortunately not very clear at places. The change we reverted was probably a bad one. The stricter check was not done at the Porcelain level but was done at the plumbing level. -- 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
