threads / rfc / 53044

[GSoC Project RFC] "git log --oneline" improvements

Subject: [GSoC Project RFC] "git log --oneline" improvements

## tl;dr

4 messages between Mar 20, 2020 and Mar 21, 2020.

replies: 3people: 2as markdown or json

Parth Gala· Mar 20, 2020, 23:11 UTC · lore
Hey everyone,

I am Parth Gala. I am second year major in Electronics and Communications Engineering at Dwarkadas J. Sanghvi College of Engineering. I am interested in participating for GSoC 2020 under the Git organisation.

First of all I would like to apologise for sending in my participation so late. I lost 2 crucial weeks of discussion from the end of Feb due to some personal problems. I was initially interested in working on the rewrite of submodule from shell to C, but after checking the mailing list I saw that Shourya Shukla had already taken it up and had started work on it, so I felt it wise to leave it to him. So all the reading that I did for submodules had to be repeated for this project.

I went through the discussions here[1] and here[2] and what I could conclude from [1] is, the 'git log --oneline' command currently shows the decorations of a commit before the commit message but after the shortened hash due to which the alignment of the messages is disturbed like this,

     3f07dac29 (HEAD -> master) pathspec: don't error out on 
all-exclusionary pathspec patterns
     ca4a562f2 pathspec magic: add '^' as alias for '!'
     02555c1b2 ls-remote: add "--diff" option to show only refs that differ
     6e3a7b339 (tag: v2.12.0-rc0, origin/master, origin/HEAD) Git 2.12-rc0
     fafca0f72 Merge branch 'cw/log-updates-for-all-refs-really'
     74dee5cfa Merge branch 'pl/complete-diff-submodule-diff'
     36acf4123 Merge branch 'rs/object-id'

And if the decorations were to be shown after the message and you were checking the logs just to see the status of a branch rather than the contents then you would again be at a disadvantage, since you would want to have them visible right next to the hashes. Besides decorations at the end would have the inconvenience of being truncated at the end of the line on smaller screens.

This format for --oneline with decorations was decided upon,
   b9df16a4c (HEAD -> master)
             pathspec: don't error out on all-exclusionary pathspec patterns
   91a491f05 pathspec magic: add '^' as alias for '!'
   c8e05fd6d ls-remote: add "--diff" option to show only refs that differ
   20769079d (tag: v2.12.0-rc2, origin/master, origin/HEAD)
             Git 2.12-rc2
   076c05393 Hopefully the final batch of mini-topics before the final

In [2] such formats with date and timestamp are discussed along with compatibility for --graph option as well,

   === 2015-09-17 ===
   * ee6ad5f4 12:16 jch (tag: v2.5.3) Git 2.5.3
     === 2015-09-09 ===
   * b9d66899 14:22 js  am --skip/--abort: merge HEAD/ORIG_HEAD tree 
into index
   |   === 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 ?

Also, I had submitted a patch series here[3] but I felt it was trivial so took upon a bug fix[4] which is yet to be sent to the mailing list for discussions.

I am currently drafting my proposal which I will send for discussion after having received comments here.

Thanks :-),
Parth.

[1] : https://lore.kernel.org/git/xmqqeg42fslw.fsf@gitster.mtv.corp.google.com/T/#t [2] : https://lore.kernel.org/git/CA+55aFwT2HUBzZO8Gpt9tHoJtdRxv9oe3TDoSH5jcEOixRNBXg@mail.gmail.com/T/#t [3] : https://public-inbox.org/git/pull.545.git.1581535151.gitgitgadget@gmail.com/#t [4] : https://github.com/gitgitgadget/git/pull/582

Junio C Hamano· Mar 20, 2020, 23:36 UTC · re: Parth Gala · lore

Re: [GSoC Project RFC] "git log --oneline" improvements

Parth Gala <parthpgala@gmail.com> writes:
Show 29 quoted lines
> I went through the discussions here[1] and here[2] and what I could
> conclude from [1] is, the 'git log --oneline' command currently shows the
> decorations of a commit before the commit message but after the shortened
> hash due to which the alignment of the messages is disturbed like this,
>
>     3f07dac29 (HEAD -> master) pathspec: don't error out on all-excl...
>     ca4a562f2 pathspec magic: add '^' as alias for '!'
>     02555c1b2 ls-remote: add "--diff" option to show only refs that differ
>     6e3a7b339 (tag: v2.12.0-rc0, origin/master, origin/HEAD) Git 2.12-rc0
>     fafca0f72 Merge branch 'cw/log-updates-for-all-refs-really'
>     74dee5cfa Merge branch 'pl/complete-diff-submodule-diff'
>     36acf4123 Merge branch 'rs/object-id'
>
> And if the decorations were to be shown after the message and you were
> checking the logs just to see the status of a branch rather than the
> contents then you would again be at a disadvantage, since you would want
> to have them visible right next to the hashes. Besides decorations at the
> end would have the inconvenience of being truncated at the end of the line
> on smaller screens.
>
> This format for --oneline with decorations was decided upon,
>
>   b9df16a4c (HEAD -> master)
>             pathspec: don't error out on all-exclusionary pathspec patterns
>   91a491f05 pathspec magic: add '^' as alias for '!'
>   c8e05fd6d ls-remote: add "--diff" option to show only refs that differ
>   20769079d (tag: v2.12.0-rc2, origin/master, origin/HEAD)
>             Git 2.12-rc2
>   076c05393 Hopefully the final batch of mini-topics before the final

Hmph. Who decided that such a format is a good idea? I do not see anything decided positively in the thread [1] you referred to.

Show 17 quoted lines
> In [2] such formats with date and timestamp are discussed along with
> compatibility for --graph option as well,
>
>   === 2015-09-17 ===
>   * ee6ad5f4 12:16 jch (tag: v2.5.3) Git 2.5.3
>     === 2015-09-09 ===
>   * b9d66899 14:22 js  am --skip/--abort: merge HEAD/ORIG_HEAD tree
> into index
>   |   === 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.

Coming up with a new format (say, "--pretty=concise"), or a new option that tweaks the behaviour of "--oneline", are possible ways to add a new feature without disrupting existing users' use cases, though.

Thanks.
Parth Gala· Mar 21, 2020, 22:05 UTC · re: Junio C Hamano · lore

Re: [GSoC Project RFC] "git log --oneline" improvements

Show 33 quoted lines
> Parth Gala <parthpgala@gmail.com> writes:
>
>> I went through the discussions here[1] and here[2] and what I could
>> conclude from [1] is, the 'git log --oneline' command currently shows the
>> decorations of a commit before the commit message but after the shortened
>> hash due to which the alignment of the messages is disturbed like this,
>>
>>      3f07dac29 (HEAD -> master) pathspec: don't error out on all-excl...
>>      ca4a562f2 pathspec magic: add '^' as alias for '!'
>>      02555c1b2 ls-remote: add "--diff" option to show only refs that differ
>>      6e3a7b339 (tag: v2.12.0-rc0, origin/master, origin/HEAD) Git 2.12-rc0
>>      fafca0f72 Merge branch 'cw/log-updates-for-all-refs-really'
>>      74dee5cfa Merge branch 'pl/complete-diff-submodule-diff'
>>      36acf4123 Merge branch 'rs/object-id'
>>
>> And if the decorations were to be shown after the message and you were
>> checking the logs just to see the status of a branch rather than the
>> contents then you would again be at a disadvantage, since you would want
>> to have them visible right next to the hashes. Besides decorations at the
>> end would have the inconvenience of being truncated at the end of the line
>> on smaller screens.
>>
>> This format for --oneline with decorations was decided upon,
>>
>>    b9df16a4c (HEAD -> master)
>>              pathspec: don't error out on all-exclusionary pathspec patterns
>>    91a491f05 pathspec magic: add '^' as alias for '!'
>>    c8e05fd6d ls-remote: add "--diff" option to show only refs that differ
>>    20769079d (tag: v2.12.0-rc2, origin/master, origin/HEAD)
>>              Git 2.12-rc2
>>    076c05393 Hopefully the final batch of mini-topics before the final
> Hmph.  Who decided that such a format is a good idea?  I do not see
> anything decided positively in the thread [1] you referred to.

Okay, right. But this format does overcome the problems discussed in that thread. And yes, if `--oneline` is preferred to consume no more than one line, then as you mentioned below, a `--pretty=concise` format seems to be a good idea here.

Show 19 quoted lines
>> In [2] such formats with date and timestamp are discussed along with
>> compatibility for --graph option as well,
>>
>>    === 2015-09-17 ===
>>    * ee6ad5f4 12:16 jch (tag: v2.5.3) Git 2.5.3
>>      === 2015-09-09 ===
>>    * b9d66899 14:22 js  am --skip/--abort: merge HEAD/ORIG_HEAD tree
>> into index
>>    |   === 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!) which is compatible only when the other options don't include --notes, --pretty or --format(in which case `--log-time` option gets ignored). Here I will have to probably build upon Jeff's work to include the other options that the script supports too.

Show 7 quoted lines
> Coming up with a new format (say, "--pretty=concise"), or a new
> option that tweaks the behaviour of "--oneline", are possible ways
> to add a new feature without disrupting existing users' use cases,
> though.
>
> Thanks.
>
Junio C Hamano· Mar 21, 2020, 22:37 UTC · re: Parth Gala · lore

Re: [GSoC Project RFC] "git log --oneline" improvements

Parth Gala <parthpgala@gmail.com> writes:
Show 13 quoted lines
>>>    |   === 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.

← back to recent threads