Sync on tag addition?

[whophil]

This seems not to sync if a new tag has been added, but the ref being watched hasn't changed. With the existing options, is there any way to force this to occur? Essentially, I would like to do the equivalent of git fetch --tags every period.

[thockin]

V4 is designed to watch a single ref (tag or branch), so it doesn't really care if there's a new tag. This is somewhat different than v3. Can you say more about how you want to use it?

[whophil]

Thanks for the quick reply @thockin! I essentially want to keep one branch of a local repository up to date with the branch from a remote, including tags. The issue, I suppose, is that tags are pushed to the branch after the commits are pushed.

I'm happy to use v3 if there is a way to make it do this.

[thockin]

If you could sync the branch, with tags, would that work? I will have to try to make that work.

On Thu, Nov 9, 2023, 8:14 PM Phil Chiu @.***> wrote:

Thanks for the quick reply @thockin https://github.com/thockin! I essentially want to keep one branch of a local repository up to date with the branch from a remote, including tags. The issue, I suppose, is that tags are pushed to the branch after the commits are pushed.

I'm happy to use v3 if there is a way to make it do this.

— Reply to this email directly, view it on GitHub https://github.com/kubernetes/git-sync/issues/842#issuecomment-1804970319, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABKWAVARSB266Q6PKOVW43LYDWEZLAVCNFSM6AAAAAA7FPDXS2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMBUHE3TAMZRHE . You are receiving this because you were mentioned.Message ID: @.***>

[whophil]

@thockin - I think it depends on the implementation. For my use case, I need the tags to be updated even if the ref of the branch has not changed. I understand this might be an edge case, so I appreciate you thinking about it!

[thockin]

oh...yeah, I don't know if that will work even on v3. git-sync tries to sync a given ref, but it's not a full mirror.

Can you tell me more about the use-case? What's going on that tags are being added to old commits? Do you want to mirror the full repo (including branches on the remote) or just tags that are present on a given branch? Or something else I am missing?

What are you doing with these tags?

[thockin]

Som notes for myself, just from playing:

This fetches a single tag: git fetch --no-tags https://github.com/kubernetes/git-sync tag <tag>

We could maybe fetch all reachable tags with something like:

git ls-remote https://github.com/kubernetes/git-sync refs/tags/\* | while read H T; do
    git show $H >/dev/null 2>&1 \
        && echo "I HAVE $T" \
        && git fetch --no-tags https://github.com/kubernetes/git-sync $T:$T
done;

That's pretty brute-force to run every loop

[whophil]

Can you tell me more about the use-case? What's going on that tags are being added to old commits? Do you want to mirror the full repo (including branches on the remote) or just tags that are present on a given branch? Or something else I am missing?

What are you doing with these tags?

Sorry @thockin , I missed this message somehow! We push tags with a given pattern to trigger actions downstream (e.g., a package build/deploy). We also have another application which serves some content from the repo and needs to maintain its own local copy of the repo, including tags.

[thockin]

And these tags are such that syncing one branch with tags would be enough? Or is it across multiple branches? How does the consumer find these tags -periodic polling and pattern matching or something?

[thockin]

I'm staring at this trying to rationalize how to do what you're describing and still be part of the same tool. git-sync is all about syncing and publishing one specific ref (tag/branch) and when that ref changes upstream, resyncing and republishing the new form.

What you want is to sync is some pattern of refs (plural) and publishing.... I'm not quite sure what you want to publish?

Maybe something like git-sync --repo=... --extra-ref=refs/tags/* which would ALSO pull anything that resolves the extra refs, but still publish the usual ref?

You can sort of fake it like:

$ rm -rf /tmp/gs; mkdir -p /tmp/gs/repo; mkdir -p /tmp/gs/wt; cd /tmp/gs/repo

$ REPO=https://github.com/kubernetes/git-sync

$ REF=HEAD

$ git init
Initialized empty Git repository in /tmp/gs/repo/.git/

$ refs=($(git ls-remote $REPO refs/tags/v4.* | awk '{print $2":"$2}'))

$ git fetch --no-tags --depth 1 $REPO $REF "${refs[@]}"
remote: Enumerating objects: 937, done.
remote: Counting objects: 100% (937/937), done.
remote: Compressing objects: 100% (691/691), done.
remote: Total 937 (delta 285), reused 498 (delta 192), pack-reused 0
Receiving objects: 100% (937/937), 1.76 MiB | 7.67 MiB/s, done.
Resolving deltas: 100% (285/285), done.
From https://github.com/kubernetes/git-sync
 * branch            HEAD       -> FETCH_HEAD
 * [new tag]         v4.0.0     -> v4.0.0
 * [new tag]         v4.0.0-rc1 -> v4.0.0-rc1
 * [new tag]         v4.0.0-rc2 -> v4.0.0-rc2
 * [new tag]         v4.0.0-rc3 -> v4.0.0-rc3
 * [new tag]         v4.0.0-rc4 -> v4.0.0-rc4
 * [new tag]         v4.0.0-rc5 -> v4.0.0-rc5
 * [new tag]         v4.1.0     -> v4.1.0

$ git worktree add /tmp/gs/wt/HEAD FETCH_HEAD
Preparing worktree (detached HEAD 9e1d0c5)
HEAD is now at 9e1d0c5 Document the change in default target

$ git -C /tmp/gs/wt/HEAD tag
v4.0.0
v4.0.0-rc1
v4.0.0-rc2
v4.0.0-rc3
v4.0.0-rc4
v4.0.0-rc5
v4.1.0

This would still require some surgery inside git-sync...does it get even close to what you were thinking?

[whophil]

I really appreciate the thought you've put into this @thockin!

I had wishfully hoped that my use case would somehow be possible without modification to git-sync. It seems like it is not, but that is no problem - no need to bend this application around my odd use case.

I've written my own simple script which does do what I need, copying some of the principles from git-sync.

I'm happy to close this issue, as I don't think anybody else is asking for this feature. Again, I appreciate your time!

[thockin]

Well, exploring this helped me see a simplification of the inner loop, so it's not all bad. That simplification makes this sort of change even easier, so I will still explore it in my "free time"