On Mon, 2010-07-19 at 01:19 +0200, Jakub Narebski wrote: > On Sun, 18 Jul 2010, Will Palmer wrote: > > On Sun, 2010-07-18 at 13:55 +0200, Jakub Narebski wrote: > > having any kind of suffix like refs~/heads~/bar is just asking for > > someone to delete a branch twice. > > I don't understand what you wanted to say here. Using the > > $GIT_DIR/logs/refs~/heads~/bar > > (and not $GIT_DIR/refs~/heads~/bar) as a reflog for a deleted branch > 'bar' is an implementation detail. You wouldn't see refs~/heads~/bar > when listing branches... well, perhaps 'git branch --list-deleted' > could be used to list deleted branches (by scanning for reflogs). > git branch -d integration # git renames refs/heads/integration to refs~/heads~/integration git co -b integration sometopic # git creates refs/heads/integration, unrelated to the old one (do some work) (merge into the main branch) git branch -d integration Now what? git renames refs/heads/integration to ... what? - does the old refs~/heads~/integration get clobbered? If that's ever okay, why are we even having this discussion? - does the "old reflog" stuff get combined? If that's ever okay, why even have an extra reflog, instead of just using the reflog we already have? - do we move everything else one step down, so refs~/heads~/integration becomes refs~2/heads~2/integration? (ie: 2-dimensional reflog, which sounds rather too fancy, to me) -- -- Will -- 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