Git tag for a subfolder of a repository

I use Git to import a SVN repository. Then I created my own project as a subfolder in the repository.

I use the SVN repository with Git-SVN. My working procedure is:

  • Homebrew: insufficient permission for adding an object to repository database .git/objects
  • Git pushes entire project even if few files are changed. AWS
  • How to git svn clone full history despite svn copy
  • Merging two completely different repositories
  • Display latest tag in a commit with multiple tags
  • Automatically ignore selected code changes when pushing to a git-hub repository
    1. git commit -am "message"
    2. git svn rebase
    3. git svn dcommit.

    Now I want to tag my project with git tag -a RC1 -m 'Release Candidate 1', but I only want that my project gets the tag.

    How can I do that?

  • Merge back deleted file from a branch to master
  • How to create a patch with git-extensions
  • Cloud9 IDE git setup
  • Benefits of Git vs TFS
  • How to right align something in Powershell prompt?
  • What are git's thin packs?
  • 4 Solutions collect form web for “Git tag for a subfolder of a repository”

    TL;DR version

    It’s possible to tag specific directories (aka trees) if you know the tree’s SHA-1, but it’s not often done & not easy to do useful things with that tag.

    Long answer

    Every object in Git has a unique SHA-1. Most commonly, SHA-1s refer to commits, but they can also refer to blobs (file contents) and trees (directory structures & filenames/file-permission mappings). You can read about it in the Git Objects documentation.

    For example, suppose I’m in a particular directory in my repository. I can run git ls-tree HEAD to get the list of files/directories in my path, along with their SHA-1s:

    $git ls-tree HEAD
    100644 blob ed76d466f5025ce88575770b07a65c49b281ca59    app.css
    100644 blob ed58ee4a9be6f5b58e25e5b025b25e6d04549767    app.js
    100644 blob e2bed82bd9554fdd89d982b37a8e0659fe82390a    controllers.js
    040000 tree f888c44e16f7811ba69a245adf35c4303cb0d4e7    data
    100644 blob d68aa862e4746fc9abd0132cc576a4df266b0a9d    directives.js
    100644 blob df0ae0e7288617552b373d21f7796adb8fb0d1b6    index.html
    040000 tree fa9c05b1bb45fb85821c7b1c27925b2618d646ac    partials
    100644 blob 28e9eb6fe697cb5039d1cb093742e90b739ad6af    services.js

    I can then tag one of these trees (let’s say the data directory above):

    $git tag data-1.0 f888c44e16f7811ba69a245adf35c4303cb0d4e7

    The tag is now an alias for that SHA-1 and I can use it wherever a SHA-1 for a tree is accepted:

    $git ls-tree -rt data-1.0
    100644 blob 6ab0a52a17d14cbc8e30c4bf8d060c4ff58ff971    file1.json
    100644 blob e097e393fa72007b0c328d67b70ba1c571854db0    file2.json
    040000 tree 39573c56941fdd2fc88747a96bf871550f4affb2    subfolder1
    ...    ...  ...                                         ...

    To get back the original SHA-1:

    $git rev-parse data-1.0

    What good will all this do you? Not much as-is. However, if you’re willing to write your own scripts to reconstruct the contents of a tree, or to find the commits containing a tree, then it might be useful to you. (e.g. this SO answer could be adapted for such a purpose).

    But like others have said, you’ll probably have an easier time using a versioning/tagging model that’s works better with Git, rather than trying to adapt your existing model. As already mentioned by shikjohari & others, if you want projects-within-a-project, which have their own versions, consider Git Submodules instead.

    You cannot.

    In Git, a tag by design always applies to the repository as a whole (just like commits and branches). This is unlike in Subversion, where a tag (being just a copy) can be applied to a subtree.

    BTW: Tagging a subtree is usually discouraged even in Subversion, because it can quickly become confusing just which part of the tree was tagged. Most sources I know (for example Version Control with Subversion recommend to always tag by copying trunk.

    About your problem:

    Usually, separate projects should get separate Git repositories. “Seperate” in this context usually means that you might want to branch / tag separately.

    If you do not / cannot do that, the best option is probably to use some tag prefix, and call all tags myproj-1.0, myproj-1.1 etc.

    This isn’t possible with Git. A Git tag is a pointer to a specific commit, whereas a Subversion tag is a copy of any folder in the Subversion repository. The concept of tagging a single folder in Subversion doesn’t carry over very well into Git.

    The problem is that your initial setup doesn’t match Git’s branching model. The way to do this in a Git-friendly manner would be to have a branch set up for your project, and then to tag commits on that branch.

    You’ve a couple of options:

    • Tag the entire repository at a given point using git svn tag. Run git help svn for instructions on using this command.

    • Tag the directory using regular Subversion commands. This doesn’t need to involve downloading a Subversion working copy, since you can just run svn copy {URL to your project on the repository} {URL to your tag directory}, but you will need to install Subversion.

    • Start a new Git clone of your Subversion repository in a whole new directory. Specify your project folder as the trunk URL, rather than the actual trunk. Git-svn will then treat that directory as your main branch and allow you to tag and copy it through Subversion.

    I found myself in the similiar problem when I had to move a very large project to Git. I found that the team did not handle the SVN properly and did the taggings from wherever they wanted to. So there were tags for individual projects and folders – which is highly discouraged.

    If you are planning to move to Git, you should keep it as how things work in Git and keep it clean. I would suggest to create seperate repositories of frequently changing projects. Also you can make use of submodules if you find your project dependent on other projects.

    Git Baby is a git and github fan, let's start git clone.