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.
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
> 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.
Branches are expected to change, tags are not. Tags are also mildly harder to change. A tag seems more apt for an archived branch. So I sort of see where OP comes from.
Because in git tooling (be it github.com or a tui/gui client like lazygit), git branches are shown more prominently because the expectation is that a branch is something you actively work on (if you're finished with a branch, you delete it).
If 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.
How would this argument change if git branch recognized the "archive/" convention, or had some other mechanism, such that archived branches are concealed from view unless -a/--all is given?
I like the idea that branch names starting with . (period) are considered hidden, similarly to files in Unix.
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.
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.
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.
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?
Readit News
It's not guaranteed not to change. The UI just makes it harder to update.
would clobber existing tag
Really wish my coworkers would leave old tags as they were heh.
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).
`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.
How about just
If 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.
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.