On Fri, Oct 10, 2014 at 04:46:31AM +1030, Ron wrote: > On Thu, Oct 09, 2014 at 09:17:41AM -0700, Jason Gerecke wrote: > > On Thu, Oct 9, 2014 at 6:41 AM, Ron <r...@debian.org> wrote: > > > > > > Hi, > > > > > > The SF downloads appear to be showing a 0.26.1 release tarball, > > > but I'm not seeing a version bump commit, or tag in the SF git > > > repo. Did someone just forget to push, or did the primary git > > > tree move again while I wasn't looking ;? > > > > > > [last chance for non-critical updates for Debian Jessie is about > > > a week or two away now, a snapshot with the recent clang fixes > > > should migrate to testing today, but I just noticed there is > > > supposedly an actually released version of that now too ...] > > > > > > Cheers, > > > Ron > > > > > The release should be tagged on Sourceforge as > > 'xf86-input-wacom-0.26.1'. We normally release from the 'master' > > branch, but as this was an unscheduled bugfix we cherry-picked the > > change to a branch directly off of 0.26.0 (avoiding having it include > > other non-fix changes that were already on master). > > hmm, something odd is going on then, since I can see that tag and > the cherry picked commit here: > > http://sourceforge.net/p/linuxwacom/xf86-input-wacom/ci/9c83d997ccdba38fd02d5bf163f10cdc4f000a9b/log/ > > and if I do a fresh clone of the repo I see it too. > > But fetching it normally as an update to my existing repo doesn't > seem to work at all. > > > It's not pulled by: git fetch sf > (but I am correctly up to date on master with 8f856 as its head) > > An explicit: git fetch sf xf86-input-wacom-0.26.1 > did pull the extra commits, but it still thinks the tag doesn't > exist by that name (git tag -l doesn't show it). I can look at > them by hash ref though and see 9c83d9. > > > If I checkout that ref, then switch back to the master branch > again, git reports: > > $ git checkout master > Warning: you are leaving 2 commits behind, not connected to > any of your branches: > > 9c83d99 wacom 0.26.1 > 1f9f17b Strengthen condition that pad may never be arbitrated pointer > control > > If you want to keep them by creating a new branch, this may be a good time > to do so with: > > git branch new_branch_name 9c83d99 > > > And I likewise see: > > $ git fsck > dangling tag c50b55fcf0a2faf61ddbdbbfef3371051e65c30c > > Where c50b55 does appear to be the signed tag for 0.26.1 > > > It appears that I can 'fix' it locally by creating a temporary branch > at 9c83d9, doing another "git fetch sf", which then pulls the tag name, > and then force deleting that temporary branch name again ... > After that git fsck seems to think everything is fine now. > > Which sounds like we've possibly tickled a git bug by not leaving that > as a named branch and only pinning it with the tag :) > > I'm on git 2.1.1 right now.
hmm. git fetch --tags, might have also worked. It may have just not pulled that because it wasn't actually a part of the history of any of the branches that existed in my repo ... (being an offshoot from one without a branch of its own) In which case it's documented behaviour we fell foul of rather than a bug as such :) ------------------------------------------------------------------------------ Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk _______________________________________________ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
