Parth Gala <parthpgala@xxxxxxxxx> writes: >>> | === 2015-09-04 === >>> | * 27ea6f85 10:46 jch (tag: v2.5.2) Git 2.5.2 >>> * 74b67638 10:36 jch (tag: v2.4.9) Git 2.4.9 >>> .......... >>> * ecad27cf 10:32 jch (tag: v2.3.9) Git 2.3.9 >>> >>> So these are the two main formats to be enhanced along with as many options >>> of log as possible. What are your views on this ? >>> >> Making the "--oneline" format to consume more than one line for a >> commit is probably not what we want anyway. > > For this format can we build a new option say `--time` or `--log-time`(duh!) Making such an option orthogonal to the base formats (i.e. "--decorate" is usable with "--pretty=short", "--pretty=fuller", "--oneline", etc.---note that this is not meant to be exhaustive) would be a good idea. I do not think of any reason why your "--group-by-same-date" cannot be combined with some of these formats. It is reasonable to combine it with "--format="%h %s", for that matter, because the "--group-by-same-date" is not about showing any particular commit but inserting something that does *not* belong to any particular commit in between. Just like "--graph" can be combined with many formats, showing group separators in between the stream of commits would mix well with any format, I would say. By using the idea Peff shown, before starting to emit one commit (in any format), you would show a single line of "== YYYY-MM-DD ==" if the commit is from a date different from the one that was shown last. It would naturally extend to "--group-by-same-month", etc., so you'd want to be prepared for such future. Your patch does *not* have to implement such variations like grouping by month, season or year. But a developer with a good taste would prepare the code in such a way that is easy to modify to extend the support for such variations by future developers. Also remember there are two timestamps, and depending on the use case, people want to see author dates or committer dates. Thanks.
