Linus Torvalds [off-list ref] writes:
On Sun, 12 Aug 2007, David Kastrup wrote:
quoted
quoted
But to visualize a history, it's useless.
Not half as useless as existing git-specific tools. They thrash my
computer to death on serious sized trees.
So, use "git log --pretty=oneline" instead, which doesn't have the
expense.
Yes, like managing a manual with grep is all one needs. git log
--pretty=oneline provides just the commit headers, but offers no way
to jump into the commits themselves and back easily.
I don't see why you think that using nntp would help anything. The
_problem_ is still the same one, of calculating full
reachability. It didn't go away just because you changed to another
intermediate protocol.
Newsreaders are designed _not_ to calculate full reachability. They
would be unusable otherwise. They have reasonable heuristics for
dealing with partial information and getting more only when needed.
Yes, you could perhaps use the nntp caching, but I don't know if
you've noticed: the reason news servers tend to expire old messages
is that a news reader and the NNTP protocol won't be able to handle
huge histories either.
It's actually more of a storage problem. A pretty normal general
newsspool with about 2 weeks of storage requires several gigabytes of
disk space already.
And if you just want the "expire" feature, then you might as well
just make git date-limit things for you, ie "gitk --since=last.week"
I actually don't want any "expire feature". Expiry happens at the
server, and git is quite efficient enough at "storing" the articles
that expiry appears pointless (unless one puts all of Sourceforge's
recent commit histories onto an NNTP spool, probably an interesting
experiment).
"Marked as read" could conceivably come handy for keeping on top of
large projects, but basically I'd already be suited fine with
ephemeral groups which look the same whenever I visit them again.
The thing with newsreaders is that it is easy to say "since last
week", and then just look at a few more earlier articles. This sort
of functionality has been honed and improved over decades. If I can
avoid starting fresh, with a new user interface and the same old
problems, that helps. Nobody wants tools that require to tell them
when you start them just how much information you'll ever want from
them.
That's the thing why pagers are so convenient with real pipes as
compared to temporary files: you can cut off the data generating
process when you decide you don't need more, and you don't need to
wait until the whole data is there.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
On Sun, 12 Aug 2007, David Kastrup wrote:
quoted
So, use "git log --pretty=oneline" instead, which doesn't have the
expense.
Yes, like managing a manual with grep is all one needs. git log
--pretty=oneline provides just the commit headers, but offers no way
to jump into the commits themselves and back easily.
You misunderstand.
I was suggesting you do a *tool* that bases its listing on
--pretty=oneline, and then goes from there.
If you don't show the graph anyway, all the complex and expensive things
that "git-rev-list --topo-order" does is pretty much totally useless.
You're going to show the commits as a list anyway, and then when you
*select* one commit for closer inspection, you can then try to do a better
job at that point of doing the reachability (ie parenthood is trivial, and
the branch reachability is cheap if it's close to the tip of the tree,
which it would almost always be).
The real problem with the topological sort is that it requires you to have
the full history. That not only makes everything pretty big, it also means
that the startup cost is bad, since you can't do things incrementally.
But if you have a client that is incremental anyway, almost all of that
goes away.
Linus
Since you all are talking about such things, I thought I would show
you a shot of my git UI. It does what I think Linus is talking about.
I have a window of x commits which I show in a list and allow the
user to look at each one. You can click on a commit to see full
details. There are back/next buttons to browse the entire history and
date/author/etc filters to narrow your results. The only thing I am
missing is the pretty chart that gitk and others have. The chart (in
my app) would only show the chart for the current window of commits.
I'll get to that sometime after work gives me enough time to start
working on this again.
Is this something like what you had in mind?
On 8/12/07, Linus Torvalds [off-list ref] wrote:
On Sun, 12 Aug 2007, David Kastrup wrote:
quoted
quoted
So, use "git log --pretty=oneline" instead, which doesn't have the
expense.
Yes, like managing a manual with grep is all one needs. git log
--pretty=oneline provides just the commit headers, but offers no way
to jump into the commits themselves and back easily.
You misunderstand.
I was suggesting you do a *tool* that bases its listing on
--pretty=oneline, and then goes from there.
If you don't show the graph anyway, all the complex and expensive things
that "git-rev-list --topo-order" does is pretty much totally useless.
You're going to show the commits as a list anyway, and then when you
*select* one commit for closer inspection, you can then try to do a better
job at that point of doing the reachability (ie parenthood is trivial, and
the branch reachability is cheap if it's close to the tip of the tree,
which it would almost always be).
The real problem with the topological sort is that it requires you to have
the full history. That not only makes everything pretty big, it also means
that the startup cost is bad, since you can't do things incrementally.
But if you have a client that is incremental anyway, almost all of that
goes away.
Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html