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
> 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

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
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to