Lars Hjemli wrote:
quoted text
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html