Lars Hjemli wrote: > Extend git-branch with the following options: > > git-branch -m|-M [<oldbranch>] newbranch > > The -M variation is required to force renaming over an exsisting > branchname. > > This also indroduces $GIT_DIR/RENAME_REF which is a "metabranch" > used when renaming branches. It will always hold the original sha1 > for the latest renamed branch. > > Additionally, if $GIT_DIR/logs/RENAME_REF exists, all branch rename > events are logged there. > > Finally, some testcases are added to verify the new options. Ok, I have been feeling uneasy about rename and reflogs for a while now. About removing reflogs too for that matter. In my mind the ref log is about tracking what a ref points to. So I want to be able to say "what was next, yesterday". Do I care if its not there now? Perhaps I want a rename to just put a rename from in the top of the new reflog and leave the old there. Yep, no idea how we would clean them up with this model. But ... -apw - 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