Nono, I don't think you fully understand git's versioning. To oversimplify: git's history is composed of commits and parental relationships between them. Nothing more, nothing less; it is just a directed acyclic graph. On top of this graph structure you have additional stuff like branches, which are just labels atteched to the commits, and also tags, which are also just labels. So when you tag a commit, it doesn't really matter what branch it was on, you've simply said that tag 1.0 points to a particular commit XXXXXX in the history; that commit could belong to master branch, or development branch, or any other branch (or no named branch at all, also known as detached head). In another words, your tag points to a commit only, and branches do not play any role in this whatsoever. Am I being clear? (I'm sipping my morning coffee so my brain is not fully operational yet ;) ) Peter On Sun, Jul 30, 2017 at 05:28:44PM +0200, Tim Mackinnon wrote:
Peter - I meant it as a figurative example - on a master branch you can tag whenever you want right? And so you can point users to a specific tag on master so they have a stable point to load from (possibly while you merge a branch back to master and then update any documentation or config before retagging and updating a BaselineOf?
This looks like what the AWS Smalltalk git repo has used as an example.
Tim
(Ps Apologies for the "rage" iOS autocorrect - apparently that's what Apple thinks tags is corrected to ;)
Sent from my iPhone
Sent from my iPhone On 30 Jul 2017, at 16:35, Peter Uhnak <i.uhnak@gmail.com> wrote:
If I've understood correctly, this means you can rage master with a version number like v1.1 and then put that in the URL
I am not sure where you got this url from, but combining branch and tag name makes nor sense... that's like you wanted a version 1.1 AND 2.3 (or whatever would be the latest in master).
(as mentioned in the syntax: branch name OR commit id OR tag id)
Peter