* gitk drawing bug
@ 2015-02-18 19:27 Martin d'Anjou
2015-04-03 23:05 ` Alex Henrie
0 siblings, 1 reply; 4+ messages in thread
From: Martin d'Anjou @ 2015-02-18 19:27 UTC (permalink / raw)
To: git
Hi,
It appears I have uncovered inconsistent behaviour in gitk. Looks like
a bug. I have a picture here:
https://docs.google.com/document/d/19TTzGD94B9EEIrVU5mRMjfJFvF5Ar3MlPblRJfP5OdQ/edit?usp=sharing
Essentially, when I hit shift-F5, it sometimes draw the history
differently (still valid, but drawn differently). There is no change
in the repository between the shift-F5 keystrokes.
Thanks,
Martin
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: gitk drawing bug
2015-02-18 19:27 gitk drawing bug Martin d'Anjou
@ 2015-04-03 23:05 ` Alex Henrie
2015-04-04 1:28 ` Martin d'Anjou
0 siblings, 1 reply; 4+ messages in thread
From: Alex Henrie @ 2015-04-03 23:05 UTC (permalink / raw)
To: Martin d'Anjou; +Cc: Paul Mackerras, Git mailing list
2015-02-18 12:27 GMT-07:00 Martin d'Anjou <martin.danjou14@gmail.com>:
> It appears I have uncovered inconsistent behaviour in gitk. Looks like
> a bug. I have a picture here:
> https://docs.google.com/document/d/19TTzGD94B9EEIrVU5mRMjfJFvF5Ar3MlPblRJfP5OdQ/edit?usp=sharing
>
> Essentially, when I hit shift-F5, it sometimes draw the history
> differently (still valid, but drawn differently). There is no change
> in the repository between the shift-F5 keystrokes.
Did you ever contact the gitk maintainer, Paul Mackerras
<paulus@samba.org>, about this bug?
-Alex
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: gitk drawing bug
2015-04-03 23:05 ` Alex Henrie
@ 2015-04-04 1:28 ` Martin d'Anjou
2015-04-06 3:11 ` Paul Mackerras
0 siblings, 1 reply; 4+ messages in thread
From: Martin d'Anjou @ 2015-04-04 1:28 UTC (permalink / raw)
To: Alex Henrie; +Cc: Paul Mackerras, Git mailing list
On 15-04-03 07:05 PM, Alex Henrie wrote:
> 2015-02-18 12:27 GMT-07:00 Martin d'Anjou <martin.danjou14@gmail.com>:
>> It appears I have uncovered inconsistent behaviour in gitk. Looks like
>> a bug. I have a picture here:
>> https://docs.google.com/document/d/19TTzGD94B9EEIrVU5mRMjfJFvF5Ar3MlPblRJfP5OdQ/edit?usp=sharing
>>
>> Essentially, when I hit shift-F5, it sometimes draw the history
>> differently (still valid, but drawn differently). There is no change
>> in the repository between the shift-F5 keystrokes.
> Did you ever contact the gitk maintainer, Paul Mackerras
> <paulus@samba.org>, about this bug?
>
> -Alex
I do not remember contacting Paul Mackerras, but thank you for doing so.
Martin
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: gitk drawing bug
2015-04-04 1:28 ` Martin d'Anjou
@ 2015-04-06 3:11 ` Paul Mackerras
0 siblings, 0 replies; 4+ messages in thread
From: Paul Mackerras @ 2015-04-06 3:11 UTC (permalink / raw)
To: Martin d'Anjou; +Cc: Alex Henrie, Git mailing list
On Fri, Apr 03, 2015 at 09:28:00PM -0400, Martin d'Anjou wrote:
> On 15-04-03 07:05 PM, Alex Henrie wrote:
> >2015-02-18 12:27 GMT-07:00 Martin d'Anjou <martin.danjou14@gmail.com>:
> >>It appears I have uncovered inconsistent behaviour in gitk. Looks like
> >>a bug. I have a picture here:
> >>https://docs.google.com/document/d/19TTzGD94B9EEIrVU5mRMjfJFvF5Ar3MlPblRJfP5OdQ/edit?usp=sharing
> >>
> >>Essentially, when I hit shift-F5, it sometimes draw the history
> >>differently (still valid, but drawn differently). There is no change
> >>in the repository between the shift-F5 keystrokes.
That's not a bug, it's a consequence of the fact that gitk is designed
to be fast. It only lays out as much of the graph is visible plus a
little more, not the whole graph, and it doesn't use any global
analysis. The reason for that is speed. Gitk is usable on a
repository with half a million commits, such as the linux kernel, and
to achieve that we can't afford to do wait until we have all the
commits read in and then do some computation over the whole topology;
it all has to be done incrementally. Also, the underlying git log
sometimes gives gitk a parent commit before one of its children, and
when that happens the topology has to be modified and thus the graph
does too, if any topology that has already been drawn gets modified.
As long as the graph correctly shows the relationships between
commits, it has achieved its purpose. If you (or anyone) can come up
with improvements that make it look nicer, that's great, and I'll
consider them as long as they don't slow down gitk on large
repositories to any noticeable extent.
Paul.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2015-04-06 3:22 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-02-18 19:27 gitk drawing bug Martin d'Anjou
2015-04-03 23:05 ` Alex Henrie
2015-04-04 1:28 ` Martin d'Anjou
2015-04-06 3:11 ` Paul Mackerras
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).