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?

Improve this question
3
  • 3
    Technically, annotated tags are an example of tagging a non-commit object, but I suppose that's not what you mean.
    – user743382
    Commented Mar 20, 2016 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
    Commented Mar 20, 2016 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
    Commented Feb 22, 2017 at 20:14

2 Answers 2

Reset to default
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.

Improve this answer
2
  • 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
    Commented Aug 5, 2017 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.
    – user743382
    Commented Aug 5, 2017 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

Improve this answer
3
  • 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
    Commented Mar 20, 2016 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
    Commented Mar 20, 2016 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
    Commented Mar 20, 2016 at 10:59

Not the answer you're looking for? Browse other questions tagged or ask your own question.