I was just writing beginner-level instructions for looking at a specific commit in gitk ('double-click on the "SHA1 ID" box to selet the contents, type "5401f304" in its place, and click "goto"'), and it dawned on me that it would be easier to look at a given commit in context if there was a --goto <commit-ish> option as well as the usual filtering options. It might be a nice feature for "git bisect visualize" to preselect the currently-being-tested commit, for example, rather than making the ...

Or, even simpler, use: svn info <url> which will cache the credentials and not require a working copy. Anand -

When using the "tree" view and trying to unfold a particular dir, I got the following error: can't read "treeheight(lib/)": no such element in array can't read "treeheight(lib/)": no such element in array (reading value of variable to increment) invoked from within "incr treeheight($x) $n" (procedure "treeopendir" line 15) invoked from within "treeopendir $w $e" (procedure "treeclick" line 20) invoked from within "treeclick .ctop.cdet.right.cfiles 18 233" (command ...

Table of contents: [PATCH 1/5] gitweb: Protect against possible warning in git_commitdiff [PATCH 2/5] gitweb: Buffer diff header to deal with split patches + git_patchset_body refactoring [PATCH 3/5] gitweb: New improved formatting of chunk header in diff [PATCH 4/5] gitweb: Default to $hash_base or HEAD for $hash in "commit" and "commitdiff" [PATCH 5/5] gitweb: Add an option to href() to return full URL Diffstat: gitweb/gitweb.css | 13 +++ gi...

If we have provided enough info, and diff is not combined diff, and if provided diff line is chunk header, then: * split chunk header into .chunk_info and .section span elements, first containing proper chunk header, second section heading (aka. which function), for separate styling: the proper chunk header is on non-white background, section heading part uses slightly lighter color. * hyperlink from-file-range to starting line of from-file, if file was not created. * hyperlink to-file-ra...

There are some cases when one line from "raw" git-diff output (raw format) corresponds to more than one patch in the patchset git-diff output. To deal with this buffer git diff header and extended diff header (everything up to actual patch) to check from information from "index <hash>..<hash>" extended header line if the patch corresponds to the same or next difftree raw line. This could also be used to gather information needed for hyperlinking, and used for printing gitweb quoted filen...

Executive Summary - 'maint' and 'master' are the same, since we are still in "v1.4.4 fix" mood right now. A maintenance release v1.4.4.1 should follow soonish. - 'next' has a few 'these are obviously the right things to me but I want a bit of cheering-up before pushing them out, and they can wait until the dust settles after early fixes to v1.4.4 anyway' changes. - 'pu' has the shallow clone WIP and a half-finished rewrite of git branch in C, both by Johannes. Both need...

On Sat, 18 Nov 2006 11:37:14 -0800 Well this isn't a huge issue. One point you made though that struck a chord is that many of the commands should probably not be in Is there really a reason for a git user to access these from the command line rather than a script: commit-tree, diff-files, diff-index, diff-tree, for-each-ref, hash-object, http-fetch, http-push, index-pack, local-fetch, merge-base, merge-index, merge-octopus, merge-one-file, merge-ours, merge-recur, merge-recursive, merge-recu...

We fully support dealing with repositories with symlinked HEAD, and will continue to do so; I do not think we ever talked about deprecating it. Public "distribution point" repositories that have been established long ago that do not have reason to switch HEAD to point at different branch still have symlinked HEAD and they should continue to work. What we _don't_ do these days is to set up new repositories with symlinked HEAD, but that does not have anything to do with deprecating symlinked HEAD...

Ah, well. This could be considered a bug... but it can be not. The link is clearly marked "HEAD", so you are requesting HEAD version of the file... which does not exist. We could check if the file has HEAD version, but that is another call to git commands. What you want is the link to the tip of branch ("head", "top" or "tip")... you are welcome to add that (or replace "HEAD" link with that). Tip: href(...,hash_base => $hash_base,...) -- Jakub Narebski Poland -

Because HEAD is master, not html, and there us no such file in master branch? But all the following links http://repo.or.cz/w/LinuxKernelDevelopmentProcess.git?a=blob;f=LinuxKernelDevelopmentP... http://repo.or.cz/w/LinuxKernelDevelopmentProcess.git?a=blob;f=LinuxKernelDevelopmentP... http://repo.or.cz/w/LinuxKernelDevelopmentProcess.git?a=blob;f=LinuxKernelDevelopmentP... works You can use [ message continues ]

Where did you find this link? On what page? "Browsing the repo" is not enough information to discover where there is a bug. -- Jakub Narebski Poland -

Hi all, I'm playing with a repo hosted by repos.os.cz and I think I faced a bug (Pasky confirmed that this should be reported here as a bug). My repo has two branches, master html Master contains a text file while html contains his conversion in html done via asciidoc. I need to URLs that point to the top of the branches in order to have an easy way for lnkind the documentation to external portals. This link points to HEAD, so top of master: [ message continues ]

All commands deserve a man page. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ The meaning of Stonehenge in Traflamadorian, when viewed from above, is: "Replacement part being rushed with all possible speed." -- Kurt Vonnegut, Sirens from Titan -

On Sat, 18 Nov 2006 16:04:43 +0100 What could be said in the docs as to when the use of one is preferred Heh, I suppose you and Petr are right. It's just that in recent discussions the great number of commands provided by Git is seen as a UI problem. Thus having two commands that seem to do the exact same thing gives more such pain for no gain. It's possible that plumbers should not be seen as "users" but rather as coders capable of reading traditional text based (non man-page) documentation...

Are you suggesting that all non section 1 man pages should not exist? -

I copied most of the text from git-status.txt. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> --- Documentation/git-runstatus.txt | 66 +++++++++++++++++++++++++++++++++++++++ builtin-runstatus.c | 2 +- 2 files changed, 67 insertions(+), 1 deletions(-) diff --git a/Documentation/git-runstatus.txt b/Documentation/git-runstatus.txt new file mode 100644 index 0000000..c144c7b --- /dev/null +++ b/Documentation/git-runstatus.txt @@ -0,0 +1,66 @@ +git-runstatus(...

This patch fixes a sparse warning about inaccurate_eof being a "dubious one-bit signed bitfield", makes three more binary variables members of this (now unsigned) bitfield and adds a short comment to indicate the nature of two ternary variables. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> --- builtin-apply.c | 7 +++++-- 1 files changed, 5 insertions(+), 2 deletions(-) diff --git a/builtin-apply.c b/builtin-apply.c index aad5526..61f047f 100644 --- a/builtin-apply.c ++...

Z_NULL is defined as 0, use a proper NULL pointer in its stead. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> --- archive-zip.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/archive-zip.c b/archive-zip.c index 28e7352..ae5572a 100644 --- a/archive-zip.c +++ b/archive-zip.c @@ -160,7 +160,7 @@ static int write_zip_entry(const unsigne void *buffer = NULL; void *deflated = NULL; - crc = crc32(0, Z_NULL, 0); + crc = crc32(0, NULL, 0); p...

I think the question is why you would want to run peek-remote. Do you use the ^{} peeled-onion information and if so how and why? -

qgit (but also gitk FWIK) extracts e0b0830726286287744cc9e1a629a534bbe75452 1965efb1599f59b8e3380335d1fa395e2008a30b Stores in a quick look-up container and then checks against loaded commits to, as Pasky says, attach the nice green markers to tags. Marco -

I was out for dinner, just come back home. Some quick tests with show-ref -d instead of peek-remote: - git tree 2374ms - linux tree 2225ms Not a big change. I reboot before each test to have a guaranteed cold cache. Tested also with show-ref only, not useful to me, but just as a comparison. - git tree 1420ms - linux tree 1021ms Better, but still slower then what I would expected. In both case CPU load is low, processes are heavily I/O bound, so avoiding some fork does not save the ...

This is still a WIP and for discussion only (I have to leave to pick up my wife now so I won't be making any further progress tonight), but I think parse_object() in show-ref is costing us. One worry is that existing git will misinterpret packed-refs file prepared with this version. If you say "git show-ref -d --tags" to this version, it takes the fast path which seems to shave about 1/3 of the runtime. --- diff --git a/builtin-pack-refs.c b/builtin-pack-refs.c index 042d271..0c770f5 1006...

Well, Marco is testing cold-cache numbers. But I agree, even with cold-cache, it shouldn't be anywhere close to that bad. Linus -

Asciidoc-include it into the manuals for programs that use the --pretty command-line option, for consistency among the docs. This describes all the pretty-formats currently listed in the cmit_fmt enum in commit.h, and also briefly describes the presence and format of the 'Merge: ' line in some pretty formats. Signed-off-by: Chris Riddoch <chris@syntacticsugar.org> --- Documentation/git-diff-tree.txt | 7 ++--- Documentation/git-log.txt | 3 +- Documentation/git-rev-list.txt...