--- Junio C Hamano <junkio@xxxxxxx> wrote: > Having said that, I agree to the point you are trying to make > here. It was a mistake to remove blob/tree links from the view > that lists pathnames. > > If we did not have any obviously clickable links on the right > hand side it might have been a different story, but when given > UNIXy permission bits, pathname and blame/history/raw links, > nobody would think of clicking on the pathname itself to grab > its contents. The blame link would give you the same I've seen the exact opposite. BTW, what is our standard here? People with zero-computer exposure? With some? With high? Certainly, if I didn't know what a folder/directory/tree is, and what a file is and I was told to "get" that file, the first thing I'd do when I see it on the screen would be to "put my pointer over the file and press the action button". It is when people actually start to "think" is when they fail to naively click on the pathname (name of the file) to get it. The naive approach is to simply click on what you want to get. The interesting point here is that people with zero and high computer exposure tend to click on the file name to obtain it. Only people with some computer exposure start to "think" and "figure it out" and fail to intuit to naively point at the file name to get the file. So this is 2/3 to 1/3. > information (and a bit more) and people would just go there > without much thinking. > > 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. 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