[HN Gopher] Archiving Git branches as tags
       ___________________________________________________________________
        
       Archiving Git branches as tags
        
       Author : octavore
       Score  : 59 points
       Date   : 2025-12-22 18:52 UTC (3 days ago)
        
 (HTM) web link (etc.octavore.com)
 (TXT) w3m dump (etc.octavore.com)
        
       | ziml77 wrote:
       | Seems like a sensible way to archive branches. It's not like a
       | tag and branch are actually very different anyway, right? A tag
       | is a pointer that always refers to the same commit while a branch
       | is a pointer that follows commits forward. And for something
       | that's archived, you don't need the pointer updating mechanism.
        
         | progval wrote:
         | > A tag is a pointer that always refers to the same commit
         | 
         | It's not guaranteed not to change. The UI just makes it harder
         | to update.
        
           | QuantumNomad_ wrote:
           | And anyone whose coworkers replace tags on a regular basis
           | will be familiar with the following message from git when
           | pulling changes:
           | 
           | would clobber existing tag
           | 
           | Really wish my coworkers would leave old tags as they were
           | heh.
        
             | toenail wrote:
             | A hook should be able to prevent that
        
               | monkpit wrote:
               | Hooks only keep honest people honest :) and an LLM will
               | happily clobber a tag and skip hooks while the user just
               | spams "accept".
        
               | mroche wrote:
               | Luckily commonly used forges for collaboration have the
               | ability to make tags immutable. Any repository where
               | multiple people collaborate on a project should have that
               | feature enabled by default. I'm still waiting for the day
               | where tags are immutable by default with no option
               | exposed to change it.
               | 
               | I'm sure that would cause problems for some, but
               | transitive labels already exist in Git: branches.
        
       | PunchyHamster wrote:
       | How often did you go back to the archived tagches that are older
       | than say, 6 months ? Seems very niche, unless dunno, there are no
       | version tags in the repo.
        
         | yawaramin wrote:
         | True. At work our flow is to tag commits that we want to mark
         | as release candidates and delete feature branches after their
         | PRs are merged/declined. We've never had a need to archive
         | branches.
        
           | phire wrote:
           | It seems very useful for archiving branches that never got
           | merged.
           | 
           | Sometimes I work on a feature, and it doesn't quite work out
           | for some reason or another. The branch will probably never
           | get merged, but it's still useful for reference later when I
           | want to see what didn't work when taking a second attempt.
           | 
           | Currently, those abandoned branches have been polluting my
           | branch list. In the past I have cloned the repo a second time
           | just to "archive" them. Tags seem like a better idea.
        
             | dotancohen wrote:
             | I sometimes leave merged branches around for quite a while,
             | because I squash them when I merge to master and sometimes
             | when tracking down a bug the ability to bisect very handy.
        
               | matijsvzuijlen wrote:
               | What made you decide to squash when merging instead of
               | leaving the commits in the history so you can always
               | bisect?
        
             | skydhash wrote:
             | I don't think I've ever returned to a branch that I can
             | easily rebase on top of the main branch. And if I really
             | wanted to, I'd prefer to extract a patch so that I can copy
             | the interesting lines.
             | 
             | Any branch older than 6 months is a strong candidate for
             | deletion.
        
             | ervine wrote:
             | Wonder if it's worth squashing in the branch, merging to
             | main, then immediately reverting.
             | 
             | Now the work is visible in history, branch can be deleted,
             | and anyone in the future can search the ticket number or
             | whatever if your commit messages are useful.
             | 
             | Dunno if it's worth polluting history, just thinking out
             | loud.
        
           | fragmede wrote:
           | if you're deleting branches then why would you need to
           | archive them? What would you even archive if you're deleting
           | them? My deeper question is why are you deleting them in the
           | first place though?
        
       | tonymet wrote:
       | IMO a cleaner way to do this is with a headless remote, either on
       | disk or "backed up" on a server. `git push ---all` won't delete
       | refs on the remote, so you don't have to do any additional work
       | to record or recover them.
       | 
       | `git push --all backup` will record all of your refs and tags
       | 
       | If you are archiving branches in your own rep, prefix with `ar/`
       | so you can grep -v to conceal them.
       | 
       | See also `git notes` to record metadata an against a commit
       | without changing the commit
        
       | derriz wrote:
       | > Important note: the strange magic requires the official git
       | completion script.
       | 
       | I dislike the official git completion script because it's so slow
       | when working with large repos. On macOS - because of vagaries of
       | the way its file system works - with large repos it's effectively
       | unusable. Hint to completion script writers: if your "smart"
       | completion ever takes seconds, it's worse than useless and far
       | worse than "dumb" filename completion.
        
       ___________________________________________________________________
       (page generated 2025-12-25 23:00 UTC)