What's up with "*-git date" packages in the AUR?

In short: Just build the package and it will be the latest version from the Git repo; this is automatically handled by makepkg.

From reading the PKGBUILD files of -git packages (e.g. for adonthell-git), you can see:

cd $_gitname && git pull origin
msg "The local files are updated."

Thus, every time makepkg is run, it downloads the latest version from the Git repository.

The pkgver parameter is because makepkg requires a version number in the PKGBUILD and in the final package; a date is what makes the most sense here.

If it's detected that it's a package from Git, makepkg handles the special case accordingly:

(lines 1687-1771 of makepkg, function devel_check)

elif [[ -n ${_gitroot} && -n ${_gitname} ]] ; then
    if ! type -p git >/dev/null; then
            warning "$(gettext "Cannot find the %s binary required to determine latest %s revision.")" "git" "git"
            return 0
        fi
        msg "$(gettext "Determining latest %s revision...")" 'git'
        newpkgver=$(date +%Y%m%d)

[snipped lots of other cases for darcs, hg, svn etc...]

(lines 1773-1792 of makepkg, function devel_update)

# This is lame, but if we're wanting to use an updated pkgver for
# retrieving svn/cvs/etc sources, we'll update the PKGBUILD with
# the new pkgver and then re-source it. This is the most robust
# method for dealing with PKGBUILDs that use, e.g.:

hence you end up with a package with its version number being the date when you built it.

Using a Git date is just as valid as using any other form of version numbering.

As to how to get the newest version of a package/program, downloading from git and compiling yourself if probably the best way to get the "most recent" version of a package.

On the other hand, if you want an already-compiled version that has been at least marginally tested and found moderately stable, then I would recommend the package from the repository.