| Message ID | 20240407051031.6018-1-leduyquang753@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add lines to `git log --graph` to separate connected regions | expand |
On Sun, Apr 7, 2024 at 1:10 AM Lê Duy Quang <leduyquang753@gmail.com> wrote: > `git log --graph`, when invoked with multiple starting revisions and some > exclusions which cut the commit graph, may give a disconnected graph. In other > words, the resulting graph has more than one separate connected regions. The > command currently prints the connected regions on top of each other without any > separation. > > This leads to a problem. Say there are two connected regions, each having two > commits, the graph would look like this: > > * a2 > * a1 > * b2 > * b1 > > which may lead to a misunderstanding that these four commits belong to the same > timeline, i.e. b2 is a parent of a1. > > This patchset adds a separator line between each pair of connected regions to > clarify that they are not actually connected: > > * a2 > * a1 > --- > * b2 > * b1 This sort of information which explains why the patch may be desirable is not only helpful to reviewers of the submission, but will be helpful to future readers of the patch once it becomes part of the project's permanent history (assuming it is accepted). However, the cover letter does not become part of the project's history (it exists only in the mailing list). As such, please move this discussion into the commit message of the patch itself.
Eric Sunshine <sunshine@sunshineco.com> writes: >> This leads to a problem. Say there are two connected regions, each having two >> commits, the graph would look like this: >> >> * a2 >> * a1 >> * b2 >> * b1 >> >> which may lead to a misunderstanding that these four commits belong to the same >> timeline, i.e. b2 is a parent of a1. >> >> This patchset adds a separator line between each pair of connected regions to >> clarify that they are not actually connected: >> >> * a2 >> * a1 >> --- >> * b2 >> * b1 > > This sort of information which explains why the patch may be desirable > is not only helpful to reviewers of the submission, but will be > helpful to future readers of the patch once it becomes part of the > project's permanent history (assuming it is accepted). However, the > cover letter does not become part of the project's history (it exists > only in the mailing list). As such, please move this discussion into > the commit message of the patch itself. True. But because we are doing graph, shouldn't we be able to do better? For example, you can draw the two lineage of histories on different columns and ... * a2 * a1 * b2 * b1 ... that way, you do not need to lose one line of precious vertical screen real estate.
On Sun, Apr 7, 2024 at 12:37 PM Junio C Hamano <gitster@pobox.com> wrote: > True. But because we are doing graph, shouldn't we be able to do > better? For example, you can draw the two lineage of histories > on different columns and ... > > * a2 > * a1 > * b2 > * b1 > > ... that way, you do not need to lose one line of precious vertical > screen real estate. I think horizontal screen real estate is even more precious than the vertical one, since one usually doesn't scroll their terminal horizontally. And then it would probably be a way more complicated implementation.
Hello Quang, On 2024-04-07 08:40, Quang Lê Duy wrote: > On Sun, Apr 7, 2024 at 12:37 PM Junio C Hamano <gitster@pobox.com> > wrote: >> True. But because we are doing graph, shouldn't we be able to do >> better? For example, you can draw the two lineage of histories >> on different columns and ... >> >> * a2 >> * a1 >> * b2 >> * b1 >> >> ... that way, you do not need to lose one line of precious vertical >> screen real estate. > > I think horizontal screen real estate is even more precious than the > vertical > one, since one usually doesn't scroll their terminal horizontally. And > then it > would probably be a way more complicated implementation. These days, very few computer screens aren't in widescreen format, so there's inevitably less vertical screen space available than the horizontal space.
On Sun, Apr 7, 2024 at 3:34 PM Dragan Simic <dsimic@manjaro.org> wrote: > These days, very few computer screens aren't in widescreen format, > so there's inevitably less vertical screen space available than the > horizontal space. The ability to scroll makes all the diffence though, there is quite a chance any non-trivial commit log is going to span more than one screen height already anyway. There's no risk in sprinkling a few more lines into it; meanwhile if the number of columns actually gets too many, in many cases you will not have a horizontal scrollbar to play with. But it depends on how this idea will be expanded, as it has been only an initial hint from the original reply.
On 2024-04-07 10:46, Quang Lê Duy wrote: > On Sun, Apr 7, 2024 at 3:34 PM Dragan Simic <dsimic@manjaro.org> wrote: >> These days, very few computer screens aren't in widescreen format, >> so there's inevitably less vertical screen space available than the >> horizontal space. > > The ability to scroll makes all the diffence though, there is quite a > chance any > non-trivial commit log is going to span more than one screen height > already > anyway. There's no risk in sprinkling a few more lines into it; > meanwhile if the > number of columns actually gets too many, in many cases you will not > have a > horizontal scrollbar to play with. > > But it depends on how this idea will be expanded, as it has been only > an initial > hint from the original reply. Please note that less(1), which is commonly used as the pager, also supports horizontal scrolling. Perhaps that isn't a very well known feature of less(1), but it is supported.
Junio C Hamano <gitster@pobox.com> writes: > True. But because we are doing graph, shouldn't we be able to do > better? For example, you can draw the two lineage of histories > on different columns and ... > > * a2 > * a1 > * b2 > * b1 > > ... that way, you do not need to lose one line of precious vertical > screen real estate. Just to save others time to go spelunking in the list archive, "solutions" attempted and did not work in the past include (1) wasting a line to insert a "gap" in the output. (2) using marker different from '*' to mark each commit. If taking the latter approach, it needs to designed to work well with "boundary" and "left-right" options (the design to shift column would not have to worry about these, which is another plus). Thanks.