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.
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.
Any branch older than 6 months is a strong candidate for deletion.
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.
It just moves trash from branch list to tag list.
`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
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.
git-<command name>
Where "command name" in this case would be `archive-branch` and could be defined thusly: #!/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
It then could be invoked the same as the alias: git archive-branch ...How about just
# rename branch to archive/ prefix to indicate it is archived
git branch -m foo-branch archive/foo-branchIf you don't anticipate working on a branch but you want to preserve the code you leave it but it starts to clutter that prominent "active" space in most git tools.
This allows you to preserve the code (if you ever want to look at it again) while also de-cluttering the prominent "branches" view.
I like the idea that branch names starting with . (period) are considered hidden, similarly to files in Unix.
ziml77•1mo ago
progval•1mo ago
It's not guaranteed not to change. The UI just makes it harder to update.
QuantumNomad_•1mo ago
would clobber existing tag
Really wish my coworkers would leave old tags as they were heh.
toenail•1mo ago
monkpit•1mo ago
mroche•1mo ago
I'm sure that would cause problems for some, but transitive labels already exist in Git: branches.
MadnessASAP•1mo ago
mroche•1mo ago
Buttons840•1mo ago
mroche•1mo ago
Of course, the repository owner has unlimited privilege here, hence the last part of my prior comment.
jaggederest•1mo ago
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.
mroche•1mo ago
https://docs.github.com/en/repositories/configuring-branches...
https://docs.gitlab.com/user/project/protected_tags/
https://forgejo.org/docs/latest/user/protection/#protected-t...
Denvercoder9•1mo ago
toenail•1mo ago
venturecruelty•1mo ago
az09mugen•1mo ago
paulddraper•1mo ago
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).
lucasoshiro•1mo ago