Alessandro Di Marco wrote: > this is a hack I made a couple of years ago in order to store my current > location in git commits (I travel a lot and being able to associate a > place with the commit date helps me to quickly recover what were doing > at that time). Long story short, the screeenshot at > http://tinypic.com/r/wars40/5 shows the new gitk interface once this > patch has been integrated. Geolocation is controlled by two envvars > GIT_AUTHOR_PLACE and COMMITTER_PLACE, respectively. You can set them via > something like this:
Obviously very interesting. Now, how do we mainline (parts of) this feature? I'll raise some questions here: 0. We already have timezone information, but this is obviously insufficient for any sensible geolocation data. 1. Does it make sense to make it an optional field in the commit object? I can see how generic optional fields in the commit object can be useful: a lot of code-review systems put the code-review ID in the commit message, and I can see how an optional field would benefit them. Will it break existing parsers (shouldn't they ignore unknown fields)? 2. How accurate should this geolocation information for it to be invariant enough? If we blindly store what a GPS gives us, the centering error is obviously a problem. What should be the resolution of the lat/long that we store? 3. Failing (2), can we put the geolocation data in the commit message, and proceed? If so, does it need to be part of git-core, or should an external client (gitk, or other clients) write/ parse the geolocation information? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
