On Sun, May 11, 2025 at 10:50:21PM +0100, Colin Watson wrote: > On Sun, May 11, 2025 at 02:35:14PM -0700, Otto Kekäläinen wrote: > > > Once we have a decision, Guido is more likely > > to support making that decision the default in git-buildpackage, and > > the people who previously migrated from master to debian/master or > > debian/sid (while the historic DEP-14 suggested them) are more likely > > to change to the final branch name. With this everything would most > > likely converge. > > I think this significantly underestimates the annoyance involved in renaming > existing long-lived branches (in that all clients have to re-clone or > manually adjust), which is certainly why I generally avoid doing so unless I > absolutely have to. > I'm personally not a fan of branch renaming, so I can see the validity of arguing for "no change". However, would it not be possible for those who prefer to keep the old branch names (for the sake of compatibility with existing tools/working copies/etc) to change the *default* (so that new clones benefit from the new/preferred naming structure) and then maintain the old default and the new default in sync by way of a 'git merge --ff-only' (which could be implemented in a hook, CI, or some other automated means)?
This could even be something that gbp is aware of (maybe by a configuration option which can be placed in gbp.conf, perhaps named something like 'old-debian-branch') which it then warns the user about when the two branch pointers aren't pointing at the same commit. Or something like that. Regards, -Roberto -- Roberto C. Sánchez
