--- Jakub Narebski <jnareb@xxxxxxxxx> wrote:
> Luben Tuikov wrote:
>
> >> It probably is wise to resurrect those "redundant" links.
> >
> > If someone does this, can they also remove the now "other"
> > redundant link? (the link at the pathname itself) A simple
> > code analyzer would show the duplicate code in gitweb.
>
> Easy, easy now.
Can you please CC me when replying to a post of mine? Else
I have to go chase in the git folder as opposed it coming to
my inbox. Thanks!
> I'd rather add some more "hidden" links, but for each hidden
> link (which are convenience only, to have larger are to click,
> or to have closer area to click) I'd like to have clearly marked
> link (marked as a link, i.e. using default link style; and with link text
> denoting _kind_ of link) which leads to the same contents.
Why would you like all this? If users start using those other links
all the time, what is the purpose of the "hidden" links as you call them?
Consider the "tree" link between "commitdiff" and "snapshot" (if enabled)
in shortlog view.
Consider the "hidden" link of each entry (file/directory).
Can you see how they are different?
Introducing this to an engineer who has little knowlege about git:
"Click on the file or directory name, to get the file or go into
the directory"
Simple and intuitive, no need to mention "blob" or "tree" or "object".
Or,
"Click on the 'blob' link to get the ... Click on the 'tree' link to
get the ... Oh you didn't know what a 'tree' or 'blob' object is?
A 'blob' is ... A 'tree' is ..."
At which point the engineer has lost 90% of his interest.
It even gets even worse for the obnoxious "tree" link next to each commit
in shortlog view:
"The tree link is the the tree object which is part of a commit object.
Oh you don't know the internals of a commit object? A commit object
binds a tree object and a (parent) commit object, but blah, blah, blah..."
Can you see how all this apparent "simplicity" you're trying to introduce
contradics the mere links you're introducing it with?
Surely "we can", but should we? The "tree" link in shortlog next to each commit
is one such example of "we can", but we shouldn't.
The question is: Given the average engineer, what is the gitweb interface
such that they can start using it fastest with the minimum amount of
questions?
> But we agreed (I guess) to disagree on the whole redundancy in user
> interface issue (although I agree on the issue of reducing clutter).
> BTW. we can reduce redundancy in the code without need for removing
> "alternate entry points" in interface, I think.
Clutter and redundancy is just a part of it. A larger part is
how much git or non-git oriented we want to make the interface, which
seems related to the overall simplicity and intuitiveness.
The golden question:
What is the interface such that both git-experts and never-seen-git-
but-know-about-SCMs engineers can find it intuitive to use with minimal
amount of questions?
Luben
-
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