Two functions, namely write_idx_file() and open_pack_file(), currently return a const pointer. However that pointer is either a copy of the first argument, or set to a malloc'd buffer when that first argument is null. In the later case it is wrong to qualify that pointer as const since ownership of the buffer is transferred to the caller to dispose of, and obviously the free() function is not meant to be passed const pointers. Making the return pointer not const causes a warning when the first a...

This is a few patches I've been accumulating. Included is a rework of the progress display so it uses much less screen lines, as well as a couple code cleanups. Nicolas -

Nice. Of course that screws with git-gui and now I have to Hmm. n is unsigned and last_value is signed. Uh? I know you are using the special value -1 to mean we've never output anything for this progress meter but mixing signed and unsigned always gives me the willies. -- Shawn. -

A single sideband packet may sometimes contain multiple lines of progress messages, but we prepend "remote: " only to the whole buffer which creates a messed up display in that case. Make sure that the "remote: " prefix is applied to every remote lines. Signed-off-by: Nicolas Pitre <nico@cam.org> --- sideband.c | 19 +++++++++++++++++-- 1 files changed, 17 insertions(+), 2 deletions(-) diff --git a/sideband.c b/sideband.c index 277fa3c..ab8a1e9 100644 --- a/sideband.c +++ b/sideband...

Totally unrelated to this patch but yesterday a coworker called the Grammar Police on me because Git said "Deltifying objects" in their console window during a fetch or push operation. I told them it was perfectly valid, they disagreed. I got free coffee out of the deal. But still, it bothers some users that we use perhaps less than commonly accepted English in an important tool's output. Seeing it in your context just reminded me of that discussion yesterday. -- Shawn. -

To keep things well layered, sha1close() now returns the file descriptor when it doesn't close the file. An ugly cast was added to the return of write_idx_file() to avoid a warning. A proper fix will come separately. Signed-off-by: Nicolas Pitre <nico@cam.org> --- builtin-pack-objects.c | 29 +++++++++++++++-------------- csum-file.c | 23 ++++++++++++++--------- 2 files changed, 29 insertions(+), 23 deletions(-) diff --git a/builtin-pack-objects.c b/builtin-pack-object...

Resubmit patch due to tab/space issue :) Signed-off-by: Luke Lu <git@vicaya.com> --- Makefile | 2 ++ gitweb/gitweb.perl | 11 +++++++++++ 2 files changed, 13 insertions(+), 0 deletions(-) diff --git a/Makefile b/Makefile index 8db4dbe..3e9938e 100644 --- a/Makefile +++ b/Makefile @@ -165,6 +165,7 @@ GITWEB_CONFIG = gitweb_config.perl GITWEB_HOME_LINK_STR = projects GITWEB_SITENAME = GITWEB_PROJECTROOT = /pub/git +GITWEB_PROJECT_MAXDEPTH = 2007 GITWEB_EXPORT_OK =...

Thanks, I have this locally from your prior version but already Cute. But does what I was asking for, which was to not change behavior for existing users. Most folks have a MAX_PATH around 1024-4096. There's no sane way they would exceed 2000 nested directories. -- Shawn. -

I'm testing out git-filter-branch, as I would like to use it to remove proprietary information from our repository. I created a test repo with "sensitive information" in a file 'A', some other "plain" information, more sensitive stuff in file 'D', a subdirectory of sensitive information (some of this added on a branch 'branch_1', some added on master): % ls -F sensitive A B C D sensitive_stuff/ I then cloned this repo and tried the filter: % git clone sensitive sensitive.clone % cd sen...

Earlier, "git filter-branch --<options> HEAD" would not update the working tree after rewriting the branch. This commit fixes it. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> --- Bill, I hope this clarifies some things for you, too... git-filter-branch.sh | 15 +++++++++++++++ t/t7003-filter-branch.sh | 4 +++- 2 files changed, 18 insertions(+), 1 deletions(-) diff --git a/git-filter-branch.sh b/git-filter-branch.sh index a12f6c2..ffcc408 100755 ...

Ouch. But this may cause the user to lose what they might consider important settings relative to the old section named branch.test. I think in the case you mention above where you are doing a `branch -M` the user really does want the basic branch properties to be forced over (branch.$name.remote, branch.$name.merge) but they probably do not want other branch properties to be removed or deleted. Or maybe they do. Its really hard to second guess the user's intent here. I think its too broad ...

Resubmit patch to make project max depth configurable. Signed-off-by: Luke Lu <git@vicaya.com> --- Makefile | 2 ++ gitweb/gitweb.perl | 8 ++++++++ 2 files changed, 10 insertions(+), 0 deletions(-) diff --git a/Makefile b/Makefile index 8db4dbe..b70ba8c 100644 --- a/Makefile +++ b/Makefile @@ -165,6 +165,7 @@ GITWEB_CONFIG = gitweb_config.perl GITWEB_HOME_LINK_STR = projects GITWEB_SITENAME = GITWEB_PROJECTROOT = /pub/git +GITWEB_PROJECT_MAXDEPTH = 2 GITWEB_EXP...

There are a few programs, such as config and diff, which allow running without a git repository. Therefore, they have to call setup_git_directory_gently(). However, when GIT_DIR and GIT_WORK_TREE were set, and the current directory was a subdirectory of the work tree, setup_git_directory_gently() would return a bogus NULL prefix. This patch fixes that. Noticed by REPLeffect on IRC. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> --- setup.c | 13 ++++...

Simple gitweb patch to speed up project listing on checked out repos with large trees. It was spending minutes in perl (5.8.8 macports). It's taking a fraction of a second after the patch. Resubmitted per Andreas Ericsson's advice. --- gitweb/gitweb.perl | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl index 3064298..a30eef9 100755 --- a/gitweb/gitweb.perl +++ b/gitweb/gitweb.perl @@ -1509,16 +1509,20 @@ sub git_get_projects_l...

If the user specifies 'diff.color = 1' in their configuration file, then gitk will not start. Disable colours when calling git log. Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz> --- gitk | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/gitk b/gitk index 300fdce..999e3c2 100755 --- a/gitk +++ b/gitk @@ -92,7 +92,7 @@ proc start_rev_list {view} { set order "--date-order" } if {[catch { - set fd [open [concat | git log -z --pretty=raw $orde...

Someone else already responded about how to set this limit, but I wanted to clarify what the docs vs. the code were doing here. The docs use camelCase as it is prettier to read multiple words that useCamelCase than alllowercaselikethis. Internally when we parse your config file we lowercase the entire string so that the code can worry only about the lowercase variant. That's why you see it all lowercase in diff.c, but the docs suggest you to use the camelCase format. -- Shawn. -

I believe that with the following change it's a bit easier to visualize the table including the links to the tar.bz2 and tar.gz source packages. Signed-off-by: Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> --- index.html | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/index.html b/index.html index dc5189a..b061178 100644 --- a/index.html +++ b/index.html @@ -54,7 +54,7 @@ Junio C Hamano.</p> <div style="float: right"><table class="releases"...

As far as I know the survey is close so it makes sense to remove the link/text from the home page. Signed-off-by: Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> --- index.html | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/index.html b/index.html index 5d14acf..dc5189a 100644 --- a/index.html +++ b/index.html @@ -50,7 +50,7 @@ the <a href="http://www.gnu.org/licenses/gpl2.txt">GNU General Public License v2 It was originally written by Linus Torvalds and i...

Instead of v2.6.23-5054-g821f3ef please read v1.5.3.4-206-g58ba4f6. -

No. Tabs are 8 spaces wide. Live with it. It's the only sane solution. The fact is, people do mix the two. No ifs, buts or maybes about it. Even in the absense of any actual *spaces*, the size of a tab matters, since you can - and do - have two separately indented things (the initial indentation, and then things like comments being indented separately). The only sane solution is the one the kernel and git have always used: tabs are 8 spaces wide, and anybody who disagrees can go screw...

Actually, part of the mess with tabs is due to the fact they're not exactly 8 spaces wide, but any width that ends at a multiple of 8 characters from the start of the line. So 0 <= n < 8 spaces and a tab is still 8 spaces. Anyways, it's maybe just simpler to run indent before sending patches. Mike -

Read better before replying, and I'm sure you'll agree with Mike ... -- Matthieu -

I'm reading two different ideas here, and it seems like you're conflating the two — and, in the process, telling some pretty smart people (smarter than me, anyhow) to go fuck themselves. If a project uses tabs, your statement regarding 8-char-width tabs makes sense; you need some rule by which you can assume others are viewing the same thing you are. But you then dismiss out of hand the option of using all spaces; Python has been getting along perfectly well for quite some time by following ...

On Tue, 16 Oct 2007 16:05:34 -0700 (PDT) Unfortunately most editors are totally confused about the difference between tab size and indentation level. Visual Studio, probably the most commonly used development environment on Windows, by default uses TAB characters that are 4 spaces wide, and users are recommended not to change that because of that a lot of existing Windows source code and examples uses those settings. Two years ago, when I last looked at it, Eclipse, a very commonly used develop...

It's unreasonable not to list that anywhere. mfwitten -