* Re: More merge questions (why doesn't this work?)
From: Junio C Hamano @ 2005-12-02 22:00 UTC (permalink / raw)
To: git
In-Reply-To: <20051202213214.27282.qmail@science.horizon.com>
<linux <at> horizon.com> writes:
> + git merge 'Merge a, b, c' master a b c
> Trying simple merge with a
> Trying simple merge with b
> Trying simple merge with c
> Simple merge did not work, trying automatic merge.
> Removing c
> fatal: merge program failed
> No merge strategy handled the merge.
I think this is the same problem I fixed yesterday after the breakage report
from Luben Tuikov. You need the ce3ca275452cf069eb6451d6f5b0f424a6f046aa commit.
Sorry about that.
Could you try the latest and see if it still breaks?
^ permalink raw reply
* Re: More merge questions (why doesn't this work?)
From: Linus Torvalds @ 2005-12-02 22:12 UTC (permalink / raw)
To: linux; +Cc: junkio, git
In-Reply-To: <20051202213214.27282.qmail@science.horizon.com>
On Fri, 2 Dec 2005, linux@horizon.com wrote:
>
> produces...
>
> + git merge 'Merge a, b, c' master a b c
> Trying simple merge with a
> Trying simple merge with b
> Trying simple merge with c
> Simple merge did not work, trying automatic merge.
> Removing c
> fatal: merge program failed
> No merge strategy handled the merge.
I'm getting
...
+ git merge 'Merge a, b, c' master a b c
Trying simple merge with a
Trying simple merge with b
Trying simple merge with c
Simple merge did not work, trying automatic merge.
Removing c
Merge 9ca217790c7e6581fe0b8b3b4baf026d03584c66, made by octopus.
a | 1 +
b | 1 +
c | 1 -
3 files changed, 2 insertions(+), 1 deletions(-)
delete mode 100644 c
and I don't see why you wouldn't get that too.
Do you have that broken version of git that had problems with "rmdir" and
thought the unlink failed?
Linus
^ permalink raw reply
* Re: git-ls-tree: add "-t" option to always show the tree entries
From: Junio C Hamano @ 2005-12-02 22:12 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0512011354500.3099@g5.osdl.org>
Linus Torvalds <torvalds <at> osdl.org> writes:
> That brings up another issue. I typed
>
> git-ls-tree -r --name-only ..
>
> and it obviously didn't work.
This brings up another issue. When git-ls-tree works from subdirectory,
do we want to see repository-relative paths, or cwd relative paths?
Currently we do the latter.
^ permalink raw reply
* [PATCH] Add compat/setenv.c, use in git.c.
From: Jason Riedy @ 2005-12-02 23:08 UTC (permalink / raw)
To: git
There is no setenv() in Solaris 5.8. The trivial calls to
setenv() were replaced by putenv() in a much earlier patch,
but setenv() was used again in git.c. This patch just adds
a compat/setenv.c.
The rule for building git$(X) also needs to include compat.
objects and compiler flags. Those are now in makefile vars
COMPAT_OBJS and COMPAT_CFLAGS.
Signed-off-by: E. Jason Riedy <ejr@cs.berkeley.edu>
---
Makefile | 27 ++++++++++++++++++---------
compat/setenv.c | 31 +++++++++++++++++++++++++++++++
git.c | 4 ++++
3 files changed, 53 insertions(+), 9 deletions(-)
create mode 100644 compat/setenv.c
applies-to: fc206c1ad60cfb6481cc51f6737ce728d1d8d83f
4bbc94c80d34b1ef859dd92254284198b0c3c2b6
diff --git a/Makefile b/Makefile
index 45db357..df3c6eb 100644
--- a/Makefile
+++ b/Makefile
@@ -21,6 +21,8 @@ all:
#
# Define NO_STRCASESTR if you don't have strcasestr.
#
+# Define NO_SETENV if you don't have setenv in the C library.
+#
# Define PPC_SHA1 environment variable when running make to make use of
# a bundled SHA1 routine optimized for PowerPC.
#
@@ -194,6 +196,7 @@ shellquote = '$(call shq,$(1))'
uname_S := $(shell sh -c 'uname -s 2>/dev/null || echo not')
uname_M := $(shell sh -c 'uname -m 2>/dev/null || echo not')
uname_O := $(shell sh -c 'uname -o 2>/dev/null || echo not')
+uname_R := $(shell sh -c 'uname -r 2>/dev/null || echo not')
ifeq ($(uname_S),Darwin)
NEEDS_SSL_WITH_CRYPTO = YesPlease
@@ -211,6 +214,9 @@ ifeq ($(uname_S),SunOS)
NEEDS_LIBICONV = YesPlease
SHELL_PATH = /bin/bash
NO_STRCASESTR = YesPlease
+ ifeq ($(uname_R),5.8)
+ NO_SETENV = YesPlease
+ endif
INSTALL = ginstall
TAR = gtar
ALL_CFLAGS += -D__EXTENSIONS__
@@ -314,12 +320,16 @@ ifdef NEEDS_NSL
SIMPLE_LIB += -lnsl
endif
ifdef NO_STRCASESTR
- ALL_CFLAGS += -Dstrcasestr=gitstrcasestr -DNO_STRCASESTR=1
- LIB_OBJS += compat/strcasestr.o
+ COMPAT_CFLAGS += -Dstrcasestr=gitstrcasestr -DNO_STRCASESTR=1
+ COMPAT_OBJS += compat/strcasestr.o
+endif
+ifdef NO_SETENV
+ COMPAT_CFLAGS += -Dsetenv=gitsetenv -DNO_SETENV=1
+ COMPAT_OBJS += compat/setenv.o
endif
ifdef NO_MMAP
- ALL_CFLAGS += -Dmmap=gitfakemmap -Dmunmap=gitfakemunmap -DNO_MMAP
- LIB_OBJS += compat/mmap.o
+ COMPAT_CFLAGS += -Dmmap=gitfakemmap -Dmunmap=gitfakemunmap -DNO_MMAP
+ COMPAT_OBJS += compat/mmap.o
endif
ifdef NO_IPV6
ALL_CFLAGS += -DNO_IPV6 -Dsockaddr_storage=sockaddr_in
@@ -343,8 +353,8 @@ endif
endif
endif
-ALL_CFLAGS += -DSHA1_HEADER=$(call shellquote,$(SHA1_HEADER))
-
+ALL_CFLAGS += -DSHA1_HEADER=$(call shellquote,$(SHA1_HEADER)) $(COMPAT_CFLAGS)
+LIB_OBJS += $(COMPAT_OBJS)
export prefix TAR INSTALL DESTDIR SHELL_PATH template_dir
### Build rules
@@ -353,10 +363,9 @@ all: $(ALL_PROGRAMS)
all:
$(MAKE) -C templates
-# Only use $(CFLAGS). We don't need anything else.
-git$(X): git.c Makefile
+git$(X): git.c $(COMPAT_OBJS) Makefile
$(CC) -DGIT_EXEC_PATH='"$(bindir)"' -DGIT_VERSION='"$(GIT_VERSION)"' \
- $(CFLAGS) $< -o $@
+ $(CFLAGS) $(COMPAT_CFLAGS) -o $@ $(filter %.c,$^) $(filter %.o,$^)
$(patsubst %.sh,%,$(SCRIPT_SH)) : % : %.sh
rm -f $@
diff --git a/compat/setenv.c b/compat/setenv.c
new file mode 100644
index 0000000..94acd2d
--- /dev/null
+++ b/compat/setenv.c
@@ -0,0 +1,31 @@
+#include <stdlib.h>
+#include <string.h>
+
+int gitsetenv(const char *name, const char *value, int replace)
+{
+ int out;
+ size_t namelen, valuelen;
+ char *envstr;
+
+ if (!name || !value) return -1;
+ if (!replace) {
+ char *oldval = NULL;
+ oldval = getenv(name);
+ if (oldval) return 0;
+ }
+
+ namelen = strlen(name);
+ valuelen = strlen(value);
+ envstr = malloc((namelen + valuelen + 2) * sizeof(char));
+ if (!envstr) return -1;
+
+ memcpy(envstr, name, namelen);
+ envstr[namelen] = '=';
+ memcpy(envstr + namelen + 1, value, valuelen);
+ envstr[namelen + valuelen + 1] = 0;
+
+ out = putenv(envstr);
+
+ free(envstr);
+ return out;
+}
diff --git a/git.c b/git.c
index 878c359..619f25a 100644
--- a/git.c
+++ b/git.c
@@ -13,6 +13,10 @@
# define PATH_MAX 4096
#endif
+#ifdef NO_SETENV
+extern int gitsetenv(char *name, char *value, int overwrite);
+#endif
+
static const char git_usage[] =
"Usage: git [--version] [--exec-path[=GIT_EXEC_PATH]] [--help] COMMAND [ ARGS ]";
---
0.99.9h
^ permalink raw reply related
* [PATCH] Include Makefile.localdef in Makefile, if it exists.
From: Jason Riedy @ 2005-12-02 23:11 UTC (permalink / raw)
To: git
Makefile.localdef is just a hook for local definitions. Users
can track their definitions in a branch and not worry about
merge conflicts.
Signed-off-by: E. Jason Riedy <ejr@cs.berkeley.edu>
---
Makefile | 15 +++++++++------
1 files changed, 9 insertions(+), 6 deletions(-)
applies-to: b93e1c78095bf4ace0806ab70295931f6da28174
65e5d3d6d31af3dda6d5cfd4e0745f34118955c3
diff --git a/Makefile b/Makefile
index df3c6eb..dc7581d 100644
--- a/Makefile
+++ b/Makefile
@@ -64,18 +64,21 @@ LDFLAGS =
ALL_CFLAGS = $(CFLAGS)
ALL_LDFLAGS = $(LDFLAGS)
-prefix = $(HOME)
-bindir = $(prefix)/bin
-template_dir = $(prefix)/share/git-core/templates/
-GIT_PYTHON_DIR = $(prefix)/share/git-core/python
-# DESTDIR=
-
CC = gcc
AR = ar
TAR = tar
INSTALL = install
RPMBUILD = rpmbuild
+# Include local definitions, if any.
+-include Makefile.localdef
+
+prefix ?= $(HOME)
+bindir ?= $(prefix)/bin
+template_dir ?= $(prefix)/share/git-core/templates/
+GIT_PYTHON_DIR ?= $(prefix)/share/git-core/python
+# DESTDIR=
+
# sparse is architecture-neutral, which means that we need to tell it
# explicitly what architecture to check for. Fix this up for yours..
SPARSE_FLAGS = -D__BIG_ENDIAN__ -D__powerpc__
---
0.99.9h
^ permalink raw reply related
* Re: git-ls-tree: add "-t" option to always show the tree entries
From: Linus Torvalds @ 2005-12-02 23:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <loom.20051202T231110-711@post.gmane.org>
On Fri, 2 Dec 2005, Junio C Hamano wrote:
>
> This brings up another issue. When git-ls-tree works from subdirectory,
> do we want to see repository-relative paths, or cwd relative paths?
> Currently we do the latter.
Umm, I'd not say that we do the latter, but yeah, that's broken. We
actually do _filter_ based on the cwd, but then we show the whole path,
which makes no sense.
Something like this?
Linus
---
diff --git a/ls-tree.c b/ls-tree.c
index dae377d..09dc34d 100644
--- a/ls-tree.c
+++ b/ls-tree.c
@@ -14,6 +14,7 @@ static int line_termination = '\n';
#define LS_SHOW_TREES 4
#define LS_NAME_ONLY 8
static int ls_options = 0;
+static int skip_chars = 0;
const char **pathspec;
static const char ls_tree_usage[] =
@@ -65,6 +66,12 @@ static int show_tree(unsigned char *sha1
else if (ls_options & LS_TREE_ONLY)
return 0;
+ /* Normalize to cwd */
+ if (baselen < skip_chars)
+ return retval;
+ base += skip_chars;
+ baselen -= skip_chars;
+
if (!(ls_options & LS_NAME_ONLY))
printf("%06o %s %s\t", mode, type, sha1_to_hex(sha1));
write_name_quoted(base, baselen, pathname, line_termination, stdout);
@@ -116,6 +123,9 @@ int main(int argc, const char **argv)
if (get_sha1(argv[1], sha1) < 0)
usage(ls_tree_usage);
+
+ if (prefix)
+ skip_chars = strlen(prefix);
pathspec = get_pathspec(prefix, argv + 2);
buf = read_object_with_reference(sha1, "tree", &size, NULL);
if (!buf)
^ permalink raw reply related
* Re: More merge questions (why doesn't this work?)
From: linux @ 2005-12-02 23:14 UTC (permalink / raw)
To: linux, torvalds; +Cc: git, junkio
In-Reply-To: <Pine.LNX.4.64.0512021409320.3099@g5.osdl.org>
> and I don't see why you wouldn't get that too.
>
> Do you have that broken version of git that had problems with "rmdir" and
> thought the unlink failed?
Quite possibly; my previous version of git was 27 November.
(I've been using the Debian package builder, which insists on a
full rebuild each time and is thus annoyingly slow... especially
the "xmlto man" part. I think I'll switch to "make; make install")
Anyway, updated and it works as expected. Sorry for the spurious
complaint.
^ permalink raw reply
* Is reserving the branch name "bisect" a good thing?
From: linux @ 2005-12-02 23:25 UTC (permalink / raw)
To: git; +Cc: linux
Just wondering... most of the "magic" references are in $GIT_DIR
directly, and ALL_CAPS. "git bisect start" begins with
"rm -f $GIT_DIR/refs/heads/bisect", which could catch someone
trying to implement a bisection algorithm in their own code.
Would it be better if "git bisect" followed that rule as well?
Otherwise, we really should document the reserved word.
Either that, or use refs/bisect/current and avoid the issue entirely.
Something like (untested):
diff --git a/git-bisect.sh b/git-bisect.sh
index 68838f3..19a8f36 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -50,7 +50,7 @@ bisect_start() {
head=$(GIT_DIR="$GIT_DIR" git-symbolic-ref HEAD) ||
die "Bad HEAD - I need a symbolic ref"
case "$head" in
- refs/heads/bisect*)
+ BISECT*)
git checkout master || exit
;;
refs/heads/*)
@@ -63,7 +63,7 @@ bisect_start() {
#
# Get rid of any old bisect state
#
- rm -f "$GIT_DIR/refs/heads/bisect"
+ rm -f "$GIT_DIR/BISECT"
rm -rf "$GIT_DIR/refs/bisect/"
mkdir "$GIT_DIR/refs/bisect"
{
@@ -146,10 +146,10 @@ bisect_next() {
fi
nr=$(eval "git-rev-list $rev $good -- $(cat $GIT_DIR/BISECT_NAMES)" | wc -l) || exit
echo "Bisecting: $nr revisions left to test after this"
- echo "$rev" > "$GIT_DIR/refs/heads/new-bisect"
- git checkout new-bisect || exit
- mv "$GIT_DIR/refs/heads/new-bisect" "$GIT_DIR/refs/heads/bisect" &&
- GIT_DIR="$GIT_DIR" git-symbolic-ref HEAD refs/heads/bisect
+ echo "$rev" > "$GIT_DIR/NEW-BISECT"
+ git checkout NEW-BISECT || exit
+ mv "$GIT_DIR/NEW-BISECT" "$GIT_DIR/BISECT" &&
+ GIT_DIR="$GIT_DIR" git-symbolic-ref HEAD BISECT
git-show-branch "$rev"
}
@@ -172,7 +172,7 @@ bisect_reset() {
esac
git checkout "$branch" &&
rm -fr "$GIT_DIR/refs/bisect"
- rm -f "$GIT_DIR/refs/heads/bisect"
+ rm -f "$GIT_DIR/BISECT"
rm -f "$GIT_DIR/BISECT_LOG"
}
^ permalink raw reply related
* Re: Is reserving the branch name "bisect" a good thing?
From: Junio C Hamano @ 2005-12-02 23:44 UTC (permalink / raw)
To: git
In-Reply-To: <20051202232555.13082.qmail@science.horizon.com>
<linux <at> horizon.com> writes:
> Would it be better if "git bisect" followed that rule as well?
> Otherwise, we really should document the reserved word.
I wonder if you broke "git bisect visualize" with that patch.
^ permalink raw reply
* Re: git pull aborts in 50% of cases
From: Johannes Schindelin @ 2005-12-03 2:18 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Alexey Dobriyan, git
In-Reply-To: <4390B64E.20601@zytor.com>
Hi,
On Fri, 2 Dec 2005, H. Peter Anvin wrote:
> Alexey Dobriyan wrote:
> >
> > Heisenbug :-\. I'll send IP next time.
> >
>
> Actually, it turns out the two servers were running different versions; one
> 0.99.9j and one 0.99.9k. They're both running 0.99.9j now.
>
> 0.99.9k is clearly bad.
Huh? It could be slower, and it could therefore hit the maximum client
count faster, but it should not be bad.
All changes to pull were done in a manner so as to be backward compatible.
In both ways.
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH] Include Makefile.localdef in Makefile, if it exists.
From: Johannes Schindelin @ 2005-12-03 2:23 UTC (permalink / raw)
To: Jason Riedy; +Cc: git
In-Reply-To: <28417.1133565102@lotus.CS.Berkeley.EDU>
Hi,
On Fri, 2 Dec 2005, Jason Riedy wrote:
> Makefile.localdef is just a hook for local definitions. Users
> can track their definitions in a branch and not worry about
> merge conflicts.
I wonder why you do not just override them in config.mak, which was
introduced just for that purpose...
Hth,
Dscho
^ permalink raw reply
* Re: git pull aborts in 50% of cases
From: Junio C Hamano @ 2005-12-03 2:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, H. Peter Anvin
In-Reply-To: <Pine.LNX.4.63.0512030316520.19086@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> 0.99.9k is clearly bad.
>
> Huh? It could be slower, and it could therefore hit the maximum client
> count faster, but it should not be bad.
>
> All changes to pull were done in a manner so as to be backward compatible.
> In both ways.
I do not think the fetch-pack common computation changes is
involved in this problem at all.
What is suspect is the repository validity check code,
specifically (quoting from diff between 0.99.9j and 0.99.9k
daemon.c::path_ok() function):
+ /* The validation is done on the paths after enter_repo
+ * canonicalization, so whitelist should be written in
+ * terms of real pathnames (i.e. after ~user is expanded
+ * and symlinks resolved).
+ */
I suspect (but have not heard back from HPA to confirm) that
kernel.org runs git-daemon with /pub/scm as the whitelist, but
there is a symbolic link (or bind mount?) involved, and the real
path checked based on getcwd() return value is somewhere else.
^ permalink raw reply
* Re: [PATCH] Move couple of ifdefs after "include config.mk"
From: Johannes Schindelin @ 2005-12-03 2:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Timo Hirvonen, git
In-Reply-To: <7vmzjlkx2f.fsf@assigned-by-dhcp.cox.net>
Hi,
On Thu, 1 Dec 2005, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > But it is only one line, heck only 20 bytes!
>
> Hey, don't get so piped up. Timo's patch has already been
> merged (thanks, Timo).
In case I did not make it clear: I was not mad or something like that. I
only see 3 ways to go about that particular problem:
- maintain your private config.mak
- maintain your private Make (shell script)
- maintain your private Makefile
I actually did the third way for a while, always merging the newest
version. But all of a sudden -- when I was working on another project,
which *has* a config.mak -- I had the idea to do the first way.
Actually, the second way falls a little bit short for some of my
applications: I sometimes override settings in the first part of the
Makefile. This is not possible with Make.
> If you need an override, you have to write down and maintain
> those YesPlease _somewhere_ yourself anyway, outside what I
> ship. Either "config.mak" or "Make" script.
As mentioned, with the difference that you just can't override some things
in Make.
> If we have '-include' in the Makefile, we need to make a
> decision if what we are adding to the Makefile should be
> overridable by that config.mak every time, exactly because
> whatever is included becomes part of the Makefile. IOW, that
> "only 20 bytes" adds work for the Makefile maintainer.
... which might have another (desired) effect: the structure of the
Makefile is better. More organized.
Besides, if you change things in an organized Makefile, you tend to be a
little bit more careful where you put things, so the cost of maintaining
is not really high (happened to me...).
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH 7/9] Add the accurate changeset applyer
From: Eric Wong @ 2005-12-03 2:51 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git list, Martin Langhoff
In-Reply-To: <46a038f90512010902lb11c326p99af9ff99dacf9b4@mail.gmail.com>
Martin Langhoff <martin.langhoff@gmail.com> wrote:
> Eric,
>
> My test results are a bit of a mixed bag. On one hand, I'm satisfied
> that both fast and correct imports reach the same tree (minus file
> modes) for the same commit with the arch repos I imported.
>
> On the other hand, with my "moodle" repo, the 'correct' import seems
> to have stop importing a lot earlier than it should have. I am
> re-running it now to try to continue from where it left off, but it's
> unclear why it abandoned -- I didn't see any error. How widely have
> you tested this method?
This was from the moodle repo I archive-mirrored locally a few weeks ago
for testing:
get_new: 6
get_tag: 0
import_or_tag: 0
replay: 356
Rerunning it doesn't seem to pull anymore. IIRC, My previous times
only imported around ~150 patchsets. The time it took to run this
was certainly longer than the last run (~4 hours here, vs ~2 hours
I mentioned in <20051124074605.GA4789@mail.yhbt.net>, so there may
be a bug somewhere... Unfortunately, I no longer have those old
trees around.
I've imported several trees with >1000 revisions without problems,
mpd-uclinux is among them:
http://mpd.bogomips.org/mpd-uclinux.git/
--
Eric Wong
^ permalink raw reply
* managing my first project with git, yeay
From: Randal L. Schwartz @ 2005-12-03 3:24 UTC (permalink / raw)
To: git
So, between yesterday and today, I issued "git-init-db", followed by
enough commands to have done this:
git-diff-tree -p -M 1723 HEAD | git-apply --stat --summary
lib/GC/App/change_transactions.tt | 4 -
lib/GC/App/edit_snippets.pm | 2
lib/GC/App/generate_aged_receivables.tt | 2
lib/GC/App/make_manifest.tt | 2
lib/GC/App/record_adjustment.tt | 11 +-
lib/GC/App/record_payment.pm | 7 +
lib/GC/App/record_payment.tt | 7 +
lib/GC/App/snippet.pm | 3
lib/GC/App/snippet.tt | 2
lib/GC/App/welcome.pm | 2
lib/GC/App/welcome.tt | 1
lib/GC/DB.pm | 11 ++
lib/GC/DB/Booking.pm | 28 ----
lib/GC/DB/PersonCruise.pm | 3
lib/GC/DB/Phone.cfg | 1
lib/GC/DB/all.pm | 20 ++-
lib/GC/DB/randal-funcs-4 | 2
lib/GC/DB/randal-funcs-5 | 132 ++++++++++++++++++++
lib/GC/DB/randal-funcs-6 | 14 ++
lib/GC/ttlib/pcs_to_ar.tt | 14 +-
lib/GC/ttlib/pcs_to_matrix.tt | 3
lib/GC/ttlib/view/amount_with_button.tt | 15 ++
.../view/combo_select_person_ccs_for_payment.tt | 31 ++++-
23 files changed, 251 insertions(+), 66 deletions(-)
create mode 100644 lib/GC/DB/randal-funcs-5
create mode 100644 lib/GC/DB/randal-funcs-6
create mode 100644 lib/GC/ttlib/view/amount_with_button.tt
This was on Darwin. yeay.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: git pull aborts in 50% of cases
From: H. Peter Anvin @ 2005-12-03 4:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vu0dq29wg.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>
>>>0.99.9k is clearly bad.
>>
>>Huh? It could be slower, and it could therefore hit the maximum client
>>count faster, but it should not be bad.
>>
>>All changes to pull were done in a manner so as to be backward compatible.
>>In both ways.
>
>
> I do not think the fetch-pack common computation changes is
> involved in this problem at all.
>
> What is suspect is the repository validity check code,
> specifically (quoting from diff between 0.99.9j and 0.99.9k
> daemon.c::path_ok() function):
>
> + /* The validation is done on the paths after enter_repo
> + * canonicalization, so whitelist should be written in
> + * terms of real pathnames (i.e. after ~user is expanded
> + * and symlinks resolved).
> + */
>
> I suspect (but have not heard back from HPA to confirm) that
> kernel.org runs git-daemon with /pub/scm as the whitelist, but
> there is a symbolic link (or bind mount?) involved, and the real
> path checked based on getcwd() return value is somewhere else.
/pub is a symbolic link. We shouldn't rely on getcwd() for this kind of
stuff; it's bad for a whole bunch of reasons.
-hpa
^ permalink raw reply
* Re: [PATCH] Include Makefile.localdef in Makefile, if it exists.
From: Jason Riedy @ 2005-12-03 6:35 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0512030322410.19086@wbgn013.biozentrum.uni-wuerzburg.de>
And Johannes Schindelin writes:
- I wonder why you do not just override them in config.mak, which was
- introduced just for that purpose...
'Cause I'm a git and didn't notice it, thanks. The prefix stuff
probably ought to be moved below the -include config.mak so
someone need only change $(prefix) and not the rest. I might
send along such a patch, along with a note about config.mak in
INSTALL...
Jason
^ permalink raw reply
* Re: How can I specify a non-standard TCP port for a git+ssh connection?
From: Andreas Jochens @ 2005-12-03 8:06 UTC (permalink / raw)
To: linux; +Cc: git, torvalds
In-Reply-To: <20051202193101.29853.qmail@science.horizon.com>
On 05-Dec-02 14:31, linux@horizon.com wrote:
> Actually, you don't need any git support. ssh allows you to set up
> "virtual hosts" with any combination of options you like.
> So typing "ssh <virtual>" will have the effect of
> ssh <whoever>@<physical> -p <nonstandard> -i <custom> -a
This is a nice feature, of course. But I still have to edit a separate
config file. In some cases (e.g. scripts using ad hoc port forwarding) it
would be much easier if the non-standard port and maybe some other
options could be specified directly on the git command line or
in .git/branches.
Regards
Andreas Jochens
^ permalink raw reply
* Re: git pull aborts in 50% of cases
From: Junio C Hamano @ 2005-12-03 9:45 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Johannes Schindelin, git
In-Reply-To: <43911D9E.5030803@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
> /pub is a symbolic link. We shouldn't rely on getcwd() for this kind of
> stuff; it's bad for a whole bunch of reasons.
Well, if I recall correctly it was done this way because
DWIMmery needs to be done before the validation.
Anyway, here is a rewrite of tonight (I resurrected your "belts
and suspenders paranoia patch" for this). Would appreciate it
if people can try this out (in the proposed updates branch).
The rules (in 0.99.9k and "master" so far) have been that if you
have symlinked public, whitelist should say what the canonical
names of them are (and the way canonical names are obtained were
getcwd()). The rule of this patch is different: whitelist says
what the remote requestor can ask for. So if your /pub is a
symlink to /mnt/mnt1/pub, you do not have to say /mnt/mnt1/pub
to export it. Instead you whitelist /pub (or /pub/scm). Also
if your ~bob is /home1/bob and ~alice is /home2/alice, you do
not say "/home1 /home2" -- instead, you say "~alice ~bob".
-- >8 --
Subject: [PATCH] daemon.c and path.enter_repo(): revamp path validation.
The whitelist of git-daemon is checked against return value from
enter_repo(), and enter_repo() used to return the value obtained
from getcwd() to avoid directory aliasing issues as discussed
earier (mid October 2005).
Unfortunately, it did not go well as we hoped.
For example, /pub on a kernel.org public machine is a symlink to
its real mountpoint, and it is understandable that the
administrator does not want to adjust the whitelist every time
/pub needs to point at a different partition for storage
allcation or whatever reasons. Being able to keep using
/pub/scm as the whitelist is a desirable property.
So this version of enter_repo() reports what it used to chdir()
and validate, but does not use getcwd() to canonicalize the
directory name. When it sees a user relative path ~user/path,
it internally resolves it to try chdir() there, but it still
reports ~user/path (possibly after appending .git if allowed to
do so, in which case it would report ~user/path.git).
What this means is that if a whitelist wants to allow a user
relative path, it needs to say "~" (for all users) or list user
home directories like "~alice" "~bob". And no, you cannot say
/home if the advertised way to access user home directories are
~alice,~bob, etc. The whole point of this is to avoid
unnecessary aliasing issues.
Anyway, because of this, daemon needs to do a bit more work to
guard itself. Namely, it needs to make sure that the accessor
does not try to exploit its leading path match rule by inserting
/../ in the middle or hanging /.. at the end. I resurrected the
belts and suspender paranoia code HPA did for this purpose.
This check cannot be done in the enter_repo() unconditionally,
because there are valid callers of enter_repo() that want to
honor /../; authorized users coming over ssh to run send-pack
and fetch-pack should be allowed to do so.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
daemon.c | 64 ++++++++++++++++++++++++--
path.c | 153 ++++++++++++++++++++++++++++++++++++++++----------------------
2 files changed, 159 insertions(+), 58 deletions(-)
018c8d740d18b7fe7d9d5a24fc1d008e29d70bc4
diff --git a/daemon.c b/daemon.c
index 91b9656..539f6e8 100644
--- a/daemon.c
+++ b/daemon.c
@@ -82,9 +82,63 @@ static void loginfo(const char *err, ...
va_end(params);
}
+static int avoid_alias(char *p)
+{
+ int sl, ndot;
+
+ /*
+ * This resurrects the belts and suspenders paranoia check by HPA
+ * done in <435560F7.4080006@zytor.com> thread, now enter_repo()
+ * does not do getcwd() based path canonicalizations.
+ *
+ * sl becomes true immediately after seeing '/' and continues to
+ * be true as long as dots continue after that without intervening
+ * non-dot character.
+ */
+ if (!p || (*p != '/' && *p != '~'))
+ return -1;
+ sl = 1; ndot = 0;
+ p++;
+
+ while (1) {
+ char ch = *p++;
+ if (sl) {
+ if (ch == '.')
+ ndot++;
+ else if (ch == '/') {
+ if (ndot < 3)
+ /* reject //, /./ and /../ */
+ return -1;
+ ndot = 0;
+ }
+ else if (ch == 0) {
+ if (0 < ndot && ndot < 3)
+ /* reject /.$ and /..$ */
+ return -1;
+ return 0;
+ }
+ else
+ sl = ndot = 0;
+ }
+ else if (ch == 0)
+ return 0;
+ else if (ch == '/') {
+ sl = 1;
+ ndot = 0;
+ }
+ }
+}
+
static char *path_ok(char *dir)
{
- char *path = enter_repo(dir, strict_paths);
+ char *path;
+
+ if (avoid_alias(dir)) {
+ logerror("'%s': aliased", dir);
+ return NULL;
+ }
+
+ path = enter_repo(dir, strict_paths);
if (!path) {
logerror("'%s': unable to chdir or not a git archive", dir);
@@ -96,9 +150,11 @@ static char *path_ok(char *dir)
int pathlen = strlen(path);
/* The validation is done on the paths after enter_repo
- * canonicalization, so whitelist should be written in
- * terms of real pathnames (i.e. after ~user is expanded
- * and symlinks resolved).
+ * appends optional {.git,.git/.git} and friends, but
+ * it does not use getcwd(). So if your /pub is
+ * a symlink to /mnt/pub, you can whitelist /pub and
+ * do not have to say /mnt/pub.
+ * Do not say /pub/.
*/
for ( pp = ok_paths ; *pp ; pp++ ) {
int len = strlen(*pp);
diff --git a/path.c b/path.c
index 2c077c0..334b2bd 100644
--- a/path.c
+++ b/path.c
@@ -131,76 +131,121 @@ int validate_symref(const char *path)
return -1;
}
-static char *current_dir(void)
+static char *user_path(char *buf, char *path, int sz)
{
- return getcwd(pathname, sizeof(pathname));
-}
-
-static int user_chdir(char *path)
-{
- char *dir = path;
+ struct passwd *pw;
+ char *slash;
+ int len, baselen;
- if(*dir == '~') { /* user-relative path */
- struct passwd *pw;
- char *slash = strchr(dir, '/');
-
- dir++;
- /* '~/' and '~' (no slash) means users own home-dir */
- if(!*dir || *dir == '/')
- pw = getpwuid(getuid());
- else {
- if (slash) {
- *slash = '\0';
- pw = getpwnam(dir);
- *slash = '/';
- }
- else
- pw = getpwnam(dir);
+ if (!path || path[0] != '~')
+ return NULL;
+ path++;
+ slash = strchr(path, '/');
+ if (path[0] == '/' || !path[0]) {
+ pw = getpwuid(getuid());
+ }
+ else {
+ if (slash) {
+ *slash = 0;
+ pw = getpwnam(path);
+ *slash = '/';
}
-
- /* make sure we got something back that we can chdir() to */
- if(!pw || chdir(pw->pw_dir) < 0)
- return -1;
-
- if(!slash || !slash[1]) /* no path following username */
- return 0;
-
- dir = slash + 1;
+ else
+ pw = getpwnam(path);
}
-
- /* ~foo/path/to/repo is now path/to/repo and we're in foo's homedir */
- if(chdir(dir) < 0)
- return -1;
-
- return 0;
+ if (!pw || !pw->pw_dir || sz <= strlen(pw->pw_dir))
+ return NULL;
+ baselen = strlen(pw->pw_dir);
+ memcpy(buf, pw->pw_dir, baselen);
+ while ((1 < baselen) && (buf[baselen-1] == '/')) {
+ buf[baselen-1] = 0;
+ baselen--;
+ }
+ if (slash && slash[1]) {
+ len = strlen(slash);
+ if (sz <= baselen + len)
+ return NULL;
+ memcpy(buf + baselen, slash, len + 1);
+ }
+ return buf;
}
+/*
+ * First, one directory to try is determined by the following algorithm.
+ *
+ * (0) If "strict" is given, the path is used as given and no DWIM is
+ * done. Otherwise:
+ * (1) "~/path" to mean path under the running user's home directory;
+ * (2) "~user/path" to mean path under named user's home directory;
+ * (3) "relative/path" to mean cwd relative directory; or
+ * (4) "/absolute/path" to mean absolute directory.
+ *
+ * Unless "strict" is given, we try access() for existence of "%s.git/.git",
+ * "%s/.git", "%s.git", "%s" in this order. The first one that exists is
+ * what we try.
+ *
+ * Second, we try chdir() to that. Upon failure, we return NULL.
+ *
+ * Then, we try if the current directory is a valid git repository.
+ * Upon failure, we return NULL.
+ *
+ * If all goes well, we return the directory we used to chdir() (but
+ * before ~user is expanded), avoiding getcwd() resolving symbolic
+ * links. User relative paths are also returned as they are given,
+ * except DWIM suffixing.
+ */
char *enter_repo(char *path, int strict)
{
- if(!path)
+ static char used_path[PATH_MAX];
+ static char validated_path[PATH_MAX];
+
+ if (!path)
return NULL;
- if (strict) {
- if (chdir(path) < 0)
+ if (!strict) {
+ static const char *suffix[] = {
+ ".git/.git", "/.git", ".git", "", NULL,
+ };
+ int len = strlen(path);
+ int i;
+ while ((1 < len) && (path[len-1] == '/')) {
+ path[len-1] = 0;
+ len--;
+ }
+ if (PATH_MAX <= len)
return NULL;
- }
- else {
- if (!*path)
- ; /* happy -- no chdir */
- else if (!user_chdir(path))
- ; /* happy -- as given */
- else if (!user_chdir(mkpath("%s.git", path)))
- ; /* happy -- uemacs --> uemacs.git */
- else
+ if (path[0] == '~') {
+ if (!user_path(used_path, path, PATH_MAX))
+ return NULL;
+ strcpy(validated_path, path);
+ path = used_path;
+ }
+ else if (PATH_MAX - 10 < len)
return NULL;
- (void)chdir(".git");
+ else {
+ path = strcpy(used_path, path);
+ strcpy(validated_path, path);
+ }
+ len = strlen(path);
+ for (i = 0; suffix[i]; i++) {
+ strcpy(path + len, suffix[i]);
+ if (!access(path, F_OK)) {
+ strcat(validated_path, suffix[i]);
+ break;
+ }
+ }
+ if (!suffix[i] || chdir(path))
+ return NULL;
+ path = validated_path;
}
+ else if (chdir(path))
+ return NULL;
- if(access("objects", X_OK) == 0 && access("refs", X_OK) == 0 &&
- validate_symref("HEAD") == 0) {
+ if (access("objects", X_OK) == 0 && access("refs", X_OK) == 0 &&
+ validate_symref("HEAD") == 0) {
putenv("GIT_DIR=.");
check_repository_format();
- return current_dir();
+ return path;
}
return NULL;
--
0.99.9.GIT
^ permalink raw reply related
* [PATCH 0/4] Merge test cases
From: Fredrik Kuivinen @ 2005-12-03 10:32 UTC (permalink / raw)
To: junkio; +Cc: git
This series adds two test cases for merge strategies. The first one
test that something sensible is done in case of directory/file
conflicts, the second one tests a criss-cross merge.
- Fredrik
^ permalink raw reply
* [PATCH 1/4] git-merge: Exit with code 2 if no strategy was able to handle the merge.
From: Fredrik Kuivinen @ 2005-12-03 10:40 UTC (permalink / raw)
To: junkio; +Cc: git
In-Reply-To: <20051203103255.GA4896@c165.ib.student.liu.se>
This way it is possible to test in scripts if the merge was non-clean
or if the strategy had other problems with the merge.
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
---
git-merge.sh | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
8fb7e4ef2b13f85966976c567cefb6a6d4c18c29
diff --git a/git-merge.sh b/git-merge.sh
index d352a3c..a221daa 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -273,7 +273,8 @@ fi
case "$best_strategy" in
'')
restorestate
- die "No merge strategy handled the merge."
+ echo >&2 "No merge strategy handled the merge."
+ exit 2
;;
"$wt_strategy")
# We already have its result in the working tree.
--
0.99.9.GIT
^ permalink raw reply related
* [PATCH 2/4] test-lib.sh: Add new function, test_expect_code
From: Fredrik Kuivinen @ 2005-12-03 10:40 UTC (permalink / raw)
To: junkio; +Cc: git
In-Reply-To: <20051203103255.GA4896@c165.ib.student.liu.se>
The test is considered OK if it exits with code $1
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
---
t/test-lib.sh | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
12ea56dda039b8b2fed61459a7a2df5ebf3dfde2
diff --git a/t/test-lib.sh b/t/test-lib.sh
index e654155..f2eccd7 100755
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -133,6 +133,19 @@ test_expect_success () {
fi
}
+test_expect_code () {
+ test "$#" = 3 ||
+ error "bug in the test script: not 3 parameters to test-expect-code"
+ say >&3 "expecting exit code $1: $3"
+ test_run_ "$3"
+ if [ "$?" = 0 -a "$eval_ret" = "$1" ]
+ then
+ test_ok_ "$2"
+ else
+ test_failure_ "$@"
+ fi
+}
+
test_done () {
trap - exit
case "$test_failure" in
--
0.99.9.GIT
^ permalink raw reply related
* [PATCH 3/4] New test case: merge with directory/file conflicts
From: Fredrik Kuivinen @ 2005-12-03 10:41 UTC (permalink / raw)
To: junkio; +Cc: git
In-Reply-To: <20051203103255.GA4896@c165.ib.student.liu.se>
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
---
t/t6020-merge-df.sh | 25 +++++++++++++++++++++++++
1 files changed, 25 insertions(+), 0 deletions(-)
create mode 100755 t/t6020-merge-df.sh
b1d7b5544a3890d2beb19286a328bc2f7e92cb6b
diff --git a/t/t6020-merge-df.sh b/t/t6020-merge-df.sh
new file mode 100755
index 0000000..a19d49d
--- /dev/null
+++ b/t/t6020-merge-df.sh
@@ -0,0 +1,25 @@
+#!/bin/sh
+#
+# Copyright (c) 2005 Fredrik Kuivinen
+#
+
+test_description='Test merge with directory/file conflicts'
+. ./test-lib.sh
+
+test_expect_success 'prepare repository' \
+'echo "Hello" > init &&
+git add init &&
+git commit -m "Initial commit" &&
+git branch B &&
+mkdir dir &&
+echo "foo" > dir/foo &&
+git add dir/foo &&
+git commit -m "File: dir/foo" &&
+git checkout B &&
+echo "file dir" > dir &&
+git add dir &&
+git commit -m "File: dir"'
+
+test_expect_code 1 'Merge with d/f conflicts' 'git merge "merge msg" B master'
+
+test_done
--
0.99.9.GIT
^ permalink raw reply related
* [PATCH 4/4] New test case: Criss-cross merge
From: Fredrik Kuivinen @ 2005-12-03 10:41 UTC (permalink / raw)
To: junkio; +Cc: git
In-Reply-To: <20051203103255.GA4896@c165.ib.student.liu.se>
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
---
t/t6021-merge-criss-cross.sh | 92 ++++++++++++++++++++++++++++++++++++++++++
1 files changed, 92 insertions(+), 0 deletions(-)
create mode 100755 t/t6021-merge-criss-cross.sh
0813848ea43ec76a07fd5bf57dfa68332513d930
diff --git a/t/t6021-merge-criss-cross.sh b/t/t6021-merge-criss-cross.sh
new file mode 100755
index 0000000..e8606c7
--- /dev/null
+++ b/t/t6021-merge-criss-cross.sh
@@ -0,0 +1,92 @@
+#!/bin/sh
+#
+# Copyright (c) 2005 Fredrik Kuivinen
+#
+
+# See http://marc.theaimsgroup.com/?l=git&m=111463358500362&w=2 for a
+# nice decription of what this is about.
+
+
+test_description='Test criss-cross merge'
+. ./test-lib.sh
+
+test_expect_success 'prepare repository' \
+'echo "1
+2
+3
+4
+5
+6
+7
+8
+9" > file &&
+git add file &&
+git commit -m "Initial commit" file &&
+git branch A &&
+git branch B &&
+git checkout A &&
+echo "1
+2
+3
+4
+5
+6
+7
+8 changed in B8, branch A
+9" > file &&
+git commit -m "B8" file &&
+git checkout B &&
+echo "1
+2
+3 changed in C3, branch B
+4
+5
+6
+7
+8
+9
+" > file &&
+git commit -m "C3" file &&
+git branch C3 &&
+git merge "pre E3 merge" B A &&
+echo "1
+2
+3 changed in E3, branch B. New file size
+4
+5
+6
+7
+8 changed in B8, branch A
+9
+" > file &&
+git commit -m "E3" file &&
+git checkout A &&
+git merge "pre D8 merge" A C3 &&
+echo "1
+2
+3 changed in C3, branch B
+4
+5
+6
+7
+8 changed in D8, branch A. New file size 2
+9" > file &&
+git commit -m D8 file'
+
+test_expect_success 'Criss-cross merge' 'git merge "final merge" A B'
+
+cat > file-expect <<EOF
+1
+2
+3 changed in E3, branch B. New file size
+4
+5
+6
+7
+8 changed in D8, branch A. New file size 2
+9
+EOF
+
+test_expect_success 'Criss-cross merge result' 'cmp file file-expect'
+
+test_done
--
0.99.9.GIT
^ permalink raw reply related
* Re: [PATCH] Include Makefile.localdef in Makefile, if it exists.
From: Johannes Schindelin @ 2005-12-03 10:45 UTC (permalink / raw)
To: Jason Riedy; +Cc: git
In-Reply-To: <3061.1133591717@lotus.CS.Berkeley.EDU>
Hi,
On Fri, 2 Dec 2005, Jason Riedy wrote:
> And Johannes Schindelin writes:
> - I wonder why you do not just override them in config.mak, which was
> - introduced just for that purpose...
>
> 'Cause I'm a git and didn't notice it, thanks.
Nopraw.
> The prefix stuff probably ought to be moved below the -include
> config.mak so someone need only change $(prefix) and not the rest. I
> might send along such a patch, along with a note about config.mak in
> INSTALL...
Actually, it is a feature that you can override prefix and template_dir
independently.
Hth,
Dscho
^ 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