GIT TAG OLD COMMIT UPDATE

Hook the two together with git remote add, and push your brand new clean repository to the branch new clean remote. Also throw your remote away and make a fresh remote. Then say git init and start all over with a fresh commit. Īnd that's why the simplest way to do what you want to do is just to checkout the state of things that you like, which is presumably main, and then just throw the entire. For every remote-tracking branch, you'd need to say git push -delete origin. You'd need to delete all those remote branches too! But you can't just delete them you have to push the deletion.

Plus, you'd need to say git tag -list to find out what tags you have, and delete each of those tags.īut even that wouldn't be enough, because what about all the remote-tracking branches you have? To see those, you'd say git branch -remote.

So, to do it correctly the way you did it, you would need to say git branch to find out what branches you have, and delete each of those branches. git folder didn't get significantly smaller after what you did. So what you did probably didn't cause any commits to die!Īnd that would explain why your. So that origin/main is keeping all your commits alive, all the way back to the root commit. So in addition to your main, you've also got an origin/main. So you also have remote-tracking branches that mirror the state of that remote. So let me ask you this: was main the only branch you had? Because if it wasn't, then all those other branch names still exist, and they are keeping all their parents alive all the way back to the root commit. You deleted main, in the hopes that this would cause all existing commits to die. Okay, so now let's talk about what you did. In other words, imagine a chain of commit parentage well, a commit can only die if no chain of commit parentage starting with a branch or tag name reaches it. If that's how a commit can't die, how can a commit die? Well, for a commit to die, it would have to be the case that no branch or tag name points to a commit that calls this commit its parent at any depth. If commit is the parent of a commit that is alive, it cannot die. If a commit has a name - that is, a branch name or tag name points to it - it cannot die. So is a tag name.Įvery commit has at least one 'parent' - except for the very first commit you ever made (the 'root' commit) and any 'orphan' commits that you may create. Here's what you need to know:Ī branch is merely a name for one commit. To understand that, you need to know how commits can't die. To discover the answer, let's talk about how commits die. Why didn't the thing I did reduce the size of the.

GIT TAG OLD COMMIT UPDATE

The Update Major Version action looks for a semantic version when you push a tag, and it automatically moves the matching major version ahead.I take it that the real questions here are: If you’d like to automatically maintain a latest tag in your repo that always points to the latest release you could use the Latest tag action. This way the users of the action will automatically use the latest available release of a major version next time they run their workflows. When a new release is made it can be tagged with a semantic version such as v1.4.3, and the major tag v1 can then be moved ahead to point to the same commit. When you want to use a certain version of an action you define it with the repo and a reference, for example reference can be a branch, commit, or a tag, but tags are commonly used for this purpose. Git tags highlight important milestones in a projects development history. Users can create custom actions that are distributed via Git repositories. One case where this practice is used is GitHub’s own continuous integration platform, GitHub Actions. Moving tags around can cause all sorts of problems but in some cases you may just need to go with it. Why would you want to move a tag in the first place? All tags on the remote will now be available on your local repository.

Git tag old commit