BTW, if the tag is created against a commit that *doesn't* become "unreachable" from HEAD [1], then `git pull` is sufficient to also pull down the tags.
The only time I've needed to do `git fetch --tags` is when the tagged commit SHA gets merged away. So presumably the process being followed by the core committers / releasers is resulting in these "unreachable" tags. Not sure if that is preventable though. - Erik [1] http://eddiemoya.com/2013/02/21/better-git-git-fetch-not-getting-tags/ >From the git manual (“git help fetch”): [1] -t, –tags Most of the tags are fetched automatically as branch heads are downloaded, but tags that do not point at objects reachable from the branch heads that are being tracked will not be fetched by this mechanism. This flag lets all tags and their associated objects be downloaded. The default behavior for a remote may be specified with the remote.<name>.tagopt setting. See git-config(1). On Fri, Mar 18, 2016 at 6:22 PM, Michael Browning <invitapri...@gmail.com> wrote: > I agree with Kevin -- tags are immutable, so they're naturally suited > for labeling releases, which ought to be immutable too. > > On Fri, Mar 18, 2016 at 4:59 PM, Kevin Klues <klue...@gmail.com> wrote: > > I respectfully disagree. > > > > The whole purpose of tags is to mark permanent things like releases, > > whereas branches are designed as temporary lines of development that > > come and go (and grow and shrink) dynamically all the time. > > > > On Fri, Mar 18, 2016 at 4:04 PM, Jie Yu <yujie....@gmail.com> wrote: > >> I like the idea of using branches to manage releases. > >> > >> We can use that to manage point releases and backports as well. > >> > >> Say we want to cut 0.29.0 now, we fork a branch 0.29.0 and tag RCs in > that > >> branch. Once the RC is accepted, the head of that branch will become the > >> release. > >> > >> Then, we immediate fork that branch and create 0.29.1 branch. > >> > >> When a new bug fix is committed on the trunk, the committer will decide > >> whether it'll affect the old releases (a bounded number, we can decide > that > >> later). If it does, the committer of that patch should also cherry-pick > >> that patch to the point releases (e.g., 0.29.1 in this case). We can do > a > >> timely based point releases. > >> > >> - Jie > >> > >> On Fri, Mar 18, 2016 at 1:35 PM, Cong Wang <cw...@twopensource.com> > wrote: > >> > >>> On Wed, Mar 16, 2016 at 11:56 AM, Joseph Wu <jos...@mesosphere.io> > wrote: > >>> > Cong Wang, > >>> > > >>> > The tags are sync'd. See: https://github.com/apache/mesos/releases > >>> > > >>> > You might not have done: git pull --tags > >>> > >>> > >>> Yeah, I figured it out by myself too. This is why I hate tags > personally, > >>> branches are better since they are fetched without additional > parameters. > >>> > >>> Any reason why Mesos maintainers picked tags over branches to manage > >>> releases? Just curious... > >>> > > > > > > > > -- > > ~Kevin >
