With move to git need to replace subversion keywords with tag identifying informaton

[ekluzek]

Remove $RevisionID$ fill version, which I think comes in from cime, with top level name of checkout. Note, this makes it only useful if you have checked out a frozen tagname. Current identifying information includes:

```
:history = "created on 10/17/17 03:48:34" ;
	:username = "rgknox" ;
	:host = "cheyenne" ;
	:version = "unknown" ;
	:source = "Community Land Model CLM4.0" ;
	:revision_id = "$Id: restFileMod.F90 41292 2012-10-26 13:51:45Z erik $" ;
	:case_title = "UNSET" ;
	:case_id = "iclm45fates-finit-s1.4.0-a3.0.0-f45" ;

Remove "revision_id" completely. Fill in version with the checkout name at the top level.

A secondary thing would be to add an identifier that notes if the checkout is clean or dirty. You could also add something that notes if there are SourceMods or not.

[bandre-ucar]

The hash id's are the absolutely unique identifier in git, since both tags and branches can move.

So I guess I'd propose that clm's build namelist infrastructure query git and record the hash and tag/branch if available. It can also query the clean/dirty status.

I don't know how source mods would be included in this info, since they are explicitly removed from version control and only available in a case. This would be a separate bit of information that would have to come from cime and the build?

Some other issues that come to mind:

• Should we also query and save URL of the remote the branch is associated with? The changeset may not be present in or ever pushed back to the main repo.

• Should this information be read in via namelist, or compiled into the code? Does cime have a way to dynamically regenerate fortran modules before every compilation?

• Do you distinguish between the top level checkout being cesm or standalone clm? Should clm just query it's own src directory, or go all the way back up to the root?

• Does clm want the state of all externals? rtm, mosart, cam, pop, etc? If so, what form will that info be stored in the metadata?

[bandre-ucar]

@billsacks Thoughts?

[billsacks]

The hash id's are the absolutely unique identifier in git, since both tags and branches can move.

So I guess I'd propose that clm's build namelist infrastructure query git and record the hash and tag/branch if available. It can also query the clean/dirty status.

Yes, I like this idea.

I don't know how source mods would be included in this info, since they are explicitly removed from version control and only available in a case. This would be a separate bit of information that would have to come from cime and the build?

This sounds messy. Maybe worth trying to figure out at some point, but I'd say skip it for the initial version.

Some other issues that come to mind:

• Should we also query and save URL of the remote the branch is associated with? The changeset may not be present in or ever pushed back to the main repo.

Good point, although this could get messy. If you're on a remote-tracking branch this is straightforward. But what if you're on a tag (or otherwise in detached head state)? It seems like that will be common. You could do something like git branch -r --contains SHA and then get the URL from one (or maybe better, all) of the remotes that have one or more branches containing this SHA. However, even that would break down if the current sha is contained in a tag on a given remote but not in any branches. It's possible that git for-each-ref would help here; I'm not sure (https://stackoverflow.com/questions/24993772/how-to-find-all-refs-that-contain-a-commit-in-their-history-in-git). (This might be kind of slow to query, though, and thus could be annoying to do all the time....) Maybe it would be sufficient to go with the dumb approach of listing the URLs of all remotes present in the repo???

• Should this information be read in via namelist, or compiled into the code? Does cime have a way to dynamically regenerate fortran modules before every compilation?

I'd vote for having it read in via namelist because I don't like auto-generating code unless it's really needed.

• Do you distinguish between the top level checkout being cesm or standalone clm? Should clm just query it's own src directory, or go all the way back up to the root?

I'd say that we want to query this git information from $SRCROOT. For a standalone checkout, this would give you a SHA in the CTSM repo; for a CESM checkout, it would give you a SHA in the CESM repo. This makes having the URL more important.

• Does clm want the state of all externals? rtm, mosart, cam, pop, etc? If so, what form will that info be stored in the metadata?

If you're in a clean state (with properly run checkout_externals), then this wouldn't be necessary, I think, given the above suggestions: the SHA of the root is enough to recreate the full state. Regarding recording the dirty state, I'd say that could come as a later enhancement.

[ekluzek]

This is in place now so closing.