* Re: [Census] So who uses git?
From: Andreas Ericsson @ 2006-02-02 14:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, Linus Torvalds, git, Joel Becker
In-Reply-To: <7v8xsu7kys.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>
> I do not particularly have much preference among --also,
> --with-index, or --incremental, but:
>
> - 'with-index' is precise but might be too technical;
> - 'incremental' is not really incremental -- you can use it
> only once.
>
> Because you do not have to say "git commit --also" without paths
> (which _is_ awkward) to get the traditional behaviour, maybe it
> is a good name for that flag (it is also the shortest).
>
Except that -a, which is the logical shorthand, is already taken. How
about --include (or --include-index, or --index) and -i? commit being a
fairly commonly used command, I think it's safe to assume that most
people will read the man-page or the help output if there's something
they don't undetstand.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: gitview 0.3
From: Andreas Ericsson @ 2006-02-03 9:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Aneesh Kumar, git
In-Reply-To: <7vzml9kp9q.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>
> Somebody (I think it was Sean Estabrooks but I may be mistaken)
> once offered to host git projects at a site he controls. I
> wonder if you can get him interested...
>
I've got space for this. If anyone's interested, send me an email off-list.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* [PATCH] do not cat version file if it does not exist
From: Amos Waterland @ 2006-02-03 10:11 UTC (permalink / raw)
To: junkio; +Cc: git
The build process currently produces this ugly message:
$ make
cat: version: No such file or directory
GIT_VERSION = 1.1.GIT
cat: version: No such file or directory
This patch make GIT-VERSION-GEN check that a file named `version' exists
before trying to cat it.
Signed-off-by: Amos Waterland <apw@us.ibm.com>
---
GIT-VERSION-GEN | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
applies-to: 2b022b9b34b375afff456e7527a3d89a56ce8abf
eff0a8f6c905b3112538f30fb5a9ce09d4e18e72
diff --git a/GIT-VERSION-GEN b/GIT-VERSION-GEN
index 72201be..fbaa397 100755
--- a/GIT-VERSION-GEN
+++ b/GIT-VERSION-GEN
@@ -7,8 +7,10 @@ DEF_VER=v1.1.GIT
# (included in release tarballs), then default
if VN=$(git-describe --abbrev=4 HEAD 2>/dev/null); then
VN=$(echo "$VN" | sed -e 's/-/./g');
+elif test -f version; then
+ VN=$(cat version);
else
- VN=$(cat version) || VN="$DEF_VER"
+ VN="$DEF_VER";
fi
VN=$(expr "$VN" : v*'\(.*\)')
---
0.99.9.GIT
^ permalink raw reply related
* [PATCH] do not open editor in dumb terminal
From: Amos Waterland @ 2006-02-03 11:41 UTC (permalink / raw)
To: junkio; +Cc: git, boutcher
Many people run git from a shell in emacs (obtained by M-x shell). When
they try to do a commit without specifying a log message on the command
line with -m, git opens vi inside emacs, with unpleasant results. I
think the right answer is to just refuse to open an editor in any dumb
terminal.
Signed-off-by: Amos Waterland <apw@us.ibm.com>
Cc: Dave C Boutcher <boutcher@cs.umn.edu>
---
git-commit.sh | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
c0ee93460521c1cbf9d3fe86a08b41295a79ebb1
diff --git a/git-commit.sh b/git-commit.sh
index 193feeb..fef8f96 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -207,6 +207,12 @@ then
fi
case "$no_edit" in
'')
+ if [ "$TERM" = "dumb" ]; then
+ printf "%s: %s: %s\n" "git-commit" \
+ "cannot open editor in a dumb terminal" \
+ "use -m to supply message" >&2
+ exit 1
+ fi
${VISUAL:-${EDITOR:-vi}} "$GIT_DIR/COMMIT_EDITMSG"
;;
esac
--
1.1.6.g46dc-dirty
^ permalink raw reply related
* Re: [Attn - repository browser authors] diff-tree combined format.
From: Marco Costalba @ 2006-02-03 12:17 UTC (permalink / raw)
To: Junio C Hamano
Cc: Paul Mackerras, Marco Costalba, Aneesh Kumar, Kay Sievers, git
In-Reply-To: <7v1wylkn54.fsf_-_@assigned-by-dhcp.cox.net>
On 2/3/06, Junio C Hamano <junkio@cox.net> wrote:
> Junio C Hamano <junkio@cox.net> writes:
>
>
> (2) match line numbers in the hunk header to normal diff's
> order:
>
> @@@ -1,87 -1,3 +1,93 @@@
>
> That is, counts for parents prefixed with '-', and
> the count for result prefixed with '+'.
>
It's OK for me. Just one (documentation) note. I found, by means of a
past qgit annotate bug ;-) in case of small files (1 line files as
VERSION files) the diff header format is slightly different.
Sorry, I am not able to post now the diff output but I think should be
not a problem to reproduce.
This is just, as said above, a note to avoid someone else falls in the
same bug assuming
@ -1,87 -1,3 +1,93 @
is the only possible header format.
Regarding the rest is all OK for me. I choose to do not alter/coloring
the patch as gitk does, but to always use red for removed lines and
green for added and to keep the patch output _as is_ . I found this
more simple and clear, at least for me.
Marco
^ permalink raw reply
* Re: The merge from hell...
From: Dave Jones @ 2006-02-03 16:21 UTC (permalink / raw)
To: Junio C Hamano
Cc: Linus Torvalds, Brown, Len, Git Mailing List, Paul Mackerras,
Marco Costalba, Aneesh Kumar
In-Reply-To: <7vbqxpj6qs.fsf@assigned-by-dhcp.cox.net>
On Thu, Feb 02, 2006 at 10:28:43PM -0800, Junio C Hamano wrote:
> > One thing I'd ask for: would it be possible to have more descriptive
> > branch names than just numbers? Even if you want to track it by bugzilla
> > entry number, how about calling it "bugzilla-12345" instead?
>
> When kernel people (not just Len) talk about a "bugzilla ID",
> does that ID always come from the same namespace, or do some
> subsystems have their own bugzilla?
Not only do some subsystems have their own bugtracker (ALSA for eg),
but referring to 'bugzilla' alone is meaningless, as it could
mean bugme.osdl.org, bugzilla.redhat.com, bugzilla.novell.com,
bugzilla.ubuntu.com etc etc, all of which are a prime source of
juicy kernel bugs.
Dave
^ permalink raw reply
* RE: The merge from hell...
From: Brown, Len @ 2006-02-03 18:34 UTC (permalink / raw)
To: Dave Jones, Junio C Hamano
Cc: Linus Torvalds, Git Mailing List, Paul Mackerras, Marco Costalba,
Aneesh Kumar
>On Thu, Feb 02, 2006 at 10:28:43PM -0800, Junio C Hamano wrote:
>
> > > One thing I'd ask for: would it be possible to have more
>descriptive
> > > branch names than just numbers? Even if you want to track
>it by bugzilla
> > > entry number, how about calling it "bugzilla-12345" instead?
> >
> > When kernel people (not just Len) talk about a "bugzilla ID",
> > does that ID always come from the same namespace, or do some
> > subsystems have their own bugzilla?
>
>Not only do some subsystems have their own bugtracker (ALSA for eg),
>but referring to 'bugzilla' alone is meaningless, as it could
>mean bugme.osdl.org, bugzilla.redhat.com, bugzilla.novell.com,
>bugzilla.ubuntu.com etc etc, all of which are a prime source of
>juicy kernel bugs.
Naming the branch is just eye-candy for the merge comment.
My topic branch labels in refs/my-branch never get to kernel.org, so you're
not going to see the pretty green tags on topic branches branches that I see.
I include the full-URL of the bug report in the original commit comments
for those who are interested. I think this it the important place to put it,
and in practice I've found it to be extremely useful.
-Len
^ permalink raw reply
* git-svnimport
From: Jason Harrison @ 2006-02-03 19:29 UTC (permalink / raw)
To: git
Greetings,
I am trying to import from an svn repository into a git repository using
git-svnimport. So far my attempts have failed. Here is what I have done so
far.
git-svnimport svn://svn.debian.org/demi/
### Snippet ###
73: Unrecognized path: /demi.sql
73: Unrecognized path: /lib/dsa.py
74: Unrecognized path: /bin/add-demi-machine
cp: cannot stat `/home/jharrison/svn/demi.git/.git/refs/heads/origin': No such
file or directory
fatal: master: not a valid SHA1
usage: git-read-tree (<sha> | -m [-u | -i] <sha1> [<sha2> [<sha3>]])
checkout failed: 256
git-svnimport -T demi svn://svn.debian.org/demi/
### Snippet ###
73: Unrecognized path: /web/machine.py
73: Unrecognized path: /lib/demi.py
73: Unrecognized path: /lib/dsa.py
74: Unrecognized path: /bin/add-demi-machine
Thanks for your time.
Regards,
Jason
^ permalink raw reply
* git bisect and the merge from hell
From: Luck, Tony @ 2006-02-03 19:47 UTC (permalink / raw)
To: torvalds; +Cc: git
Sometime between -rc1 and -rc2 the ia64 kernel picked up a bug
that prevents booting a UP kernel on my workstation (I recycled
the serial cable to hook up a new machine, so I don't have the
OOPS).
So I thought I'd use git bisect to narrow it down. A few iterations
in it picked the merge from hell, and two iterations after that it
appears to have wandered into the weeds and picked something from
before -rc1.
$ git describe 3c5c363826e435cf4d54d917202567e5b57cae5f
v2.6.15-g3c5c3638
Is this normal?
A couple of iterations down (with git bisect saying that we were into
the home stretch with only 5 commits to go) I ran into build problems,
so I haven't yet got to the bottom of the problem).
Here's the BISECT_LOG:
git-bisect start
# bad: [826eeb53a6f264842200d3311d69107d2eb25f5e] Linux v2.6.16-rc2
git-bisect bad 826eeb53a6f264842200d3311d69107d2eb25f5e
# good: [2664b25051f7ab96b22b199aa2f5ef6a949a4296] Linux v2.6.16-rc1
git-bisect good 2664b25051f7ab96b22b199aa2f5ef6a949a4296
# good: [10379a25fee8ddc8698d2f6c54ccedd4664c2941] Merge master.kernel.org:/pub/scm/linux/kernel/git/davej/agpgart
git-bisect good 10379a25fee8ddc8698d2f6c54ccedd4664c2941
# good: [9a2dba4b4912b493070cbc170629fdbf440b01d7] slab: rename ac_data to cpu_cache_get
git-bisect good 9a2dba4b4912b493070cbc170629fdbf440b01d7
# good: [9ad11ab48b1ad618bf47076e9e579f267f5306c2] compat: fix compat_sys_openat and friends
git-bisect good 9ad11ab48b1ad618bf47076e9e579f267f5306c2
# good: [1494a92f4c2b1d5abdaa1f823dd19f797bb137de] [ALSA] hda-codec - Fix typos in alc882 model table
git-bisect good 1494a92f4c2b1d5abdaa1f823dd19f797bb137de
# bad: [9fdb62af92c741addbea15545f214a6e89460865] [ACPI] merge 3549 4320 4485 4588 4980 5483 5651 acpica asus fops pnpacpi branches into release
git-bisect bad 9fdb62af92c741addbea15545f214a6e89460865
# bad: [3c5c363826e435cf4d54d917202567e5b57cae5f] [ACPI] delete message "**** SET: Misaligned resource pointer:"
git-bisect bad 3c5c363826e435cf4d54d917202567e5b57cae5f
# bad: [c51a4de85de720670f2fbc592a6f8040af72ad87] [ACPI] ACPICA 20051117
git-bisect bad c51a4de85de720670f2fbc592a6f8040af72ad87
Git version is 1.1.4
-Tony
^ permalink raw reply
* Re: [Attn - repository browser authors] diff-tree combined format.
From: Junio C Hamano @ 2006-02-03 19:55 UTC (permalink / raw)
To: Marco Costalba
Cc: Paul Mackerras, Marco Costalba, Aneesh Kumar, Kay Sievers, git
In-Reply-To: <e5bfff550602030417w290c12b6yc4406f890acadc73@mail.gmail.com>
Marco Costalba <mcostalba@gmail.com> writes:
> This is just, as said above, a note to avoid someone else falls in the
> same bug assuming
>
> @ -1,87 -1,3 +1,93 @
>
> is the only possible header format.
When you parse normal unidiff, you may need to watch out for
things like these:
--- a/H --- a/H --- a/H
+++ b/H +++ b/H +++ b/H
@@ -1 +1 @@ @@ -2,2 +1,0 @@ @@ -1 +0,0 @@
-A -2 -1
+1 -3
* When a hunk affects only one line, the line count is omitted.
* When a hunk is only removal of lines, the line count of the
result is zero.
* When such a hunk removes lines from the beginning of the file,
the line offset in the result is also zero.
I do not do the "omit 1" optimizatino in combined output format
(yet -- should I???), so that would not be a problem. The other
two you would see only when you do not have context, and
combined output format has its own context length you cannot
override, so they probably may not matter (I do not know offhand
what 'diff-tree -c' would do in such cases).
^ permalink raw reply
* Re: [PATCH] do not open editor in dumb terminal
From: Junio C Hamano @ 2006-02-03 19:56 UTC (permalink / raw)
To: Amos Waterland; +Cc: git, boutcher
In-Reply-To: <20060203114133.GA11499@kvasir.watson.ibm.com>
Amos Waterland <apw@us.ibm.com> writes:
> Many people run git from a shell in emacs (obtained by M-x shell). When
> they try to do a commit without specifying a log message on the command
> line with -m, git opens vi inside emacs, with unpleasant results. I
> think the right answer is to just refuse to open an editor in any dumb
> terminal.
No, please don't.
I run 'git commit' from M-x shell or M-x compile. My EDITOR is
set to 'emacsclient' while inside Emacs.
As a matter of fact, I do almost all my work inside Emacs and
this setting works rather well for not only git but for other
people's commands (like 'cvs commit').
It might be an option not to fall back on vi and instead to fall
back on ed/ex when neither EDITOR nor VISUAL is specified and
the terminal is dumb. But the patch as-is is unacceptable.
^ permalink raw reply
* Re: [PATCH 0/9] http-fetch fixes
From: Mark Wooding @ 2006-02-03 20:20 UTC (permalink / raw)
To: git
In-Reply-To: <7vzmlaxy2o.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> I briefly looked at the series; the following may be ready to be
> applied:
>
> [PATCH 2/9] http-fetch: Fix object list corruption in fill_activ...
> [PATCH 5/9] http-fetch: Fix message reporting rename of object file
> [PATCH 6/9] http: Turn on verbose Curl messages if GIT_CURL_VERB...
> [PATCH 7/9] http-fetch: Tidy control flow in process_alternate_r...
>
> For now however I'll wait and see for a while, in case you can
> reproduce the breakage Uwe found and add fixes to your set.
I've not had any more trouble with this since, but I'm still worried
that the http fetcher is rather fragile. :-(
What was wrong with 3/9, by the way? (It's the abort_active_slot patch
-- which does fix a real bug.) Is it just that it doesn't apply cleanly
without the first one? If so, I can send out a new patch easily enough.
-- [mdw]
^ permalink raw reply
* [PATCH 3/3] daemon: Support a --user-path option.
From: Mark Wooding @ 2006-02-03 20:27 UTC (permalink / raw)
To: git
In-Reply-To: <20060203202330.1895.60474.stgit@metalzone.distorted.org.uk>
From: Mark Wooding <mwooding@ponder.ncipher.com>
If we're invoked with --user-path=FOO option, then a URL of the form
git://~USER/PATH/... resolves to the path HOME/FOO/PATH/..., where HOME
is USER's home directory. This is done instead of any transformation
due to --base-path, so you can use both at the same time. This lets
users set up their own git repositories to be served by a central
daemon, without them all having to be in the same place, and without the
git-daemon being allowed to roam the entire filesystem freely, or
exposing details of filesystem layout on URLs.
Signed-off-by: Mark Wooding <mdw@distorted.org.uk>
---
Documentation/git-daemon.txt | 11 +++++++++--
daemon.c | 36 +++++++++++++++++++++++++++++++++---
2 files changed, 42 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-daemon.txt b/Documentation/git-daemon.txt
index a20e053..2e48a10 100644
--- a/Documentation/git-daemon.txt
+++ b/Documentation/git-daemon.txt
@@ -10,7 +10,7 @@ SYNOPSIS
[verse]
'git-daemon' [--verbose] [--syslog] [--inetd | --port=n] [--export-all]
[--timeout=n] [--init-timeout=n] [--strict-paths]
- [--base-path=path] [directory...]
+ [--base-path=path] [--user-path=path] [directory...]
DESCRIPTION
-----------
@@ -43,7 +43,7 @@ OPTIONS
'--base-path=/srv/git' on example.com, then if you later try to pull
'git://example.com/hello.git', `git-daemon` will interpret the path
as '/srv/git/hello.git'. Home directories (the '~login' notation)
- access is disabled.
+ access is disabled unless '--user-path' is also given.
--export-all::
Allow pulling from all directories that look like GIT repositories
@@ -70,6 +70,13 @@ OPTIONS
Log to syslog instead of stderr. Note that this option does not imply
--verbose, thus by default only error conditions will be logged.
+--user-path::
+ Rewrite a request for "~user/something" to
+ "home/user-path/something". Useful in conjunction with
+ '--base-path', if you want to restrict the daemon from roaming
+ the entire filesystem without preventing users from publishing
+ their own repositories.
+
--verbose::
Log details about the incoming connections and requested files.
diff --git a/daemon.c b/daemon.c
index 6b88c0c..95b9c7e 100644
--- a/daemon.c
+++ b/daemon.c
@@ -6,6 +6,7 @@
#include <netdb.h>
#include <netinet/in.h>
#include <arpa/inet.h>
+#include <pwd.h>
#include <syslog.h>
#include "pkt-line.h"
#include "cache.h"
@@ -17,7 +18,7 @@ static int verbose;
static const char daemon_usage[] =
"git-daemon [--verbose] [--syslog] [--inetd | --port=n] [--export-all]\n"
" [--timeout=n] [--init-timeout=n] [--strict-paths]\n"
-" [--base-path=path] [directory...]";
+" [--base-path=path] [--user-path=path] [directory...]";
/* List of acceptable pathname prefixes */
static char **ok_paths = NULL;
@@ -28,6 +29,7 @@ static int export_all_trees = 0;
/* Take all paths relative to this one if non-NULL */
static char *base_path = NULL;
+static char *user_path = NULL;
/* Timeout, and initial timeout */
static unsigned int timeout = 0;
@@ -137,14 +139,34 @@ static int avoid_alias(char *p)
static char *path_ok(char *dir)
{
char *path;
+ static char rpath[PATH_MAX];
if (avoid_alias(dir)) {
logerror("'%s': aliased", dir);
return NULL;
}
- if (base_path) {
- static char rpath[PATH_MAX];
+ if (user_path && *dir == '~') {
+ struct passwd *pw;
+ char *u, *p;
+
+ u = dir + 1;
+ p = strchr(u, '/');
+ if (!p) {
+ logerror("'%s': Missing / after user name", dir);
+ return NULL;
+ }
+ *p = 0;
+ pw = getpwnam(u);
+ *p++ = '/';
+ if (!pw) {
+ logerror("'%s': User not found", u);
+ return NULL;
+ }
+ snprintf(rpath, PATH_MAX, "%s/%s/%s",
+ pw->pw_dir, user_path, p);
+ dir = rpath;
+ } else if (base_path) {
if (*dir != '/') {
/* Forbid possible base-path evasion using ~paths. */
logerror("'%s': Non-absolute path denied (base-path active)", dir);
@@ -491,6 +513,10 @@ static int socksetup(int port, int **soc
/* Note: error is not fatal */
}
#endif
+ if (setsockopt(sockfd, SOL_SOCKET, SO_REUSEADDR, &yes, sizeof(yes))) {
+ close(sockfd);
+ continue; /* not fatal */
+ }
if (setsockopt(sockfd, SOL_SOCKET, SO_REUSEADDR,
&yes, sizeof(yes))) {
@@ -673,6 +699,10 @@ int main(int argc, char **argv)
base_path = arg+12;
continue;
}
+ if (!strncmp(arg, "--user-path=", 12)) {
+ user_path = arg+12;
+ continue;
+ }
if (!strcmp(arg, "--")) {
ok_paths = &argv[i+1];
break;
^ permalink raw reply related
* [PATCH 0/3] git-daemon hacking
From: Mark Wooding @ 2006-02-03 20:23 UTC (permalink / raw)
To: git
I've just been playing around a bit with the git-daemon. My main
objective was to implement the feature in the third patch, namely to
allow users to publish their own repositories even though the daemon was
mainly locked down to serving from a particular central tree. This is
the same idea as allowing a web server to serve files in a user's
~/public_html directory.
But I also fixed a couple of bugs I found on the way.
-- [mdw]
^ permalink raw reply
* [PATCH 2/3] daemon: Set SO_REUSEADDR on listening sockets.
From: Mark Wooding @ 2006-02-03 20:27 UTC (permalink / raw)
To: git
In-Reply-To: <20060203202330.1895.60474.stgit@metalzone.distorted.org.uk>
From: Mark Wooding <mdw@distorted.org.uk>
Without this, you can silently lose the ability to receive IPv4
connections if you stop and restart the daemon.
Signed-off-by: Mark Wooding <mdw@distorted.org.uk>
---
daemon.c | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/daemon.c b/daemon.c
index 532bb0c..6b88c0c 100644
--- a/daemon.c
+++ b/daemon.c
@@ -454,6 +454,7 @@ static int socksetup(int port, int **soc
int socknum = 0, *socklist = NULL;
int maxfd = -1;
char pbuf[NI_MAXSERV];
+ int yes = 1;
struct addrinfo hints, *ai0, *ai;
int gai;
@@ -491,6 +492,12 @@ static int socksetup(int port, int **soc
}
#endif
+ if (setsockopt(sockfd, SOL_SOCKET, SO_REUSEADDR,
+ &yes, sizeof(yes))) {
+ close(sockfd);
+ return 0; /* not fatal */
+ }
+
if (bind(sockfd, ai->ai_addr, ai->ai_addrlen) < 0) {
close(sockfd);
continue; /* not fatal */
@@ -523,6 +530,7 @@ static int socksetup(int port, int **soc
{
struct sockaddr_in sin;
int sockfd;
+ int yes = 1;
sockfd = socket(AF_INET, SOCK_STREAM, 0);
if (sockfd < 0)
@@ -533,6 +541,12 @@ static int socksetup(int port, int **soc
sin.sin_addr.s_addr = htonl(INADDR_ANY);
sin.sin_port = htons(port);
+ if (setsockopt(sockfd, SOL_SOCKET, SO_REUSEADDR,
+ &yes, sizeof(yes))) {
+ close(sockfd);
+ return 0;
+ }
+
if ( bind(sockfd, (struct sockaddr *)&sin, sizeof sin) < 0 ) {
close(sockfd);
return 0;
^ permalink raw reply related
* [PATCH 1/3] daemon: Provide missing argument for logerror() call.
From: Mark Wooding @ 2006-02-03 20:27 UTC (permalink / raw)
To: git
In-Reply-To: <20060203202330.1895.60474.stgit@metalzone.distorted.org.uk>
From: Mark Wooding <mdw@distorted.org.uk>
Could cause a crash if --base-path set. Unlikely to be a security the
concern: message doesn't go to the client, so we can't leak anything
(except by dumping core), and we've already forked, so it's not a denial
of service.
Signed-off-by: Mark Wooding <mdw@distorted.org.uk>
---
daemon.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/daemon.c b/daemon.c
index bb014fa..532bb0c 100644
--- a/daemon.c
+++ b/daemon.c
@@ -147,7 +147,7 @@ static char *path_ok(char *dir)
static char rpath[PATH_MAX];
if (*dir != '/') {
/* Forbid possible base-path evasion using ~paths. */
- logerror("'%s': Non-absolute path denied (base-path active)");
+ logerror("'%s': Non-absolute path denied (base-path active)", dir);
return NULL;
}
snprintf(rpath, PATH_MAX, "%s%s", base_path, dir);
^ permalink raw reply related
* [PATCH] config: Rummage through ~/.gitrc as well as the repository's config.
From: Mark Wooding @ 2006-02-03 20:33 UTC (permalink / raw)
To: git
From: Mark Wooding <mdw@distorted.org.uk>
I'm fed up of setting user.email in every repository I own. I want to
put this somewhere central, and I shouldn't have to log in again to make
it take effect.
Signed-off-by: Mark Wooding <mdw@distorted.org.uk>
---
Documentation/git.txt | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/Documentation/git.txt b/Documentation/git.txt
index e8ef3ef..eab3d46 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -468,6 +468,10 @@ people. Here is an example:
Various commands read from the configuration file and adjust
their operation accordingly.
+You can also have a global configuration file, in exactly the same
+format, in the file `.gitrc` in your home directory. This is a handy
+place to put your name and email address.
+
Identifier Terminology
----------------------
^ permalink raw reply related
* Re: git bisect and the merge from hell
From: Junio C Hamano @ 2006-02-03 20:34 UTC (permalink / raw)
To: Luck, Tony; +Cc: git
In-Reply-To: <200602031947.k13JlaDr003720@agluck-lia64.sc.intel.com>
"Luck, Tony" <tony.luck@intel.com> writes:
> Sometime between -rc1 and -rc2 the ia64 kernel picked up a bug
> that prevents booting a UP kernel on my workstation (I recycled
> the serial cable to hook up a new machine, so I don't have the
> OOPS).
>
> So I thought I'd use git bisect to narrow it down. A few iterations
> in it picked the merge from hell, and two iterations after that it
> appears to have wandered into the weeds and picked something from
> before -rc1.
>
> $ git describe 3c5c363826e435cf4d54d917202567e5b57cae5f
> v2.6.15-g3c5c3638
>
> Is this normal?
I haven't looked at your ancestry graph yet (I am at work
writing this message during my lunch break), but if one of the
branches merged between rc1 and rc2 were forked from the
mainline at a commit before rc1, that is an expected behaviour.
Suppose:
.o---o---o--- ... ---o---o.
/ \
/ \
---o---o---*---o--- ... ---o---o---*---o---o---*
rc1 octopus rc2
And you said "rc1 was OK but rc2 is BAD". Now, the bug may well
be somewhere between rc1 and Len's octopus on the lower
development track. But the problem may have been introduced by
some of the commits on the upper development track that bypassed
rc1. They are not descendant of rc1, and describe would say
they come after v2.6.15.
The side branch merged during that timeperiod that forked before
rc1 may not be the one merged by Len's octopus but may be merged
by some other merge, but the story is the same.
^ permalink raw reply
* Re: [PATCH 0/9] http-fetch fixes
From: Junio C Hamano @ 2006-02-03 20:42 UTC (permalink / raw)
To: Mark Wooding; +Cc: git
In-Reply-To: <slrndu7enh.2i8.mdw@metalzone.distorted.org.uk>
Mark Wooding <mdw@distorted.org.uk> writes:
> Junio C Hamano <junkio@cox.net> wrote:
>
>> I briefly looked at the series; the following may be ready to be
>> applied:
>>
>> [PATCH 2/9] http-fetch: Fix object list corruption in fill_activ...
>> [PATCH 5/9] http-fetch: Fix message reporting rename of object file
>> [PATCH 6/9] http: Turn on verbose Curl messages if GIT_CURL_VERB...
>> [PATCH 7/9] http-fetch: Tidy control flow in process_alternate_r...
>>
>> For now however I'll wait and see for a while, in case you can
>> reproduce the breakage Uwe found and add fixes to your set.
>
> I've not had any more trouble with this since, but I'm still worried
> that the http fetcher is rather fragile. :-(
>
> What was wrong with 3/9, by the way? (It's the abort_active_slot patch
> -- which does fix a real bug.)
I saw Nick raised an alternative and you responded but I did not
see Nick agreeing or disagreeing to it, and I haven't spent
enough time on that to convince myself which way to go. That is
why.
Maybe this weekend.
^ permalink raw reply
* Re: [PATCH 3/3] daemon: Support a --user-path option.
From: Junio C Hamano @ 2006-02-03 20:52 UTC (permalink / raw)
To: Mark Wooding; +Cc: git
In-Reply-To: <20060203202706.1895.70864.stgit@metalzone.distorted.org.uk>
Mark Wooding <mdw@distorted.org.uk> writes:
> If we're invoked with --user-path=FOO option, then a URL of the form
> git://~USER/PATH/... resolves to the path HOME/FOO/PATH/..., where HOME
> is USER's home directory.
I am probably slow as usual but I do not see how this is useful.
Wouldn't loosening the "request must be absolute if you use
--base-path" check in the area your first patch in the series
touches to also allow paths that start with a '~' be enough?
That way ~alice/foo would remain to be /home/alice/foo (with
/home/alice being alice's $HOME) and ~becky/bar would be
/home2/becky/bar (with /home2/becky being becky's $HOME).
I suppose you are doing something similar to ~/public_html, but
I think that is an independent feature.
^ permalink raw reply
* Re: [PATCH 2/3] daemon: Set SO_REUSEADDR on listening sockets.
From: Junio C Hamano @ 2006-02-03 20:57 UTC (permalink / raw)
To: Mark Wooding; +Cc: git
In-Reply-To: <20060203202704.1895.18383.stgit@metalzone.distorted.org.uk>
Mark Wooding <mdw@distorted.org.uk> writes:
> From: Mark Wooding <mdw@distorted.org.uk>
>
> Without this, you can silently lose the ability to receive IPv4
> connections if you stop and restart the daemon.
>
> Signed-off-by: Mark Wooding <mdw@distorted.org.uk>
I've always wanted to ask HPA and Linus about this why we did
not do SO_REUSEADDR. I've seen some non-git servers also not
using it, giving me an excuse to take a coffee break during work
;-). Is it because they predate REUSEADDR, or is there a valid
reason to avoid using REUSEADDR under certain conditions?
^ permalink raw reply
* Re: git bisect and the merge from hell
From: Linus Torvalds @ 2006-02-03 20:58 UTC (permalink / raw)
To: Luck, Tony; +Cc: git
In-Reply-To: <200602031947.k13JlaDr003720@agluck-lia64.sc.intel.com>
On Fri, 3 Feb 2006, Luck, Tony wrote:
>
> Sometime between -rc1 and -rc2 the ia64 kernel picked up a bug
> that prevents booting a UP kernel on my workstation (I recycled
> the serial cable to hook up a new machine, so I don't have the
> OOPS).
>
> So I thought I'd use git bisect to narrow it down. A few iterations
> in it picked the merge from hell, and two iterations after that it
> appears to have wandered into the weeds and picked something from
> before -rc1.
>
> $ git describe 3c5c363826e435cf4d54d917202567e5b57cae5f
> v2.6.15-g3c5c3638
>
> Is this normal?
That commit _is_ in between v2.6.16-rc1 and -r2:
[torvalds@g5 linux]$ git-rev-list v2.6.16-rc1..v2.6.16-rc2 | grep 3c5c363826e435
3c5c363826e435cf4d54d917202567e5b57cae5f
but it came through a merge, so the history isn't linear. That commit does
not actually ever reach 2.6.16-rc1 in its history.
Use "git bisect visualize" to see what "git bisect" is doing. It's doing
everything right so far..
> A couple of iterations down (with git bisect saying that we were into
> the home stretch with only 5 commits to go) I ran into build problems,
> so I haven't yet got to the bottom of the problem).
Ok. That's a different issue.
When you hit a problem where "git bisect" will pick a place that doesn't
compile (usually for some stupid reason that you're not at all
interested in chasing down), what you should do is
git bisect visualize
to see what commits are interesting.
Then, pick one of the interesting ones "at random" (it helps if it's not
close to any of the known-uninteresting points), and do
git reset --hard <picked-sha1>
and try that instead (and compile that, and just continue with your
bisection: mark it good or bad depending on whether it works).
Basically, what you're doing is to override the choice of place to test
that "git bisect" chose automatically for you. It still works, but
obviously the point is probably not as "half-way" any more, so it makes
the narrowing down of the bad commit slightly less efficient.
> Here's the BISECT_LOG:
Ok, you've done great progress. You only have 11 revisions left to test
(the last message would have been "5 revisions left to test after this",
but that means that _after_ you've verified the picked point, you'd have
had just five versions left.
"git bisect visualize" really makes it very obvious what to try next, I
think. Which exact commit you try next probably depends on what the
compile error was. I'd try
git reset --hard 3d5271f9883cba7b54762bc4fe027d4172f06db7
(which is after the "pull release into acpica branch" commit).
Linus
^ permalink raw reply
* Re: [Attn - repository browser authors] diff-tree combined format.
From: Junio C Hamano @ 2006-02-03 21:35 UTC (permalink / raw)
To: Marco Costalba
Cc: Paul Mackerras, Marco Costalba, Aneesh Kumar, Kay Sievers, git
In-Reply-To: <e5bfff550602030417w290c12b6yc4406f890acadc73@mail.gmail.com>
Marco Costalba <mcostalba@gmail.com> writes:
> Regarding the rest is all OK for me. I choose to do not alter/coloring
> the patch as gitk does, but to always use red for removed lines and
> green for added and to keep the patch output _as is_ . I found this
> more simple and clear, at least for me.
This reminds me of one thing. One thing I did not like about
the colouring of gitk on an Octopus was that it repeats the same
parents in different colors, wasting lines. From diff-tree -c
output, one thing coloured diff browsers _could_ do is to let
the user pick one parent and paint the lines to make the
differences from that parent alone stand out.
For example, If I had this, and I wanted to focus on the
difference from the first parent:
diff --cc foo
index 92cfee4,50392ff..e9bf860
@@@ -55,A -55,B +55,C @@@
# Define USE_STDEV below if you want git to care...
# change being considered an inode change from t...
- GIT_VERSION = 0.99.9n
-GIT_VERSION = 0.99.9.GIT
++GIT_VERSION = 1.0.0
+# This line was already in the first parent
+ # Not in the first parent but in the second already
# CFLAGS and LDFLAGS are for the users to overri...
You could paint ' ' (unchanged from both) and ' +' (unchanged
from first parent) lines the same way (say white background with
black letters), '- ' (first parent had it but it is gone) lines
red and '+ ' and '++' (either way, first parent did not have it)
lines green. And ' -' (disappeared from second parent, but
neither first parent nor the result has it) can even be dimmed
(say white background with gray letters).
^ permalink raw reply
* RE: git bisect and the merge from hell
From: Luck, Tony @ 2006-02-03 23:16 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
> "git bisect visualize" really makes it very obvious what to try next, I
> think. Which exact commit you try next probably depends on what the
> compile error was. I'd try
>
> git reset --hard 3d5271f9883cba7b54762bc4fe027d4172f06db7
>
> (which is after the "pull release into acpica branch" commit).
Yup, that got the bisection moving again. I finished up at:
$ git bisect bad
96db255c8f014ae3497507104e8df809785a619f is first bad commit
diff-tree 96db255c8f014ae3497507104e8df809785a619f (from 0897831bb54eb36fd9e2a22da7f0f64be1b20d09)
Author: Bob Moore <robert.moore@intel.com>
Date: Wed Nov 2 00:00:00 2005 -0500
[ACPI] ACPICA 20051102
So Len's mega-octopus merge wasn't a problem at all, but this is still
all his fault :-) I'll go beat on him.
Thanks for the tip.
-Tony
^ permalink raw reply
* RE: git bisect and the merge from hell
From: Linus Torvalds @ 2006-02-03 23:44 UTC (permalink / raw)
To: Luck, Tony; +Cc: git
In-Reply-To: <B8E391BBE9FE384DAA4C5C003888BE6F059F4AF6@scsmsx401.amr.corp.intel.com>
On Fri, 3 Feb 2006, Luck, Tony wrote:
>
> So Len's mega-octopus merge wasn't a problem at all, but this is still
> all his fault :-) I'll go beat on him.
Note that this _can_ be a problem with huge octopus merges.
If some bug only appears as a result of the interaction of two branches,
doing a 12-way merge will make it harder to debug. Doing a "git bisect"
will (correctly) pinpoint the merge as being the problem, but after that
you're on your own as to how to debug it.
So _if_ it had been a merge error, there's two issues with that:
- debugging merges is usually a bit less straightforward than debugging a
single well-defined changeset anyway.
- especially an octopus-merge will cause "git-bisect" to be less
efficient, since it cannot be bisected, so if the bug is in the merge
itself, it will ask you to test _every_ _single_ top-of-branch before
the merge.
(Normally, testing 12 kernels would zoom in on a bug from 10.000 feet, and
you'd have bisected a massive four-thousand commits. So having to test 12
branch heads just to pinpoint a _single_ commit is "unusually expensive"
by any standard for git bisection).
Anyway, had it been a merge bug, you should then have done:
- check if it's simply a mis-merge. Do "git-diff-tree --cc" to see if
there were any conflicts, and check them out more closely to see
if maybe they were incorrectly fixed up.
Normally, an octopus merge will never have any actual _manual_
conflicts (the standard git tools shouldn't allow it), but there can
still be several branches that touch the same area and that could have
merged strangely.
If that doesn't get you anywhere, you'll literally have to go to the next
step:
- re-do the merges one by one, until the bug appears, or, if it's not
there once you've re-done them all, check what the differences are
(there _should_ be none, but see above on doing mis-merging) with the
final octopus one.
Anyway, for "normal" bugs (like this one apparently is), git-bisect
shouldn't ever pinpoint a merge, since the bug hopefully was introduced
somewhere _during_ the branch development, and not when it was merged
back. Hopefully.
Anyway. The message you should take home from this is that "git bisect"
handles merges perfectly well, and that at worst it might be less
efficient and harder to debug - especially for octopus merges - but that
both of those problems are likely (a) rare and (b) not insurmountable.
Linus
^ 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