Will using a git tag instead of a branch update when tag moves?
Closed this issue · 9 comments
I've started tagging the latest tested commit on my master with a "stable" tag that I move forward.
I was thinking this was a midway between locking to a particular version (and having to update el-get recipe for every version) and simply following the master branch.
Will this work? In the sense that when the tag moves el-get will update the installation in the same way as it does when a branch is used.
Should I use :branch or :checkout for this? The documentation seems to indicate that only :checkoutcan use tags, but it also indicates that that will lock the repo to that revision. So I'm wondering what happens when the tag moves.
So I'm wondering what happens when the tag moves.
Git tags aren't expected to move, so I suspect it would fail to update (possibly not, though; I haven't tried).
Why not just make a "stable" branch instead of a tag? Git branches and tags are basically the same thing, apart from the git machinery which expects branches to be moveable.
Why not just make a "stable" branch instead of a tag?
Ok, I tried that and as I expected it was much harder for me to move a branch from the CI (Travis), possibly from my incomplete understanding of all intricacies of git (and possibly the Travis environment).
Of course this is not actually a topic for this repo, but what I tried was (when building on master)
git branch -f stable master
git checkout stable
git push <URL>
and git insists that I have upstream changes that must be fetched first (as i understand it, on the stable branch), but a git pull before the push says "already up-to-date".
I'll take this question elsewhere.
UPDATE: somehow my stable had actually gotten some extra commits so it was no longer just a reference to a commit on the master branch, that's why git wanted a fetch. Works now, thanks!
Git tags aren't expected to move, so I suspect it would fail to update (possibly not, though; I haven't tried).
I'll take that as a "undefined behaviour" answer.
Looking at what magit's P e (magit-push-current) does, I'm pretty you just need git push <URL> master:refs/heads/stable or git push -f <URL> master:refs/heads/stable if you want to ignore any extra commits.
So you mean that git push -f <URL> master:refs/heads/stable more or less is "ignore whatever stable was before, I really want it just to be pointing at whatever commit master is", in effect killing anything on the stable branch that might not have been on master and just setting it equal to master?
That would probably be exactly the semantics that I'm after, since any commit only on stable is in this scenario a mistake.
Thanks for the tip.
So you mean that git push -f master:refs/heads/stable more or less is "ignore whatever stable was before, I really want it just to be pointing at whatever commit master is", in effect killing anything on the stable branch that might not have been on master and just setting it equal to master?
Basically, yes. Note that it sets the stable branch at <URL> based on what the local master branch is.
NOTE to future readers: it should be refs/heads/stable (with an 's' in 'heads'). Without the s it creates a new branch ,-)
Maybe we should edit our comments.
Argh, that's what I get for not copying directly from the *magit-process buffer. Fixed above.
Yeah, the little things ...
Thanks for the help and the conversation!