Antoine Pelisse <apelisse@xxxxxxxxx> writes: > I'm really not convinced this kind of changes should make it into > Junio's tree (of course, he's the only one to decide). I really > believe this is a very specific solution to a very specific problem > (that is not for me to judge if the problem is real). Bloating the > commit object with this kind of information doesn't feel like a good > idea. > > I think it could be nice to provide a simple shell script to build the > location, callable from a post-commit hook, to construct a > "geolocation" note. Gitk could be programmed to read the notes to get > the location, but once again, I'm not sure it should be mainlined. I would personally find the "feature" cute, but - I think a note is an overkill for that; and - I also think that adding cruft to commit object header in a backward incompatible way, with the only possible escape-hatch being "if you want to keep being compatible with other people, you can choose not to use this feature", is a slipperly slope to fragmentation we do not want to go nearby. Wouldn't it be sufficient to treat this in a similar way as references to tracker entries and references to other commit objects in the text of the commit message body are treated by gitk and friends? Just embed the information in the log text somewhere and teach the UI how they look like and what to do with them. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html