* Re: [PATCH 5/7] t5540-http-push: check existence of fetched files
From: Clemens Buchacher @ 2009-10-25 16:49 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: git, Shawn O. Pearce
In-Reply-To: <20091025232227.96769e50.rctay89@gmail.com>
On Sun, Oct 25, 2009 at 11:22:27PM +0800, Tay Ray Chuan wrote:
> # By reset, we force git to retrieve the object
> (cd "$ROOT_PATH"/fetch_unpacked &&
> git reset --hard HEAD^ &&
> git remote rm origin &&
> git reflog expire --expire=0 --all &&
> git prune &&
> - git push -f -v $HTTPD_URL/test_repo_unpacked.git master)
> + test ! -e ".git/objects/$COMMIT_PATH" &&
> + git push -f -v $HTTPD_URL/test_repo_unpacked.git master &&
> + test -e ".git/objects/$COMMIT_PATH")
> '
This fails with smart HTTP. First of all, the objects are packed,
so I substituted the above with
! git rev-list -1 $HEAD &&
git push -f -v $HTTPD_GIT_URL/test_repo_unpacked.git master &&
git rev-list -1 $HEAD > rev-list.out &&
test -n rev-list.out
That should be an equivalent test, right? But still, why should push
re-fetch the commit we just pruned? Smart HTTP does not do that and
therefore fails the last rev-list test:
++ git rev-list -1 9d498b0bbc2a25438e2fbd19081948da86028c23
fatal: bad object 9d498b0bbc2a25438e2fbd19081948da86028c23
Clemens
^ permalink raw reply
* Fw: [ANNOUNCE] BugTracker.NET (FOSS) now supports git integration
From: Corey Trager @ 2009-10-25 16:53 UTC (permalink / raw)
To: git
In-Reply-To: <87k4yj8ta3.fsf@sanosuke.troilus.org>
Right now it just recognizes a number at the very beginning of the commit message, but what I should do is make that configure. That is, I'm using a regex to find the integer, so I can just make that regex be something that's easy to configure. I'll get that done soon, maybe today.
----- Original Message ----
From: Michael Poole <mdpoole@troilus.org>
To: Corey Trager <ctrager@yahoo.com>
Cc: git@vger.kernel.org
Sent: Sun, October 25, 2009 9:03:48 AM
Subject: Re: [ANNOUNCE] BugTracker.NET (FOSS) now supports git integration
Corey Trager writes:
> BugTracker.NET is a free, open-source, GPL, ASP.NET bug tracking app.
> More info at http://ifdefined.com/bugtrackernet.html
>
> With the integration, if you do a commit like...
> git commit -a -m "123 fixed the bug"
> ...then the hook script will link up the commit to bug 123.
>
> Here are screenshots of the Subversion integration, which looks pretty much like the git integration:
> http://ifdefined.com/doc_bug_tracker_subversion.html
>
> Feedback very welcome, good or bad.
Does it recognize bug IDs in the footer section of a commit message
(where Signed-Off-By and similar lines typically go)?
Michael Poole
^ permalink raw reply
* Re: [ANNOUNCE] Stacked Git 0.15
From: Catalin Marinas @ 2009-10-25 17:13 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Git Mailing List
In-Reply-To: <m34opoe5t6.fsf@localhost.localdomain>
2009/10/25 Jakub Narebski <jnareb@gmail.com>:
> Catalin Marinas <catalin.marinas@gmail.com> writes:
>
>> StGit is a Python application providing functionality similar to Quilt
>> (i.e. pushing/popping patches to/from a stack) on top of Git. These
>> operations are performed using Git commands, and the patches are
>> stored as Git commit objects, allowing easy merging of the StGit
>> patches into other repositories using standard Git functionality.
>>
>> Download: http://download.gna.org/stgit/stgit-0.15.tar.gz
>> Main repository: git://repo.or.cz/stgit.git
>> Project homepage: http://www.procode.org/stgit/
>> Mailing list: git@vger.kernel.org (please use "StGit" in the subject)
>> Bug tracker: https://gna.org/bugs/?group=stgit
>
> Is there RPM or SRPM (src.rpm) available somewhere? Or does tarball
> include *.spec file, or an rpm target?
Late last night when running my release script I realised that
setup.py no longer accepts the --prefix=/usr option I used for RPMs.
I'll try to build one in the next couple of days (I wasn't even sure
anyone was using it).
--
Catalin
^ permalink raw reply
* Re: date change of commit?
From: Matthieu Moy @ 2009-10-25 17:14 UTC (permalink / raw)
To: Alex K; +Cc: git
In-Reply-To: <e4a904790910250435p3ff50dcfv5c0c6a86c13d17b@mail.gmail.com>
Alex K <spaceoutlet@gmail.com> writes:
> Hello,
>
> Is it possible to change the date of a commit?
See git-filter-branch. This won't change the date of the existing
commit (which is impossible in Git), but will create another commit
where only the date has been changed.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so
From: Uri Okrent @ 2009-10-25 17:44 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jay Soffian, Johannes Schindelin, Jeff King, Thomas Rast, Euguess,
Mikael Magnusson, Matthieu Moy, git, Johannes Sixt
In-Reply-To: <7vfx9modqf.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> When you do not have local "frotz" branch, and do have cloned/fetched from
> the origin that has "frotz" branch, I am actually Ok with this
>
> $ git checkout frotz [--]
>
> to do an equivalent of:
>
> $ git checkout -t -b frotz origin/frotz
>
> I do not have problem with this _particular_ DWIMmery. It will not break
> people's expectations, other than "asking to check out non-existing ref
> should fail". That expectation might be logical, but I do not think it is
> useful.
FWIW most of the people we train (and we do spend time explaining the
distinction between origin/foo and foo) still find it annoying to have
to create local branches that track branches from the cloned repo. I
think this probably has something to do with the fact that master is
automatically checked out when you clone--people expect other upstream
branches to just 'exist' locally in a similar fashion.
I think the above suggestion is simple enough and would provide the most
bang-for-your-buck in terms of usability.
--
Uri
Please consider the environment before printing this message.
http://www.panda.org/how_you_can_help/
^ permalink raw reply
* Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so
From: Uri Okrent @ 2009-10-25 17:48 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jeff King, Daniel Barkalow, Johannes Sixt, Thomas Rast,
Johannes Schindelin, Euguess, Mikael Magnusson, Matthieu Moy,
Jay Soffian, git
In-Reply-To: <7vhbu2syi6.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> In this sequence:
>
> 1$ git checkout $commit_name_that_is_not_a_local_branch
> 2$ git commit; hack; hack; hack;...
> 3$ git checkout $branch_name
> [...]
> Step #3 is where the state built in the detached HEAD "branch" vanishes
> into lost-found.
>
> The experts argued that #3 is where it is dangerous...
If step 3 is where the danger lies, wouldn't it then be most appropriate to put
the warning message there? I.e., warn or refuse to switch branches when
currently on a detached head containing new commits, kind of like branch -d's
cowardliness.
--
Uri
Please consider the environment before printing this message.
http://www.panda.org/how_you_can_help/
^ permalink raw reply
* [PATCH 0/5] Updates for git-http-backend
From: Mark Lodato @ 2009-10-25 18:05 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Shawn O. Pearce, Mark Lodato
This patch series applies to pu. It adds a GIT_PROJECT_ROOT environment
variable, which makes git-http-backend much easier to configure, and it
updates the documentation to add more useful examples and to clarify some
things.
I originally posted this same series as a single patch in one of the replies
to Return of Smart HTTP. Here, I'm posting it as a set of proper series of
patch, each of which is a unit and has a proper signed-off-by line.
Mark Lodato (5):
http-backend: add GIT_PROJECT_ROOT environment var
http-backend: reword some documentation
http-backend: use mod_alias instead of mod_rewrite
http-backend: add example for gitweb on same URL
http-backend: more explict LocationMatch
Documentation/git-http-backend.txt | 94 +++++++++++++++++++++++-------------
http-backend.c | 25 ++++++++-
2 files changed, 83 insertions(+), 36 deletions(-)
^ permalink raw reply
* [PATCH 1/5] http-backend: add GIT_PROJECT_ROOT environment var
From: Mark Lodato @ 2009-10-25 18:05 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Shawn O. Pearce, Mark Lodato
In-Reply-To: <1256493935-8680-1-git-send-email-lodatom@gmail.com>
Add a new environment variable, GIT_PROJECT_ROOT, to override the
method of using PATH_TRANSLATED to find the git repository on disk.
This makes it much easier to configure the web server, especially when
the web server's DocumentRoot does not contain the git repositories,
which is the usual case.
Signed-off-by: Mark Lodato <lodatom@gmail.com>
---
Documentation/git-http-backend.txt | 39 +++++++++++++++--------------------
http-backend.c | 25 ++++++++++++++++++++--
2 files changed, 39 insertions(+), 25 deletions(-)
diff --git a/Documentation/git-http-backend.txt b/Documentation/git-http-backend.txt
index 022a243..99dbbfb 100644
--- a/Documentation/git-http-backend.txt
+++ b/Documentation/git-http-backend.txt
@@ -41,29 +41,24 @@ http.receivepack::
URL TRANSLATION
---------------
-'git-http-backend' relies on the invoking web server to perform
-URL to path translation, and store the repository path into the
-PATH_TRANSLATED environment variable. Most web servers will do
-this translation automatically, resolving the suffix after the
-CGI name relative to the server's document root.
+To determine the location of the repository on disk, 'git-http-backend'
+concatenates the environment variables PATH_INFO, which is set
+automatically by the web server, and GIT_PROJECT_ROOT, which must be set
+manually in the web server configuration. If GIT_PROJECT_ROOT is not
+set, 'git-http-backend' reads PATH_TRANSLATED, which is also set
+automatically by the web server.
EXAMPLES
--------
Apache 2.x::
- To serve all Git repositories contained within the '/git/'
- subdirectory of the DocumentRoot, ensure mod_cgi and
- mod_alias are enabled, and create a ScriptAlias to the CGI:
+ Ensure mod_cgi, mod_alias, and mod_env are enabled, set
+ GIT_PROJECT_ROOT (or DocumentRoot) appropriately, and
+ create a ScriptAlias to the CGI:
+
----------------------------------------------------------------
-ScriptAlias /git/ /usr/libexec/git-core/git-http-backend/git/
-
-<Directory /usr/libexec/git-core>
- Options None
-</Directory>
-<Files /usr/libexec/git-core/git-http-backend>
- Options ExecCGI
-</Files>
+SetEnv GIT_PROJECT_ROOT /var/www/git
+ScriptAlias /git/ /usr/libexec/git-core/git-http-backend/
----------------------------------------------------------------
+
To enable anonymous read access but authenticated write access,
@@ -78,16 +73,16 @@ require authorization with a LocationMatch directive:
</LocationMatch>
----------------------------------------------------------------
+
-To require authentication for both reads and writes, use a Directory
+To require authentication for both reads and writes, use a Location
directive around the repository, or one of its parent directories:
+
----------------------------------------------------------------
-<Directory /var/www/git/private>
+<Location /git/private>
AuthType Basic
AuthName "Private Git Access"
Require group committers
...
-</Directory>
+</Location>
----------------------------------------------------------------
Accelerated static Apache 2.x::
@@ -97,9 +92,9 @@ Accelerated static Apache 2.x::
file contents from the file system directly to the network:
+
----------------------------------------------------------------
-DocumentRoot /var/www
+SetEnv GIT_PROJECT_ROOT /var/www/git
-ScriptAlias /git/ /usr/libexec/git-core/git-http-backend/git/
+ScriptAlias /git/ /usr/libexec/git-core/git-http-backend/
Alias /git_static/ /var/www/git/
RewriteEngine on
@@ -114,7 +109,7 @@ ENVIRONMENT
'git-http-backend' relies upon the CGI environment variables set
by the invoking web server, including:
-* PATH_TRANSLATED
+* PATH_INFO (if GIT_PROJECT_ROOT is set, otherwise PATH_TRANSLATED)
* REMOTE_USER
* REMOTE_ADDR
* CONTENT_TYPE
diff --git a/http-backend.c b/http-backend.c
index 67030b5..8e5c0a2 100644
--- a/http-backend.c
+++ b/http-backend.c
@@ -528,6 +528,26 @@ static NORETURN void die_webcgi(const char *err, va_list params)
exit(0);
}
+static char* getdir(void)
+{
+ struct strbuf buf = STRBUF_INIT;
+ char *pathinfo = getenv("PATH_INFO");
+ char *root = getenv("GIT_PROJECT_ROOT");
+ char *path = getenv("PATH_TRANSLATED");
+
+ if (root && *root) {
+ if (!pathinfo || !*pathinfo)
+ die("GIT_PROJECT_ROOT is set but PATH_INFO is not");
+ strbuf_addstr(&buf, root);
+ strbuf_addstr(&buf, pathinfo);
+ return strbuf_detach(&buf, NULL);
+ } else if (path && *path) {
+ return xstrdup(path);
+ } else
+ die("No GIT_PROJECT_ROOT or PATH_TRANSLATED from server");
+ return NULL;
+}
+
static struct service_cmd {
const char *method;
const char *pattern;
@@ -550,7 +570,7 @@ static struct service_cmd {
int main(int argc, char **argv)
{
char *method = getenv("REQUEST_METHOD");
- char *dir = getenv("PATH_TRANSLATED");
+ char *dir;
struct service_cmd *cmd = NULL;
char *cmd_arg = NULL;
int i;
@@ -562,8 +582,7 @@ int main(int argc, char **argv)
die("No REQUEST_METHOD from server");
if (!strcmp(method, "HEAD"))
method = "GET";
- if (!dir)
- die("No PATH_TRANSLATED from server");
+ dir = getdir();
for (i = 0; i < ARRAY_SIZE(services); i++) {
struct service_cmd *c = &services[i];
--
1.6.5.1
^ permalink raw reply related
* [PATCH 2/5] http-backend: reword some documentation
From: Mark Lodato @ 2009-10-25 18:05 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Shawn O. Pearce, Mark Lodato
In-Reply-To: <1256493935-8680-2-git-send-email-lodatom@gmail.com>
Clarify some of the git-http-backend documentation, particularly:
* In the Description, state that smart/dumb HTTP fetch and smart HTTP
push are supported, state that authenticated clients allow push, and
remove the note that this is only suited for read-only updates.
* At the start of Examples, state explicitly what URL is mapping to what
location on disk.
Signed-off-by: Mark Lodato <lodatom@gmail.com>
---
Documentation/git-http-backend.txt | 12 ++++++++----
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-http-backend.txt b/Documentation/git-http-backend.txt
index 99dbbfb..0b5e951 100644
--- a/Documentation/git-http-backend.txt
+++ b/Documentation/git-http-backend.txt
@@ -14,13 +14,15 @@ DESCRIPTION
-----------
A simple CGI program to serve the contents of a Git repository to Git
clients accessing the repository over http:// and https:// protocols.
+The program supports clients fetching using both the smart HTTP protcol
+and the backwards-compatible dumb HTTP protocol, as well as clients
+pushing using the smart HTTP protocol.
By default, only the `upload-pack` service is enabled, which serves
'git-fetch-pack' and 'git-ls-remote' clients, which are invoked from
-'git-fetch', 'git-pull', and 'git-clone'.
-
-This is ideally suited for read-only updates, i.e., pulling from
-git repositories.
+'git-fetch', 'git-pull', and 'git-clone'. If the client is authenticated,
+the `receive-pack` service is enabled, which serves 'git-send-pack'
+clients, which is invoked from 'git-push'.
SERVICES
--------
@@ -50,6 +52,8 @@ automatically by the web server.
EXAMPLES
--------
+All of the following examples map 'http://$hostname/git/foo/bar.git'
+to '/var/www/git/foo/bar.git'.
Apache 2.x::
Ensure mod_cgi, mod_alias, and mod_env are enabled, set
--
1.6.5.1
^ permalink raw reply related
* [PATCH 4/5] http-backend: add example for gitweb on same URL
From: Mark Lodato @ 2009-10-25 18:05 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Shawn O. Pearce, Mark Lodato
In-Reply-To: <1256493935-8680-4-git-send-email-lodatom@gmail.com>
In the git-http-backend documentation, add an example of how to set up
gitweb and git-http-backend on the same URL by using a series of
mod_alias commands.
Signed-off-by: Mark Lodato <lodatom@gmail.com>
---
Documentation/git-http-backend.txt | 33 +++++++++++++++++++++++++++++++++
1 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-http-backend.txt b/Documentation/git-http-backend.txt
index e67519d..2989c9f 100644
--- a/Documentation/git-http-backend.txt
+++ b/Documentation/git-http-backend.txt
@@ -88,6 +88,23 @@ directive around the repository, or one of its parent directories:
...
</Location>
----------------------------------------------------------------
++
+To serve gitweb at the same url, use a ScriptAliasMatch to only
+those URLs that 'git-http-backend' can handle, and forward the
+rest to gitweb:
++
+----------------------------------------------------------------
+ScriptAliasMatch \
+ "(?x)^/git/(.*/(HEAD | \
+ info/refs | \
+ objects/(info/[^/]+ | \
+ [0-9a-f]{2}/[0-9a-f]{38} | \
+ pack/pack-[0-9a-f]{40}\.(pack|idx)) | \
+ git-(upload|receive)-pack))$" \
+ /usr/libexec/git-core/git-http-backend/$1
+
+ScriptAlias /git/ /var/www/cgi-bin/gitweb.cgi/
+----------------------------------------------------------------
Accelerated static Apache 2.x::
Similar to the above, but Apache can be used to return static
@@ -102,6 +119,22 @@ AliasMatch ^/git/(.*/objects/[0-9a-f]{2}/[0-9a-f]{38})$ /var/www/git/$1
AliasMatch ^/git/(.*/objects/pack/pack-[0-9a-f]{40}.(pack|idx))$ /var/www/git/$1
ScriptAlias /git/ /usr/libexec/git-core/git-http-backend/
----------------------------------------------------------------
++
+This can be combined with the gitweb configuration:
++
+----------------------------------------------------------------
+SetEnv GIT_PROJECT_ROOT /var/www/git
+
+AliasMatch ^/git/(.*/objects/[0-9a-f]{2}/[0-9a-f]{38})$ /var/www/git/$1
+AliasMatch ^/git/(.*/objects/pack/pack-[0-9a-f]{40}.(pack|idx))$ /var/www/git/$1
+ScriptAliasMatch \
+ "(?x)^/git/(.*/(HEAD | \
+ info/refs | \
+ objects/info/[^/]+ | \
+ git-(upload|receive)-pack))$" \
+ /usr/libexec/git-core/git-http-backend/$1
+ScriptAlias /git/ /var/www/cgi-bin/gitweb.cgi/
+----------------------------------------------------------------
ENVIRONMENT
--
1.6.5.1
^ permalink raw reply related
* [PATCH 3/5] http-backend: use mod_alias instead of mod_rewrite
From: Mark Lodato @ 2009-10-25 18:05 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Shawn O. Pearce, Mark Lodato
In-Reply-To: <1256493935-8680-3-git-send-email-lodatom@gmail.com>
In the git-http-backend documentation, use mod_alias exlusively, instead
of using a combination of mod_alias and mod_rewrite. This makes the
example slightly shorted and a bit more clear.
Signed-off-by: Mark Lodato <lodatom@gmail.com>
---
Documentation/git-http-backend.txt | 10 +++-------
1 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-http-backend.txt b/Documentation/git-http-backend.txt
index 0b5e951..e67519d 100644
--- a/Documentation/git-http-backend.txt
+++ b/Documentation/git-http-backend.txt
@@ -98,13 +98,9 @@ Accelerated static Apache 2.x::
----------------------------------------------------------------
SetEnv GIT_PROJECT_ROOT /var/www/git
-ScriptAlias /git/ /usr/libexec/git-core/git-http-backend/
-Alias /git_static/ /var/www/git/
-
-RewriteEngine on
-RewriteRule ^/git/(.*/objects/[0-9a-f]{2}/[0-9a-f]{38})$ /git_static/$1 [PT]
-RewriteRule ^/git/(.*/objects/pack/pack-[0-9a-f]{40}.pack)$ /git_static/$1 [PT]
-RewriteRule ^/git/(.*/objects/pack/pack-[0-9a-f]{40}.idx)$ /git_static/$1 [PT]
+AliasMatch ^/git/(.*/objects/[0-9a-f]{2}/[0-9a-f]{38})$ /var/www/git/$1
+AliasMatch ^/git/(.*/objects/pack/pack-[0-9a-f]{40}.(pack|idx))$ /var/www/git/$1
+ScriptAlias /git/ /usr/libexec/git-core/git-http-backend/
----------------------------------------------------------------
--
1.6.5.1
^ permalink raw reply related
* [PATCH 5/5] http-backend: more explict LocationMatch
From: Mark Lodato @ 2009-10-25 18:05 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Shawn O. Pearce, Mark Lodato
In-Reply-To: <1256493935-8680-5-git-send-email-lodatom@gmail.com>
In the git-http-backend examples, only match git-receive-pack within
/git/.
Signed-off-by: Mark Lodato <lodatom@gmail.com>
---
Documentation/git-http-backend.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-http-backend.txt b/Documentation/git-http-backend.txt
index 2989c9f..f17251a 100644
--- a/Documentation/git-http-backend.txt
+++ b/Documentation/git-http-backend.txt
@@ -69,7 +69,7 @@ To enable anonymous read access but authenticated write access,
require authorization with a LocationMatch directive:
+
----------------------------------------------------------------
-<LocationMatch ".*/git-receive-pack$">
+<LocationMatch "^/git/.*/git-receive-pack$">
AuthType Basic
AuthName "Git Access"
Require group committers
--
1.6.5.1
^ permalink raw reply related
* Re: [PATCH 3/3] format-patch documentation: Fix formatting
From: Björn Gustavsson @ 2009-10-25 18:47 UTC (permalink / raw)
To: git; +Cc: gitster
In-Reply-To: <4AE47546.6040804@gmail.com>
Björn Gustavsson wrote:
> Format git commands and options consistently using back quotes
> (i.e. a fixed font in the resulting HTML document).
I missed a few places. Here is an additional patch to be applied
on top of the original patch.
I'll send out a new combined patch later, but I'll wait for comments
on the series first.
/Björn
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index 86d3d80..14265b8 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -43,19 +43,19 @@ endif::git-format-patch[]
--stat[=width[,name-width]]::
Generate a diffstat. You can override the default
- output width for 80-column terminal by "--stat=width".
+ output width for 80-column terminal by `--stat=width`.
The width of the filename part can be controlled by
giving another width to it separated by a comma.
--numstat::
- Similar to \--stat, but shows number of added and
+ Similar to `\--stat`, but shows number of added and
deleted lines in decimal notation and pathname without
abbreviation, to make it more machine friendly. For
binary files, outputs two `-` instead of saying
`0 0`.
--shortstat::
- Output only the last line of the --stat format containing total
+ Output only the last line of the `--stat` format containing total
number of modified files, as well as number of added and deleted
lines.
@@ -63,8 +63,8 @@ endif::git-format-patch[]
Output the distribution of relative amount of changes (number of lines added or
removed) for each sub-directory. Directories with changes below
a cut-off percent (3% by default) are not shown. The cut-off percent
- can be set with "--dirstat=limit". Changes in a child directory is not
- counted for the parent directory, unless "--cumulative" is used.
+ can be set with `--dirstat=limit`. Changes in a child directory is not
+ counted for the parent directory, unless `--cumulative` is used.
--dirstat-by-file[=limit]::
Same as `--dirstat`, but counts changed files instead of lines.
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index 79d77f7..f1fd0df 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -160,7 +160,7 @@ will want to ensure that threading is disabled for `git send-email`.
Instead of the standard '[PATCH]' prefix in the subject
line, instead use '[<Subject-Prefix>]'. This
allows for useful naming of a patch series, and can be
- combined with the --numbered option.
+ combined with the `--numbered` option.
--cc=<email>::
Add a `Cc:` header to the email headers. This is in addition
^ permalink raw reply related
* [PATCH] push: always load default config
From: Jeff King @ 2009-10-25 19:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This is needed because we want to use the
advice.pushnonfastforward variable.
Previously, we would load the config on demand only when we
needed to look at push.default. Which meant that "git push"
would load it, but "git push remote" would not, leading to
differing behavior.
Signed-off-by: Jeff King <peff@peff.net>
---
builtin-push.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/builtin-push.c b/builtin-push.c
index b5cd2cd..7338176 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -66,7 +66,6 @@ static void setup_push_tracking(void)
static void setup_default_push_refspecs(void)
{
- git_config(git_default_config, NULL);
switch (push_default) {
default:
case PUSH_DEFAULT_MATCHING:
@@ -174,6 +173,8 @@ int cmd_push(int argc, const char **argv, const char *prefix)
int rc;
const char *repo = NULL; /* default repository */
+ git_config(git_default_config, NULL);
+
struct option options[] = {
OPT_BIT('q', "quiet", &flags, "be quiet", TRANSPORT_PUSH_QUIET),
OPT_BIT('v', "verbose", &flags, "be verbose", TRANSPORT_PUSH_VERBOSE),
--
1.6.4.2.269.g75194.dirty
^ permalink raw reply related
* Re: [PATCH 0/2] Speedup fetch with large numbers of refs
From: Julian Phillips @ 2009-10-25 20:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd44cymcv.fsf@alter.siamese.dyndns.org>
On Sun, 25 Oct 2009, Junio C Hamano wrote:
> Hmm, t5515 does not seem to pass with this series for me.
Ah, sorry. All the tests did (and still do) pass on my mac ...
I'll send an updated version once I get them to pass on Linux too.
--
Julian
---
George Orwell was an optimist.
^ permalink raw reply
* [PATCH v2 0/2] Speedup fetch with large numbers of refs
From: Julian Phillips @ 2009-10-25 21:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This is the same as v1, except that this time the tests pass on Linux
as well as on MacOS.
Julian Phillips (2):
remote: Make ref_remove_duplicates faster for large numbers of refs
fetch: Speed up fetch of large numbers of refs
builtin-fetch.c | 17 ++++++++++++++---
remote.c | 42 +++++++++++++++++++++++-------------------
2 files changed, 37 insertions(+), 22 deletions(-)
^ permalink raw reply
* [PATCH v2 1/2] remote: Make ref_remove_duplicates faster for large numbers of refs
From: Julian Phillips @ 2009-10-25 21:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20091025212449.48498.23208.julian@quantumfyre.co.uk>
The ref_remove_duplicates function was very slow at dealing with very
large numbers of refs. This is because it was using a linear search
through all remaining refs to find any duplicates of the current ref.
Rewriting it to use a string list to keep track of which refs have
already been seen and removing duplicates when they are found is much
more efficient.
Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
---
remote.c | 42 +++++++++++++++++++++++-------------------
1 files changed, 23 insertions(+), 19 deletions(-)
diff --git a/remote.c b/remote.c
index 73d33f2..1380b20 100644
--- a/remote.c
+++ b/remote.c
@@ -6,6 +6,7 @@
#include "revision.h"
#include "dir.h"
#include "tag.h"
+#include "string-list.h"
static struct refspec s_tag_refspec = {
0,
@@ -734,29 +735,32 @@ int for_each_remote(each_remote_fn fn, void *priv)
void ref_remove_duplicates(struct ref *ref_map)
{
- struct ref **posn;
- struct ref *next;
- for (; ref_map; ref_map = ref_map->next) {
+ struct string_list refs = { NULL, 0, 0, 0 };
+ struct string_list_item *item = NULL;
+ struct ref *prev = NULL, *next = NULL;
+ for (; ref_map; ref_map = next) {
+ next = ref_map->next;
if (!ref_map->peer_ref)
continue;
- posn = &ref_map->next;
- while (*posn) {
- if ((*posn)->peer_ref &&
- !strcmp((*posn)->peer_ref->name,
- ref_map->peer_ref->name)) {
- if (strcmp((*posn)->name, ref_map->name))
- die("%s tracks both %s and %s",
- ref_map->peer_ref->name,
- (*posn)->name, ref_map->name);
- next = (*posn)->next;
- free((*posn)->peer_ref);
- free(*posn);
- *posn = next;
- } else {
- posn = &(*posn)->next;
- }
+
+ item = string_list_lookup(ref_map->peer_ref->name, &refs);
+ if (item) {
+ if (strcmp(((struct ref *)item->util)->name,
+ ref_map->name))
+ die("%s tracks both %s and %s",
+ ref_map->peer_ref->name,
+ ((struct ref *)item->util)->name,
+ ref_map->name);
+ prev->next = ref_map->next;
+ free(ref_map->peer_ref);
+ free(ref_map);
}
+
+ item = string_list_insert(ref_map->peer_ref->name, &refs);
+ item->util = ref_map;
+ prev = ref_map;
}
+ string_list_clear(&refs, 0);
}
int remote_has_url(struct remote *remote, const char *url)
--
1.6.5.rc2
^ permalink raw reply related
* [PATCH v2 2/2] fetch: Speed up fetch of large numbers of refs
From: Julian Phillips @ 2009-10-25 21:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20091025212449.48498.23208.julian@quantumfyre.co.uk>
When there are large numbers of refs, calling read_ref for each ref is
inefficent (and infact downright slow) - so instead use for_each_ref
to build up a string list of all the refs that we currently have,
which significantly improves the volume.
Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
---
builtin-fetch.c | 17 ++++++++++++++---
1 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/builtin-fetch.c b/builtin-fetch.c
index acb08e4..0f53cbd 100644
--- a/builtin-fetch.c
+++ b/builtin-fetch.c
@@ -489,7 +489,8 @@ static int add_existing(const char *refname, const unsigned char *sha1,
int flag, void *cbdata)
{
struct string_list *list = (struct string_list *)cbdata;
- string_list_insert(refname, list);
+ struct string_list_item *item = string_list_insert(refname, list);
+ item->util = (void *)sha1;
return 0;
}
@@ -606,9 +607,14 @@ static void check_not_current_branch(struct ref *ref_map)
static int do_fetch(struct transport *transport,
struct refspec *refs, int ref_count)
{
+ struct string_list existing_refs = { NULL, 0, 0, 0 };
+ struct string_list_item *peer_item = NULL;
struct ref *ref_map;
struct ref *rm;
int autotags = (transport->remote->fetch_tags == 1);
+
+ for_each_ref(add_existing, &existing_refs);
+
if (transport->remote->fetch_tags == 2 && tags != TAGS_UNSET)
tags = TAGS_SET;
if (transport->remote->fetch_tags == -1)
@@ -631,8 +637,13 @@ static int do_fetch(struct transport *transport,
check_not_current_branch(ref_map);
for (rm = ref_map; rm; rm = rm->next) {
- if (rm->peer_ref)
- read_ref(rm->peer_ref->name, rm->peer_ref->old_sha1);
+ if (rm->peer_ref) {
+ peer_item = string_list_lookup(rm->peer_ref->name,
+ &existing_refs);
+ if (peer_item)
+ hashcpy(rm->peer_ref->old_sha1,
+ peer_item->util);
+ }
}
if (tags == TAGS_DEFAULT && autotags)
--
1.6.5.rc2
^ permalink raw reply related
* Re: git hang with corrupted .pack
From: Junio C Hamano @ 2009-10-26 2:35 UTC (permalink / raw)
To: Alex Riesen
Cc: Junio C Hamano, Nicolas Pitre, Shawn O. Pearce, Andy Isaacson,
git
In-Reply-To: <81b0412b0910200814v269e91fbkd7841308685e1c54@mail.gmail.com>
Alex Riesen <raa.lkml@gmail.com> writes:
> On Thu, Oct 15, 2009 at 09:39, Junio C Hamano <gitster@pobox.com> wrote:
>> Nicolas Pitre <nico@fluxnic.net> writes:
>>
>>> I confirm this test without the fix reproduces the infinite loop (and
>>> does stall the test suite).
>>
>> Thanks, both of you.
>
> I seem to have problems with this change (on Cygwin). Sometimes
> accessing an object in a pack fails in unpack_compressed_entry.
> When it happens, both avail_in and avail_out of the stream are 0,
> and the reported status is Z_BUF_ERROR.
Could you test the patch in
http://mid.gmane.org/7vd44gm089.fsf@alter.siamese.dyndns.org
without your workaround?
-- >8 --
Subject: Fix incorrect error check while reading deflated pack data
I looked at the issue again, and came to the conclusion that we need quite
different fix for the two inflate callsites, as they do quite different
things.
-- >8 --
Subject: Fix incorrect error check while reading deflated pack data
The loop in get_size_from_delta() feeds a deflated delta data from the
pack stream _until_ we get inflated result of 20 bytes[*] or we reach the
end of stream.
Side note. This magic number 20 does not have anything to do with the
size of the hash we use, but comes from 1a3b55c (reduce delta head
inflated size, 2006-10-18).
The loop reads like this:
do {
in = use_pack();
stream.next_in = in;
st = git_inflate(&stream, Z_FINISH);
curpos += stream.next_in - in;
} while ((st == Z_OK || st == Z_BUF_ERROR) &&
stream.total_out < sizeof(delta_head));
This git_inflate() can return:
- Z_STREAM_END, if use_pack() fed it enough input and the delta itself
was smaller than 20 bytes;
- Z_OK, when some progress has been made;
- Z_BUF_ERROR, if no progress is possible, because we either ran out of
input (due to corrupt pack), or we ran out of output before we saw the
end of the stream.
The fix b3118bd (sha1_file: Fix infinite loop when pack is corrupted,
2009-10-14) attempted was against a corruption that appears to be a valid
stream that produces a result larger than the output buffer, but we are
not even trying to read the stream to the end in this loop. If avail_out
becomes zero, total_out will be the same as sizeof(delta_head) so the loop
will terminate without the "fix". There is no fix from b3118bd needed for
this loop, in other words.
The loop in unpack_compressed_entry() is quite a different story. It
feeds a deflated stream (either delta or base) and allows the stream to
produce output up to what we expect but no more.
do {
in = use_pack();
stream.next_in = in;
st = git_inflate(&stream, Z_FINISH);
curpos += stream.next_in - in;
} while (st == Z_OK || st == Z_BUF_ERROR)
This _does_ risk falling into an endless interation, as we can exhaust
avail_out if the length we expect is smaller than what the stream wants to
produce (due to pack corruption). In such a case, avail_out will become
zero and inflate() will return Z_BUF_ERROR, while avail_in may (or may
not) be zero.
But this is not a right fix:
do {
in = use_pack();
stream.next_in = in;
st = git_inflate(&stream, Z_FINISH);
+ if (st == Z_BUF_ERROR && (stream.avail_in || !stream.avail_out)
+ break; /* wants more input??? */
curpos += stream.next_in - in;
} while (st == Z_OK || st == Z_BUF_ERROR)
as Z_BUF_ERROR from inflate() may be telling us that avail_in has also run
out before reading the end of stream marker. In such a case, both avail_in
and avail_out would be zero, and the loop should iterate to allow the end
of stream marker to be seen by inflate from the input stream.
The right fix for this loop is likely to be to increment the initial
avail_out by one (we allocate one extra byte to terminate it with NUL
anyway, so there is no risk to overrun the buffer), and break out if we
see that avail_out has become zero, in order to detect that the stream
wants to produce more than what we expect. After the loop, we have a
check that exactly tests this condition:
if ((st != Z_STREAM_END) || stream.total_out != size) {
free(buffer);
return NULL;
}
So here is a patch (without my previous botched attempts) to fix this
issue. The first hunk reverts the corresponding hunk from b3118bd, and
the second hunk is the same fix proposed earlier.
---
sha1_file.c | 8 +++-----
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index 4cc8939..63981fb 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1357,8 +1357,6 @@ unsigned long get_size_from_delta(struct packed_git *p,
in = use_pack(p, w_curs, curpos, &stream.avail_in);
stream.next_in = in;
st = git_inflate(&stream, Z_FINISH);
- if (st == Z_BUF_ERROR && (stream.avail_in || !stream.avail_out))
- break;
curpos += stream.next_in - in;
} while ((st == Z_OK || st == Z_BUF_ERROR) &&
stream.total_out < sizeof(delta_head));
@@ -1589,15 +1587,15 @@ static void *unpack_compressed_entry(struct packed_git *p,
buffer[size] = 0;
memset(&stream, 0, sizeof(stream));
stream.next_out = buffer;
- stream.avail_out = size;
+ stream.avail_out = size + 1;
git_inflate_init(&stream);
do {
in = use_pack(p, w_curs, curpos, &stream.avail_in);
stream.next_in = in;
st = git_inflate(&stream, Z_FINISH);
- if (st == Z_BUF_ERROR && (stream.avail_in || !stream.avail_out))
- break;
+ if (!stream.avail_out)
+ break; /* the payload is larger than it should be */
curpos += stream.next_in - in;
} while (st == Z_OK || st == Z_BUF_ERROR);
git_inflate_end(&stream);
^ permalink raw reply related
* [ANNOUNCE] GIT 1.6.5.2
From: Junio C Hamano @ 2009-10-26 5:19 UTC (permalink / raw)
To: git
The latest maintenance release GIT 1.6.5.2 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.6.5.2.tar.{gz,bz2} (source tarball)
git-htmldocs-1.6.5.2.tar.{gz,bz2} (preformatted docs)
git-manpages-1.6.5.2.tar.{gz,bz2} (preformatted docs)
The RPM binary packages for a few architectures are found in:
RPMS/$arch/git-*-1.6.5.2-1.fc9.$arch.rpm (RPM)
GIT v1.6.5.2 Release Notes
==========================
Fixes since v1.6.5.1
--------------------
* Installation of templates triggered a bug in busybox when using tar
implementation from it.
* "git add -i" incorrectly ignored paths that are already in the index
if they matched .gitignore patterns.
* "git describe --always" should have produced some output even there
were no tags in the repository, but it didn't.
* "git ls-files" when showing tracked files incorrectly paid attention
to the exclude patterns.
Other minor documentation updates are included.
----------------------------------------------------------------
Changes since v1.6.5.1 are as follows:
Andreas Schwab (1):
Work around option parsing bug in the busybox tar implementation
Carlos R. Mafra (1):
Makefile: clean block-sha1/ directory instead of mozilla-sha1/
Jeff King (2):
ls-files: excludes should not impact tracked files
document push's new quiet option
Joe Perches (1):
git-send-email.perl: fold multiple entry "Cc:" and multiple single line "RCPT TO:"s
Johannes Sixt (2):
Remove a left-over file from t/t5100
Mark files in t/t5100 as UTF-8
Jonathan Nieder (1):
Documentation: describe check-ref-format --branch
Junio C Hamano (4):
Fix incorrect error check while reading deflated pack data
Do not fail "describe --always" in a tag-less repository
Fix list of released versions in the toc document
GIT 1.6.5.2
Markus Heidelberg (1):
t7800-difftool: fix the effectless GIT_DIFFTOOL_PROMPT test
Matt Kraai (1):
Documentation/git-gc.txt: change "references" to "reference"
Nanako Shiraishi (2):
git push: remove incomplete options list from help text
git push: say that --tag can't be used with --all or --mirror in help text
Nasser Grainawi (1):
Document `delta` attribute in "git help attributes".
Pauli Virtanen (1):
git-add--interactive: never skip files included in index
^ permalink raw reply
* Re: git hang with corrupted .pack
From: Alex Riesen @ 2009-10-26 7:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, Shawn O. Pearce, Andy Isaacson, git
In-Reply-To: <7vr5sqq3vm.fsf@alter.siamese.dyndns.org>
On Mon, Oct 26, 2009 at 03:35, Junio C Hamano <gitster@pobox.com> wrote:
>
> Could you test the patch in
>
> http://mid.gmane.org/7vd44gm089.fsf@alter.siamese.dyndns.org
>
> without your workaround?
>
> -- >8 --
> Subject: Fix incorrect error check while reading deflated pack data
>
I did. It works as intended since about 3 days. It also helped my home
server (a 32bit Linux system), which also experienced the problem.
Thanks!
^ permalink raw reply
* Re: What's cooking in git.git (Oct 2009, #04; Wed, 21)
From: Junio C Hamano @ 2009-10-26 7:14 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: Junio C Hamano, git
In-Reply-To: <20091025160213.GA8532@localhost>
Clemens Buchacher <drizzd@aon.at> writes:
> On Wed, Oct 21, 2009 at 11:52:30PM -0700, Junio C Hamano wrote:
>
>> * ks/precompute-completion (2009-10-05) 1 commit.
>> (merged to 'next' on 2009-10-14 at adf722a)
>> + Speedup bash completion loading
>>
>> Are people happy with this?
>
> I'm looking forward to this on Windows, where loading the completion script
> can take about 10 seconds.
Thanks.
Are you giving this comment after you actually tried it on Windows and
found it satisfactory, or is it just based on the general description of
"this should make it faster"?
I need to know, to sift acks/kudos based on facts that I can use to decide
when to release it to 'master', from wishful thinking that I shouldn't,
especially after seeing an obvious issue like the one reported by Stephen
Boyd a few days ago (http://mid.gname.com/4AE0190E.8020803@gmail.com/).
^ permalink raw reply
* Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so
From: Junio C Hamano @ 2009-10-26 7:14 UTC (permalink / raw)
To: Uri Okrent
Cc: Jeff King, Daniel Barkalow, Johannes Sixt, Thomas Rast,
Johannes Schindelin, Euguess, Mikael Magnusson, Matthieu Moy,
Jay Soffian, git
In-Reply-To: <4AE48F88.1030108@gmail.com>
Uri Okrent <uokrent@gmail.com> writes:
> Junio C Hamano wrote:
>> In this sequence:
>>
>> 1$ git checkout $commit_name_that_is_not_a_local_branch
>> 2$ git commit; hack; hack; hack;...
>> 3$ git checkout $branch_name
>> [...]
>> Step #3 is where the state built in the detached HEAD "branch" vanishes
>> into lost-found.
>>
>> The experts argued that #3 is where it is dangerous...
>
> If step 3 is where the danger lies, wouldn't it then be most appropriate to put
> the warning message there?
You already get reminded that you were on a detached HEAD in step #3.
The primary point of the message you are replying to was that I do not
agree with the view that step #3 is the most problematic step. The
existing reminder would help people who read it and are capable of
realizing "ah, I started it on a throw-away branch but ended up with
something I would rather keep" and doing "git branch topic HEAD@{1}".
It will not help people who haven't got enough clue yet to know what a
detached HEAD is, or you can refer to your previous point with HEAD@{1}
notation. We do give brief advice at step #1 to alleviate this issue.
^ permalink raw reply
* Re: What's cooking in git.git (Oct 2009, #04; Wed, 21)
From: Clemens Buchacher @ 2009-10-26 8:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Stephen Boyd
In-Reply-To: <7vzl7eocd6.fsf@alter.siamese.dyndns.org>
On Mon, Oct 26, 2009 at 12:14:45AM -0700, Junio C Hamano wrote:
> Are you giving this comment after you actually tried it on Windows and
> found it satisfactory, or is it just based on the general description of
> "this should make it faster"?
I just tried and it went down from several seconds to about half a second.
On slower machines I expect the difference to be even more noticable.
> I need to know, to sift acks/kudos based on facts that I can use to decide
> when to release it to 'master', from wishful thinking that I shouldn't,
> especially after seeing an obvious issue like the one reported by Stephen
> Boyd a few days ago (http://mid.gname.com/4AE0190E.8020803@gmail.com/).
I cannot follow that link. If you're referring to the "completion of
commands available only in build environment" issue, that could also be
considered a feature, because it allows completion of user-defined scripts.
Why does your PATH include the build directory during make, Stephen?
Clemens
^ permalink raw reply
* Re: What's cooking in git.git (Oct 2009, #04; Wed, 21)
From: Stephen Boyd @ 2009-10-26 9:01 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: Junio C Hamano, git
In-Reply-To: <20091026082931.GA6192@localhost>
Clemens Buchacher wrote:
>> I need to know, to sift acks/kudos based on facts that I can use to decide
>> when to release it to 'master', from wishful thinking that I shouldn't,
>> especially after seeing an obvious issue like the one reported by Stephen
>> Boyd a few days ago (http://mid.gname.com/4AE0190E.8020803@gmail.com/).
>
> I cannot follow that link. If you're referring to the "completion of
> commands available only in build environment" issue, that could also be
> considered a feature, because it allows completion of user-defined scripts.
>
> Why does your PATH include the build directory during make, Stephen?
The Makefile says:
git-completion.bash: git-completion.bash.in git-completion.bash.generate
# Generate completions for binaries we have just built
PATH="$(shell pwd)/../..:$$PATH" ./git-completion.bash.generate
Having user-defined scripts is a good point. Generating the completion
like this removes the possibility of such scripts from appearing in the
completion. Unless users are putting their own "git-*" scripts in their
build directory (sounds odd to me).
Personally, I'd rather keep it dynamic but I can see how it's useful to
get the 10x speedup. It would be really cool if we could have the best
of both worlds, where I keep my dynamic loading, but others can build
the completion and get the speedup.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox