Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Archiving Git branches as tags

etc.octavore.com

Post reply on HN
Print view View original

21–30 of 49 posts

Re: Archiving Git branches as tags

#21

Post by quesera »

matijsvzuijlen wrote: post #15
dotancohen wrote: post #9

Earlier quoted context omitted.

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.

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

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.

Re: Archiving Git branches as tags

#22

Post by Buttons840 »

mroche wrote: post #17
monkpit wrote: post #14

Earlier quoted context omitted.

Hooks only keep honest people honest :) and an LLM will happily clobber a tag and skip hooks while the user just spams “accept”.

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.

As long as we can create and delete tags, they will never be immutable, right?

Re: Archiving Git branches as tags

#23

Post by lucasoshiro »

paulddraper wrote: post #18
ziml77 wrote: post #2

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.

Correct. One is refs/heads/ and the other is refs/tags/ 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).

Other difference (actually, more like a consequence of what you said) is that Git keeps reflogs for branches but not for tags

Re: Archiving Git branches as tags

#24

Post by jaggederest »

mroche wrote: post #17
monkpit wrote: post #14

Earlier quoted context omitted.

Hooks only keep honest people honest :) and an LLM will happily clobber a tag and skip hooks while the user just spams “accept”.

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.

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.

Re: Archiving Git branches as tags

#25

Post by AdieuToLogic »

On a related note, git supports incorporating custom commands via executables available in the `PATH` having the naming convention of:

  git-
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 ...

Re: Archiving Git branches as tags

#26

Post by mroche »

Buttons840 wrote: post #22
mroche wrote: post #17

Earlier quoted context omitted.

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.

As long as we can create and delete tags, they will never be immutable, right?

The purpose of the forge is to be able to prevent this. Protected tags are usually a feature which provides a way to mark tags as untouchable, so removal would require a minimum level of trust to the repository on the platform. Otherwise, attempts to push tag deletions or changes for tags matching the protected pattern would be rejected/ignored.

Of course, the repository owner has unlimited privilege here, hence the last part of my prior comment.

Re: Archiving Git branches as tags

#27

Post by mroche »

MadnessASAP wrote: post #19
mroche wrote: post #17

Earlier quoted context omitted.

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.

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…

I 100% agree on the latter (the tag != release is more of a project management issue), and the same concept applies to containers and their digest hashes. The main issue at the end of the day is the human one: most people don't like looking at hashes, nor do they provide context of progression. I would say "give both" and make sure they match on the end user side of things, but tags are the most common way (open source) software releases are denoted.

Re: Archiving Git branches as tags

#28

Post by mroche »

jaggederest wrote: post #24
mroche wrote: post #17

Earlier quoted context omitted.

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.

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.

That's the purpose of the forge platform, to provide a way to prevent changes to these files from being accept into the source repository. For example:

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...

Re: Archiving Git branches as tags

#29

Post by venturecruelty »

monkpit wrote: post #14
toenail wrote: post #11

Earlier quoted context omitted.

A hook should be able to prevent that

Hooks only keep honest people honest :) and an LLM will happily clobber a tag and skip hooks while the user just spams “accept”.

Can't solve culture problems with technology, but we all know that by now, right?
Post reply on HN