--- Junio C Hamano <junkio@xxxxxxx> wrote: > Before answering 3 questions, I think we need to ask a bigger > question. What is the primary target audience of gitweb? > > If it is for git-uninitiated, then staying as close to what GNU > diff would give would be a better idea. I would say we at least > can assume that the user has some familiarity with SCM, and > knows what kind of information is kept track of and is shown as > differences between versions, and what files, directories and > symlinks are, but not how git represents these. On the other > hand, if the user uses git to track a project (not necessarily > the project the user is looking at with gitweb) and is familiar > with the way git-diff presents these information, deviating from > git-diff output is distractiing. I agree. gitweb's primary audience is the developers who type "git ..." at shell prompt all the time. > At least to me /-rw-rw-... part made me feel uneasy for that > reason. It made me feel uneasy to see it where it was because it didn't belong there either way. > WIth that in mind, I'll think aloud what I would like if I were > not familiar with git: > > * "diff --git a/file b/file" would not use /dev/null but > ---/+++ does. If the former is shown as link, it should be > visible which side is a link and which side is not for > creation or deletion diff; otherwise you would need a second I'd argue otherwise: trying to click on /dev/null and failing but succeeding on b/file has already taught something to the uinitiated user. OTOH, if one is trying to "click" on /dev/null in gitweb commitdiff view -- they have other problems to resolve first... > to realize it is not a bug that clicking on a/file on the > "diff --git" line did not show anything for a creation diff. > > * I think showing object names in "index xxx..yyy mode" line is > not very useful to humans (they are added for tools). I do I like to see it because I might need to know the sha in order to go back to shell prompt and do something with the object. Instead of having to git-ls-tree -r .... in order to find it from the sha of the commitdiff. > agree that we would want some clickable handle in combined > diff output, but people not familiar with git would not know > that "index xxx,yyy..zzz" is where you would find the > parents, so that line needs to be munged anyway. I think gitweb should first and foremost cater to git users. > Side note: Even though some git people (Luben, for example) > claim they recognize some abbreviated object names, I suspect > that are mostly recent commits and not blobs. Yes, commit-8 for the day, blob-8 for less than a minute which allows me to move the mouse pointer from to the xterm. > * Mode on the "index" line may be useful, but as you say 100644 > is probably too git specific; however if our audience is > git-uninitiated, I doubt -rw-r--r-- is much better (it is > UNIXism, which I personally do not mind). Spelling them out > like "regular file", "executable file", or "symbolic link" > might be more readable. It would be more readable, but then it would be more readable. Ideally I'd like it to be less readable, i.e. less to read. > * I think the filename quoting is better left as-is, since it > is a way to indicate something funny is going on. I agree. 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