Archiving Git branches as tags

(etc.octavore.com)

93 points by octavore3 days ago

5 comments

AdieuToLogic1 hour ago
On a related note, git supports incorporating custom commands via executables available in the `PATH` having the naming convention of:<pre><code> git-<command name> </code></pre> Where "command name" in this case would be `archive-branch` and could be defined thusly:<pre><code> #!/bin/sh # git-archive-branch git_branch="${1:-$(git branch --show-current)}" git co main && git tag archive/$git_branch $git_branch && git branch -D $git_branch </code></pre> It then could be invoked the same as the alias:<pre><code> git archive-branch ...</code></pre>
ziml778 hours ago
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.
- progval8 hours ago
 > A tag is a pointer that always refers to the same commitIt's not guaranteed not to change. The UI just makes it harder to update.
 - QuantumNomad_7 hours ago
 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 tagReally wish my coworkers would leave old tags as they were heh.
 - toenail7 hours ago
 A hook should be able to prevent that
 - monkpit6 hours ago
 Hooks only keep honest people honest :) and an LLM will happily clobber a tag and skip hooks while the user just spams “accept”.
 mroche5 hours ago
 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.
 MadnessASAP5 hours ago
 I dont find the idea of a immutable "descriptive" tag or branch to be that useful (I also dont find the differentiation of tags and branches to be useful either) I've seen plenty of repositories where tags end up being pretty ambiguous compared to each other or where "release-20xx" does not actually point to the official 20xx release. Immutable references are more typically handled by builders and lockfiles to which Git already has a superior immutable reference system, the commit hash.
 Buttons8403 hours ago
 As long as we can create and delete tags, they will never be immutable, right?
 jaggederest1 hour ago
 Tags are just a text file with a name and the sha of the tag object (with the commit and some metadata/signatures as contents), last I checked. It's deliberately simple and thus almost impossible to actually lock it down in concrete terms.Packed refs are a little more complicated but all of the storage formats in git are trivial to manually edit or write a tool to handle, in extremis.
 Denvercoder94 hours ago
 That's true for local hooks, but neither a dishonest person nor an LLM can bypass a pre-receive hook on the server (as long as they don't have admin access).
- paulddraper5 hours ago
 Correct.One is refs/heads/<name> and the other is refs/tags/<name>Branches are expected to change. When a commit is authored, HEAD (the current branch) updates to that commit.Tags are expected not to change (though they can).
 - lucasoshiro3 hours ago
 Other difference (actually, more like a consequence of what you said) is that Git keeps reflogs for branches but not for tags
derriz6 hours ago
> 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.
PunchyHamster8 hours ago
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.
- yawaramin8 hours ago
 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.
 - phire7 hours ago
 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.
 - skydhash7 hours ago
 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.
 - dotancohen7 hours ago
 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.
 - matijsvzuijlen6 hours ago
 What made you decide to squash when merging instead of leaving the commits in the history so you can always bisect?
 quesera4 hours ago
 Not GP, but we do the same. Branches become the atomic unit of bisection in master, but the need is extremely rare. I think because we have good tests.We also keep merged branches around. This has never happened, but if we needed to bisect at the merged-branch level, we could do that.I know squash-merge isn't everyone's cup of tea, but I find it to be simpler and clearer for the 99+% case, and only slightly less convenient for the remainder.
 - ervine6 hours ago
 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.
 - fragmede7 hours ago
 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?
tonymet7 hours ago
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 tagsIf 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