11–20 of 49 posts
Earlier quoted context omitted.
> A tag is a pointer that always refers to the same commit It's not guaranteed not to change. The UI just makes it harder to update.
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 tag Really wish my coworkers would leave old tags as they were heh.
`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.
Earlier quoted context omitted.
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 tag Really wish my coworkers would leave old tags as they were heh.
A hook should be able to prevent that
Earlier quoted context omitted.
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 seco…
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.
Earlier quoted context omitted.
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 seco…
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.
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”.
I'm sure that would cause problems for some, but transitive labels already exist in Git: branches.
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.
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).
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.
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”.