7

I understand how it is possible to tag a blob, or a tree, or even another annotated tag, using a git tag. I understand the architecture and conceptual design that makes this possible.

However, I'm having trouble thinking of real life applications of this (or "real workflow" applications).

Searching here on Stack Overflow I only found one answer that mentions tagging non-commit objects, with advice not to do so.

Under what possible circumstances could it ever be appropriate to tag a non-commit object?

Community
  • 1
  • 1
Wildcard
  • 1,302
  • 2
  • 20
  • 42
  • 3
    Technically, annotated tags *are* an example of tagging a non-commit object, but I suppose that's not what you mean. –  Mar 20 '16 at 10:45
  • @hvd, I actually didn't realize that; thanks for pointing it out! In any case that still resolves ultimately to a commit, so my question still stands. – Wildcard Mar 20 '16 at 10:57
  • 2
    This is not standard practice, but it seems reasonable enough to share a few small assets this way (out-of-band, if you will), which don't necessarily belong in the worktree itself. For the official git repo, the maintainer's public ssh key is tagged in such a manner; the tag is the only way to access it, since it's not in the tree of any commit. – jpaugh Feb 22 '17 at 20:14

2 Answers2

6

Tagging trees or blobs may be appropriate temporarily in long-running utility programs that manipulate objects directly. Tagging would ensure that git gc can be safely run in parallel. The utility program would then remove the tags when it's done, when it's created a commit.

  • This should be rather unnecessary. git gc looks at the timestamp on objects to ensure that it's not removing new ones. And if it didn't, you can see that there's still a race here: the gc could run during a period of time after you've created an object but before you've tagged it. – Edward Thomson Aug 05 '17 at 13:30
  • 2
    @EdwardThomson I did write "long-running". You can interpret it as e.g. "waiting for input from a user who left for a month-long vacation" if you like. –  Aug 05 '17 at 13:58
0

Are there any use cases where it would be appropriate to tag a non-commit object?

As you figured out. In a nutshell you should avoid non-commit tagging.

Lets say for example that you have fixed a code (hot fix) and its part of a bigger commit

Why?
since it was committed like this and only later you figured out that you need only a single file.
Now you want to mark the file (content) of this change without marking all the other content.

Sample 2:
You are going over the code trying to figure out which file caused a bug, to mark a single commit you can use a tag or a git note but to mark a single file you will use tag.

And there can some other examples as well.

The Linux kernel repository also has a non-commit-pointing tag object – the first tag created points to the initial tree of the import of the source code

JBert
  • 3,311
  • 24
  • 37
CodeWizard
  • 128,036
  • 21
  • 144
  • 167
  • The Linux kernel example is good since it's a real example, but I don't see why they couldn't just make an initial commit and tag that. Wouldn't the effect be the same? Ultimately a commit is just a pointer to a tree, anyway, and (usually) to other commits as well. – Wildcard Mar 20 '16 at 10:53
  • I agree, this is why you should try to avoid it, Still you have the **option** to do it. You can also have the option to drive in red light (and as we know some do) but it a case of misused this feature. – CodeWizard Mar 20 '16 at 10:58
  • Lets say that you have worked on some code which cause a bug, then you commited a fix with some other files as well. now you want o grab only the fix (single file) from the commit tree. you can do it by tagging the desired content by itself. – CodeWizard Mar 20 '16 at 10:59