On 05/18/2017 04:55 PM, Rüdiger Meier wrote: > > > On 05/18/2017 09:56 PM, Karel Zak wrote: >> On Thu, May 18, 2017 at 02:08:49PM -0400, J William Piggott wrote: >>> On 05/18/2017 06:36 AM, Karel Zak wrote: >>> >>> 8< --- >>> >>>> >>>> The important thing on rcN is that we have official tarball, so you >>>> >>>> can use it independently on git, add to distros etc. >>>> >>> >>> 8< --- >>> >>> Karel, I pull from github and haven't seen a new tag since v2.29. >>> Perhaps I should be pulling from kernel.org, but github should work, >>> no? > > I think "git pull" does not always give you all the tags. In doubt I > do explicitly "git fetch --tag remote-name". Maybe "git pull" only > pulls tags if remote-name == origin, I still don't got the full logic. Using 'git pull' against master fetched the tags up through v2.29. Then it stopped. git-pull(1): By default, tags that point at objects that are downloaded from the remote repository are fetched and stored locally. If a tag is created from the master branch, then (with the default configuration) pulling the master branch will pull the tag as well. I think perhaps Karel changed his bugfix release workflow and started creating them from a working branch. I say that because the v2.30-ReleaseNotes file never hit my local repo, the master branch, until May 16th. That is why I submitted my patch for it as a simple diff instead of a git format-patch. It seems to me that the working branch should be merged into master first, and then create the tag, tarball, etc. from master. That way pulling master will fetch the release tags. That should be expected behavior. IMO, creating releases from an ephemeral branch, or anything other than master, is asking for headaches. >> I push to the both repos in the same time >> $ git push; git push github master; git push --tags; git push github --tags I think it would be better to: git push --follow-tags; git push --follow-tags github master This would be a good crosscheck to know that the release tags were created against master and not some other branch. Also, one day you may want to have some private tags and --tags will push everything. Whereas, --follow-tags will only push tags associated with what is being pushed, that is, the master branch. 8< --- >> >>> Isn't the KNOWN BUGS: referring to the v2.13.1 branch as a typo, not >>> the tag? >> >> $ git tag -l | grep v2.13.1 v2.13.1 v2.13.1-REAL >> >> v2.13.1-rc1 >> >> v2.13.1-rc2 >> >> v2.13.1.1 >> >> the first line is unwanted tag... it would be possible to delete it, >> but I don't think that remove already published tags is a good idea. I see, but isn't the v2.13.1 branch a 'bug' also, because there are not any bugfix release branches? Well like you said, it's old and doesn't matter much now. > > It should not be a problem to delete tags like it's no problem to > delete branches. Only rebasing branches or re-creating conflicting > tags could be annoying or at least confusing. > > > cu, Rudi > > > >> >> Karel >> > -- To unsubscribe from this list: send the line "unsubscribe > util-linux" in > > the body of a message to majordomo@xxxxxxxxxxxxxxx > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- To unsubscribe from this list: send the line "unsubscribe util-linux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
