On Wed, 30 Jul 2008, Roman Zippel wrote:
> >
> > The "gitk file" history is the simplest one BY FAR, because it has very
> > aggressively simplified history to the point where it tried to find the
> > _simplest_ history that explains the current contents of 'file'[*]
>
> It's "aggressively simplified" by not even bothering to look for more.
Yes and no.
It's aggressively simplified because that's the right output with the
minimal unnecessary irrelevant information. It explains how the file came
to a particular state, with the simplest possible self-consistent history.
(Again, the caveat about "simplest possible" always beign a local
minimization, not a global one).
The fact that it also obviously involved less work (so git can do it
faster, and with fewer disk and memory accesses) is a huge bonus, of
course.
Are you complaining about the fact that I'm smart, and I get the right
result I want with less work and with a simpler algorithm?
What's your point?
> "simplified" implies there is something more complex beforehand, but all
> it does is simple scan through the history as fast possible without
> bothering looking left or right.
You're just being stupid.
It's not that it's not "bothering" looking left or right. It very much
*does* bother to look left or right. But once it finds that one or the
other explains the situation entirely, it then says "screw left, I already
know that rigth gives me the information I want".
In other words, it's doing the _smart_ thing.
I don't understand why you complain about intelligence.
It's *not* just looking at one single history. Look at
gitk kernel/sched.c
and notice that the simplified history is not linear. It tries to make it
AS LINEAR AS POSSIBLE, BUT NO MORE.
"Make everything as simple as possible, but not simpler."
- Albert Einstein
You seem to complain about the fact that it's doing that. That's stupid of
you.
> "simplified" implies to me it's something intentional, but this is more of
> an accidental optimization which happens to work in most situations and in
> the special cases it just picks a random change and hopes for the best.
You're just crazy. There is nothing accidental there what-so-ever.
> "git-log --full-history file" at least produces the full change history,
> but it has an performance impact and it doesn't produce a complete graph
> usable for graphical front ends.
Umm. You have to add "--parents" if you want a full graph. Without that,
you can never re-generate the graph anyway.
And when you do that, it _does_ give all the commits needed to complete
the picture.
In other words, git (once again) is actually smarter than you, and does
the right thing, and (once again) you complain about something that you
just don't understand.
> I gave more general examples. Tracking upstream source can produce this
> problem frequently. Another example are stable/unstable branches where the
> stable branch is occasionally merged into the unstable branch can produce
> this problem.
You call it a "problem", but you don't actually give any reason for
calling it that. IT IS NOT A PROBLEM. It's very much by design, and it's
because what you want.
Use --full-history if you want the full history.
> This is your _subjective_ interpretion of this problem, because it's not a
> problem for you, nobody else can possibly have this problem (or they just
> crazy).
No, Roman. You're not crazy because you have some issue that I cannot
understand. You're crazy because you make the same mistake over and over,
and don't listen when people tell you what the mistake was.
"Insanity is doing the same thing over and over again and
expecting different results."
- Various
Please. People have told you where you go wrong. Many times. So why do you
keep repeating it?
Take the time to slow down, listen, and realize that you're on the wrong
track, and that others really _have_ spent time and thought on this.
Linus
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
