(all we did here was shove the chain up a bit for master, and add a new branch label, newbranch, pointing to the same commit as the tag v2.5.2). Start by getting yourself a branch name pointing to the original commit: before: Let's start with this: Just make the new commit as usual, on a branch as usual. If you want to make a new commit that's like the old commit but with a few things changed, you have some options. So just call it "X.1" and be done with it. Others have already seen one tag-name, and if you keep the same name, you may be in the situation that two people both have "version X", but they actually have different "X"'s. Just admit you screwed up, and use a different name. In that case you can do one of two things: And you’re done.īut if you have pushed things out (or others could just read your repository directly), then others will have already seen the old tag. If you never pushed anything out, just re-tag it. What should you do when you tag a wrong commit and you would want to re-tag?
#Git tag old commit install#
What if you remove the old name-to-ID mapping for the tag, and install this new, different name-to-ID mapping? That's called "re-tagging", and Linus Torvalds has advice for the re-tagger, right in the git tag documentation: Git normally only adds new objects to the repository existing objects stay unchanged forever, and objects are hardly ever deleted (we'll see more on this in a bit).Īll that said-that you cannot edit files in an existing commit-you can make a new and different commit*, and then make a name for it.
The tree object, and its ID, changes if you change the source, and that means that a new commit, one that uses the new-and-different tree object, is different from the old commit.īecause the ID is a cryptographic checksum of the contents, no Git object can ever change. It's actually the tree line (which refers to a Git "tree" object) that lets the commit record a snapshot of the source. L10n: de.po: fix translation of autostash I find it instructive to view an actual commit: $ git cat-file -p origin/master | sed /'
#Git tag old commit plus#
The contents of any commit depend on all the files in that commit, plus all the history leading up to that commit. If you change even one single bit in anything you have Git store, you get a new, different hash ID. This is in fact true for all Git objects: hashes are SHA-1 checksums of contents. The raw hash ID of a commit is a cryptographic checksum of the contents of that commit. The difference between a tag name and a branch name is that a tag is supposed to stay the same forever, and a branch is supposed to move, in a "forward one step" fashion as you make commits-Git does this for you automatically-or sometimes in a big "fast forward over many commits" fashion (as when you pick up new updates from elsewhere). well, who can remember 7c5b208-aw-the-heck-with-it, and how will we ever compare that to v2.5.2? I know: the computer can remember this for us! Let's have the computer remember the hash ID, and call that a "tag". The main reason to use a tag (such as v2.2.1) instead of the hash ID is. The command git rev-parse turns names (such as branch and tag names) into these hash IDs: $ git rev-parse origin/master (It may be a name for an "annotated tag object" that in turn names a commit, but this ultimately amounts to the same thing.)Įach commit-really, each Git object-is uniquely identified by its hash ID. The reason is simple enough, although it comes in two parts:Ī tag is just a name for a commit.
There is something you can do (below the line), but what you are asking for is literally impossible.
0 kommentar(er)
