On Mon, Aug 03, 2020 at 02:02:14PM -0700, Junio C Hamano wrote: > > There are probably some rough edges that could be smoothed (only looking > > in refs/heads/ and using branch names instead of fully qualified refs, > > handling the case that $to already exists more gracefully, better > > prompting). But something like that might be useful for projects that > > are transitioning. > > > > Note that it only works with protocol v2, though, because we don't > > report non-HEAD symrefs in v0. > > Renaming local branches themselves is probably the least interesting > part. You could even do _without_ renaming your local branches at > all and keep working without any problem. But you need to be able > to adjust to the renaming upstream does, so if your 'topic' branch > builds on top of 'refs/remotes/origin/master' and your upstream > renames it to 'refs/remotes/origin/stuff' you'd need to reconfigure > 'topic' branch to also build on and/or integrate with 'stuff' > instead of 'master'. Yeah, good point. That would be pretty easy to add to the script I showed by looking at: git config --get-regexp 'branch\..*\.merge' refs/heads/master And I guess checking the matching branch.*.remote to match $remote. I think we're getting to the realm where it would be easier to implement in something besides shell. :) But I do think a "branch renaming" helper like this might be useful for projects undergoing this rename. I don't think it makes sense to have as a first-class Git command, but I wouldn't be opposed to carrying something like it in contrib/ if somebody wanted to polish it up. -Peff
