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 14 hours ago | parent | next [-]

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 14 hours ago | parent | next [-]

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.

▲

skydhash 13 hours ago | parent | next [-]

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.

▲

dotancohen 13 hours ago | parent | prev | next [-]

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 12 hours ago | parent [-]

What made you decide to squash when merging instead of leaving the commits in the history so you can always bisect?

	▲	quesera 10 hours ago \| parent \| next [-]
		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.
	▲	dotancohen 3 hours ago \| parent \| prev [-]
		The range reason your history textbook is not infinitely long. The longer something is, the less digestible. When we need more granularity, it's there in the branches.

▲

ervine 12 hours ago | parent | prev [-]

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 13 hours ago | parent | prev [-]

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?

▲

venturecruelty 4 hours ago | parent | prev [-]

Believe it or not, some people need to use software more than six months old.