> Why not just lay down a new tag on main to work around this? Good idea. This could work. We would need to do it for each dependency if we archived branches on it.
On 2020/10/29 14:32:17, Joan Touzet <woh...@apache.org> wrote: > Hi Ilya, > > Sorry about this trouble. Based on this feedback I will not pursue > removal of our release branches. > > On 2020-10-29 5:56 a.m., Ilya Khlopotov wrote: > > > ❯ git describe --always --tags > > archive/prototype/fdb-layer-get-doc-spans-580-gdfb27b48a > > but: > > $ git checkout 3.x > Branch '3.x' set up to track remote branch '3.x' from 'origin'. > Switched to a new branch '3.x' > > $ git describe --always --tags > 3.1.1-18-gffbf695ff > > This is only happening because the most recent tag found on the 'main' > branch has archive/ in it. > > Why not just lay down a new tag on main to work around this? Example: > > $ git checkout main > $ git tag post-fdb-merge > $ git describe --always --tags > post-fdb-merge > > Future commits past that will reference post-fdb-merge in the git > describe command, and not that archived tag. Further, new branches that > are merged will simply be deleted, not archived, so this shouldn't be an > issue. > > -Joan >
