Reputation: 15518
Let's say I make a commit and push it, then someone else pulls my commit, creates one or more tags on it, makes a few more commits and then pushes everything again.
How can I now fetch the new tags for the commit that I already have on my machine without fetching more commits (i.e. git pull
doesn't count)?
Edit:
My incentive is to save time and resources.
Basically whenever I push a new commit to GitLab, a chain of automated jobs is triggered within GitLab. The first one analyzes the commit message (which follows a certain convention) and then decides what kind of version bump would be appropriate, then it checks the version tag for the previous commit and creates a new one for the current commit with the appropriate version bump.
Then the next job is triggered. This job might be responsible for compiling the source code. Then another job is triggered which might be responsible for creating a source code archive.
Every job runs within its own temporary Docker container and all containers include a folder representing the repository at the time of pushing. So the newly created tag which is being created in the first job needs to be fetched at the beginning of job 2 and 3 (these jobs need to know the version number, e.g. to give the source code archive a proper name). It would be a waste of resources to do a full git fetch
every time. Especially when you make multiple commits within a very short period of time.
It is also possible to manually trigger the chain of jobs of an old commit. In that case you would potentially fetch thousands of commits that you don't need for job 2 and 3.
In reality there are actually more like 15 jobs, but I had to simplify things, otherwise I would have to write a book.
Upvotes: 1
Views: 471
Reputation: 45749
I'll offer a solution, but first please refer to my comment on the original question; in summary, I am extremely skeptical that this is a valuable endeavor.
To fetch, you have to be able to name what you want to fetch. IIRC this is considered a security measure of sorts, in that it prevents fetching a known hash if the actual refs have been force-pushed to remove that commit from history. So you have to name a tag or a branch, or just take everything reachable (more or less).
If step 1 creates, in addition to any calculated version tags, a single tag with a name known to steps 2 and 3, then you can fetch that tag with the --tags
option and get what you're asking for.
source-repo $ git tag v1.3.7
source-repo $ git tag -f current_build
source-repo $ cd path/to/target/repo
target-repo $ git fetch source-repo current_build
From url://of/source/repo
* tag current_build -> FETCH_HEAD
* [new tag] v1.3.7 -> v1.3.7
* [new tag] current_build -> current_build
Upvotes: 1
Reputation: 22027
Disclaimer : broken solution, answer preserved only for further investigations.
git fetch --tags <commitID>
will limit fetch
command's range to only this commit.
If you have a doubt, first launch a dry run and see what would have been done :
git fetch --dry-run --tags <commitID>
Upvotes: 0