* Re: Rss produced by git is not valid xml?
From: H. Peter Anvin @ 2005-11-21 9:28 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Kay Sievers, Ismail Donmez, git
In-Reply-To: <Pine.LNX.4.63.0511210937500.3931@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> Hi,
>
> On Sun, 20 Nov 2005, H. Peter Anvin wrote:
>
>
>>Johannes Schindelin wrote:
>>
>>>BTW, utf-8 was designed on purpose to be easily distinguishable from
>>>other encodings so that you don't have to rely on every document
>>>obeying a certain encoding.
>>>
>>
>>No, it wasn't. It was designated on purpose to be ASCII-compatible,
>>substring-safe, and minimally stateful.
>
>
> For the record, my information stems from
>
> http://en.wikipedia.org/wiki/Utf-8#Rationale_behind_UTF-8.27s_mechanics
>
That article is a bit confusing, as it mixes rationale with commentary.
-hpa
^ permalink raw reply
* Re: [PATCH 5/5] git-daemon support for user-relative paths.
From: Junio C Hamano @ 2005-11-21 9:28 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <437E67AC.2010400@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> I'll run the clone/fetch/push test-suite again tomorrow, with this
> applied. It looks good though.
Sorry, but there was a thinko in my butchered version of
enter_repo(). While allowing only absolute path was good for
the version with your daemon.c change, it was not with the
current one that runs upload-pack with "." as repo. In either
case we _do_ chdir() to it after validating the path, so I am
wondering if it is a good idea to keep sending "." as repo when
executing upload-pack with this patch as well. This does not
make any practical difference, but I think it makes the intent
clearer -- "we are already there so do not try going anywhere
else".
So I am thinking about applying something like this patch
on top of the last part of your patch.
- Do validation only on canonicalized paths;
- Run upload-pack with "." as repo, not full path;
- allow trailing slash under --strict-paths i.e. "git://host/my/repo.git/"
What do you think?
---
diff --git a/daemon.c b/daemon.c
index ac4c94b..21d8260 100644
--- a/daemon.c
+++ b/daemon.c
@@ -93,22 +93,19 @@ static char *path_ok(char *dir)
if ( ok_paths && *ok_paths ) {
char **pp = NULL;
- int dirlen = strlen(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).
+ */
for ( pp = ok_paths ; *pp ; pp++ ) {
int len = strlen(*pp);
- /* because of symlinks we must match both what the
- * user passed and the canonicalized path, otherwise
- * the user can send a string matching either a whitelist
- * entry or an actual directory exactly and still not
- * get through */
if (len <= pathlen && !memcmp(*pp, path, len)) {
- if (path[len] == '\0' || (!strict_paths && path[len] == '/'))
- return path;
- }
- if (len <= dirlen && !memcmp(*pp, dir, len)) {
- if (dir[len] == '\0' || (!strict_paths && dir[len] == '/'))
+ if (path[len] == '\0' ||
+ (path[len] == '/' &&
+ (!strict_paths || path[len+1] == 0)))
return path;
}
}
@@ -160,7 +157,7 @@ static int upload(char *dir)
snprintf(timeout_buf, sizeof timeout_buf, "--timeout=%u", timeout);
/* git-upload-pack only ever reads stuff, so this is safe */
- execlp("git-upload-pack", "git-upload-pack", "--strict", timeout_buf, path, NULL);
+ execlp("git-upload-pack", "git-upload-pack", "--strict", timeout_buf, ".", NULL);
return -1;
}
^ permalink raw reply related
* Re: [PATCH] Fix git.c compilation target
From: Alex Riesen @ 2005-11-21 9:24 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <81b0412b0511210010m66a3f898q6d108a799de023d9@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 171 bytes --]
There was more to it.
The patch removes a reference to git.sh from Makefile and installs
_all_ programs and scripts.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
[-- Attachment #2: 0002-forget-git.sh-and-install-all-programs-and-scripts.txt --]
[-- Type: text/plain, Size: 1267 bytes --]
Subject: [PATCH] forget git.sh and install all programs and scripts
Signed-off-by: Alex Riesen <ariesen@harmanbecker.com>
---
Makefile | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
applies-to: 0d9013b9e1804aa68afbc6328d9cf93f36a6bebe
c32490dd373e0fb8b963aa0d2aa31f8a209e09b1
diff --git a/Makefile b/Makefile
index 65b948b..f6f4b87 100644
--- a/Makefile
+++ b/Makefile
@@ -352,7 +352,7 @@ git$(X): git.c Makefile
$(CC) -DGIT_EXEC_PATH='"$(bindir)"' -DGIT_VERSION='"$(GIT_VERSION)"' \
$(CFLAGS) $< -o $@
-$(filter-out git,$(patsubst %.sh,%,$(SCRIPT_SH))) : % : %.sh
+$(patsubst %.sh,%,$(SCRIPT_SH)) : % : %.sh
rm -f $@
sed -e '1s|#!.*/sh|#!$(call shq,$(SHELL_PATH))|' \
-e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
@@ -436,9 +436,9 @@ check:
### Installation rules
-install: $(PROGRAMS) $(SCRIPTS) git
+install: $(PROGRAMS) $(SCRIPTS) git$(X)
$(INSTALL) -d -m755 $(call shellquote,$(DESTDIR)$(bindir))
- $(INSTALL) git $(PROGRAMS) $(SCRIPTS) $(call shellquote,$(DESTDIR)$(bindir))
+ $(INSTALL) $+ $(call shellquote,$(DESTDIR)$(bindir))
$(MAKE) -C templates install
$(INSTALL) -d -m755 $(call shellquote,$(DESTDIR)$(GIT_PYTHON_DIR))
$(INSTALL) $(PYMODULES) $(call shellquote,$(DESTDIR)$(GIT_PYTHON_DIR))
---
0.99.9.GIT
^ permalink raw reply related
* Re: [PATCH] fix cg-fetch so that it doesn't use -d (to work with POSIX cp)
From: Andreas Ericsson @ 2005-11-21 8:46 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <863blq4p4x.fsf@blue.stonehenge.com>
Randal L. Schwartz wrote:
> I simply removed -d, since I don't know how necessary it is to make
> it work better, but it seems to work fine on OSX now.
>
This enforces symrefs instead of symlinks when cloning locally. There
have been some discussions on the topic before, and the decision was to
maintain symlink support on filesystems that can do it. OTOH, Pasky
(cogito author) was all for only supporting symrefs, so perhaps he'll
accept this anyways.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Rss produced by git is not valid xml?
From: Johannes Schindelin @ 2005-11-21 8:38 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Kay Sievers, Ismail Donmez, git
In-Reply-To: <4380C03B.9090603@zytor.com>
Hi,
On Sun, 20 Nov 2005, H. Peter Anvin wrote:
> Johannes Schindelin wrote:
> >
> > BTW, utf-8 was designed on purpose to be easily distinguishable from
> > other encodings so that you don't have to rely on every document
> > obeying a certain encoding.
> >
>
> No, it wasn't. It was designated on purpose to be ASCII-compatible,
> substring-safe, and minimally stateful.
For the record, my information stems from
http://en.wikipedia.org/wiki/Utf-8#Rationale_behind_UTF-8.27s_mechanics
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH] Add Python version checks to the Makefile to automatically set WITH_OWN_SUBPROCESS_PY
From: Johannes Schindelin @ 2005-11-21 8:26 UTC (permalink / raw)
To: David S. Miller; +Cc: ryan, git, junkio
In-Reply-To: <20051120.213129.88244378.davem@davemloft.net>
Hi,
On Sun, 20 Nov 2005, David S. Miller wrote:
> From: Ryan Anderson <ryan@michonline.com>
> Date: Mon, 21 Nov 2005 00:11:22 -0500
>
> > Also rearrange some path settings in the Makefile in the process.
> >
> > Signed-off-by: Ryan Anderson <ryan@michonline.com>
>
> Looks good from here.
Not from here... I don't have it ;-) Care to share?
Ciao,
Dscho
^ permalink raw reply
* [PATCH] enter_repo missing its prototype
From: Alex Riesen @ 2005-11-21 8:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 88 bytes --]
enter_repo was missing its prototype
Signed-off-by: Alex Riesen <ariesen@gmail.com>
[-- Attachment #2: 0001-enter_repo-missing-its-prototype.txt --]
[-- Type: text/plain, Size: 935 bytes --]
Subject: [PATCH] enter_repo missing its prototype
(cherry picked from 00de97b561c4114e89a8d2f5c8af08403278d8fa commit)
Signed-off-by: Alex Riesen <ariesen@harmanbecker.com>
---
cache.h | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
applies-to: e12ceef6841365e64bb765294235a67e9263d7de
64c38741ba2b5840990b695ec3dbaa51a3427c4b
diff --git a/cache.h b/cache.h
index a7c1bbd..80f69a7 100644
--- a/cache.h
+++ b/cache.h
@@ -204,6 +204,8 @@ int git_mkstemp(char *path, size_t n, co
int safe_create_leading_directories(char *path);
char *safe_strncpy(char *, const char *, size_t);
+extern char *enter_repo(char *path, int strict);
+
/* Read and unpack a sha1 file into memory, write memory to a sha1 file */
extern int unpack_sha1_header(z_stream *stream, void *map, unsigned long mapsize, void *buffer, unsigned long size);
extern int parse_sha1_header(char *hdr, char *type, unsigned long *sizep);
---
0.99.9.GIT
^ permalink raw reply related
* [PATCH] Fix git.c compilation target
From: Alex Riesen @ 2005-11-21 8:10 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 144 bytes --]
The target for "git" was missing $(X), strangely essential for some
exotic platform.
Signed-off-by: Alex Riesen <ariesen@harmanbecker.com>
[-- Attachment #2: 0001-fix-compilation-of-git-.exe.txt --]
[-- Type: text/plain, Size: 990 bytes --]
Subject: [PATCH] fix compilation of git(.exe)
(cherry picked from b0911b2af7c52639a2c6ae8f038ba5753f886a28 commit)
Signed-off-by: Alex Riesen <ariesen@harmanbecker.com>
---
Makefile | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
applies-to: e12ceef6841365e64bb765294235a67e9263d7de
2323c0467c437c337c0ad59e9660ccea920ff866
diff --git a/Makefile b/Makefile
index 092931a..65b948b 100644
--- a/Makefile
+++ b/Makefile
@@ -342,15 +342,15 @@ SCRIPTS = $(patsubst %.sh,%,$(SCRIPT_SH)
export prefix TAR INSTALL DESTDIR SHELL_PATH template_dir
### Build rules
-all: $(PROGRAMS) $(SCRIPTS) git
+all: $(PROGRAMS) $(SCRIPTS) git$(X)
all:
$(MAKE) -C templates
# Only use $(CFLAGS). We don't need anything else.
-git: git.c Makefile
+git$(X): git.c Makefile
$(CC) -DGIT_EXEC_PATH='"$(bindir)"' -DGIT_VERSION='"$(GIT_VERSION)"' \
- $(CFLAGS) $@.c -o $@
+ $(CFLAGS) $< -o $@
$(filter-out git,$(patsubst %.sh,%,$(SCRIPT_SH))) : % : %.sh
rm -f $@
---
0.99.9.GIT
^ permalink raw reply related
* Re: git daemon broken?
From: Junio C Hamano @ 2005-11-21 7:30 UTC (permalink / raw)
To: YOSHIFUJI Hideaki / 吉藤英明; +Cc: git
In-Reply-To: <20051121.154733.64482215.yoshfuji@linux-ipv6.org>
I think this should fix it; the problem analysis I did in my
previous mail was half-baked, and the thing about '||' vs '&&'
was completely faulty. Obviously I am not thinking straight
tonight, so I'll go to bed.
---
diff --git a/path.c b/path.c
index 84b3272..4d88947 100644
--- a/path.c
+++ b/path.c
@@ -181,7 +181,7 @@ char *enter_repo(char *path, int strict)
return NULL;
if (strict) {
- if((path[0] != '/') || chdir(path) < 0)
+ if (chdir(path) < 0)
return NULL;
}
else {
^ permalink raw reply related
* git daemon broken?
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2005-11-21 6:47 UTC (permalink / raw)
To: junkio; +Cc: yoshfuji, git
Hello.
It seems that git-daemon is broken.
(On server side)
% git daemon --verbose
(On client side)
% git pull git://git.skbuff.net/gitroot/yoshfuji/x.git
Then, we get on the server side,
:
[16660] Request for '/gitroot/yoshfuji/x.git'
fatal: '.': unable to chdir or not a git archive
[16660] Disconnected (with error)
It works if I remove "--strict" from daemon.c.
% git daemon --verbose
:
[16723] Request for '/gitroot/yoshfuji/x.git'
Packing 21 objects
[16723] Disconnected
--
YOSHIFUJI Hideaki @ USAGI Project <yoshfuji@linux-ipv6.org>
GPG-FP : 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA
^ permalink raw reply
* Re: [PATCH] Add Python version checks to the Makefile to automatically set WITH_OWN_SUBPROCESS_PY
From: David S. Miller @ 2005-11-21 5:31 UTC (permalink / raw)
To: ryan; +Cc: git, junkio
In-Reply-To: <11325498823557-git-send-email-ryan@michonline.com>
From: Ryan Anderson <ryan@michonline.com>
Date: Mon, 21 Nov 2005 00:11:22 -0500
> Also rearrange some path settings in the Makefile in the process.
>
> Signed-off-by: Ryan Anderson <ryan@michonline.com>
Looks good from here.
^ permalink raw reply
* Re: [RFC] Applying a graft to a tree and "rippling" the changes through
From: Ryan Anderson @ 2005-11-21 5:18 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: Johannes Schindelin, Yann Dirson, git
In-Reply-To: <20051121022428.GB7902@kiste.smurf.noris.de>
[-- Attachment #1: Type: text/plain, Size: 1440 bytes --]
Matthias Urlichs wrote:
> If you need a new HEAD *anyway*, then re-basing your trees would
> IMHO be a better solution.
>
> ORIG1 .. ORIG2 .. .. ORIG_HEAD
> |
> | GIT1 .. GIT2 .. .. GIT_HEAD
> | // // // \
> | // // // TAG
> NEWGIT1 .. GIT2 .. .. NEW_HEAD
> \
> NEW_TAG
>
> Those // links might be real parent pointers, which allows you to keep
> your old tags -- or not, which allows you to have a sane history. The
> good part is that you can do this incrementally, so you won't need a
> flag day.
This is exactly what the script I started this thread with does. It
would be mostly useful if someone had serious development work based of
an old, out-of-git branch, and wanted to use the git merging tools to
get it merged into something based against the current development.
I would expect that they would then want to rebase it or do something
else to clean up the mess that is created, and apply it directly to the
current development tree, rather than leaving it as part of that very
messy tree.
My other goal was to provide myself (and others) an example of using the
barebones core tools for some strange tasks that no *real* porcelain
would ever find useful.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]
^ permalink raw reply
* [PATCH] GIT: fix compilation error in pack-redundant.c
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2005-11-21 5:09 UTC (permalink / raw)
To: junkio; +Cc: git, yoshfuji
Hello.
Fix compilation error in pack-redundant.c.
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
diff --git a/pack-redundant.c b/pack-redundant.c
index fb6cb48..954dc55 100644
--- a/pack-redundant.c
+++ b/pack-redundant.c
@@ -376,11 +376,11 @@ size_t sizeof_union(struct packed_git *p
size_t get_pack_redundancy(struct pack_list *pl)
{
struct pack_list *subset;
+ size_t ret = 0;
if (pl == NULL)
return 0;
- size_t ret = 0;
while ((subset = pl->next)) {
while(subset) {
ret += sizeof_union(pl->pack, subset->pack);
--
YOSHIFUJI Hideaki @ USAGI Project <yoshfuji@linux-ipv6.org>
GPG-FP : 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA
^ permalink raw reply related
* Re: non-trivial merge failures
From: David S. Miller @ 2005-11-21 4:20 UTC (permalink / raw)
To: ryan; +Cc: git
In-Reply-To: <20051120230738.GA16861@mythryan2.michonline.com>
From: Ryan Anderson <ryan@michonline.com>
Date: Sun, 20 Nov 2005 18:07:38 -0500
> On Sun, Nov 20, 2005 at 01:49:45PM -0800, David S. Miller wrote:
> >
> > Every time I try to do a non-trivial merge, I always
> > get this:
>
> git-merge-recursive became the default merge tool recently, and Debian
> uses Python 2.3 as the default, which lacks "subprocess.py". Luckily,
> git ships a backport, so you can do:
>
> make WITH_OWN_SUBPROCESS_PY=YesPlease all doc test install install-doc
> or
> make PYTHON_PATH=/usr/bin/python2.4 all doc test install install-doc
All these ways to make it work are nice, and in fact I have
no problem with upgrading to python2.4 on my system if that
makes it work.
I have a huge problem with the fact that "make test" passes %100
cleanly even if you have the wrong python version installed. It's
amazing that this is that possible if even the most non-trivial merge
needs this Python code :-)
^ permalink raw reply
* Re: non-trivial merge failures
From: David S. Miller @ 2005-11-21 4:17 UTC (permalink / raw)
To: rayl; +Cc: git
In-Reply-To: <20051120221922.GB29291@mail.com>
From: Ray Lehtiniemi <rayl@mail.com>
Date: Sun, 20 Nov 2005 15:19:22 -0700
> On Sun, Nov 20, 2005 at 01:49:45PM -0800, David S. Miller wrote:
> >
> > It looks like it's failing to import some python module called
> > "subprocess", and I aparently don't have that installed.
> > /usr/bin/python on this Debian box is aparently python-2.3, do
> > I need to be using python-2.4 for this merge stuff to work?
>
> Define WITH_OWN_SUBPROCESS_PY in Makefile to install a copy of
> this module.
How about a version check at build or "make test" time so we can get a
sensible failure diagnostic instead of a weird cryptic "subprocess
import failure" when Python is too old? :-)
At least some better behavior than what we have now, where "make test"
still passes when you have this problem.
^ permalink raw reply
* Re: non-trivial merge failures
From: David S. Miller @ 2005-11-21 4:15 UTC (permalink / raw)
To: ismail; +Cc: git
In-Reply-To: <200511202351.42320.ismail@uludag.org.tr>
From: Ismail Donmez <ismail@uludag.org.tr>
Date: Sun, 20 Nov 2005 23:51:42 +0200
> Sunday 20 November 2005 23:49 tarihinde ^[$,1 \x7f^[(Bunlar^[$,1 Q^[(B yazm^[$,1 Q \x7f^[(Bt^[$,1 Q^[(Bn^[$,1 Q^[(Bz:
> > ImportError: No module named subprocess
>
> You need Python 2.4.x, subprocess is a new module in Python 2.4
It's amazing that "make test" passes in the presence of Python 2.3 :-)
Maybe at least a trivial version check can be added to GIT somewhere?
^ permalink raw reply
* [PATCH] fix cg-fetch so that it doesn't use -d (to work with POSIX cp)
From: Randal L. Schwartz @ 2005-11-21 4:10 UTC (permalink / raw)
To: git
I simply removed -d, since I don't know how necessary it is to make
it work better, but it seems to work fine on OSX now.
remove -d flag from cp
---
commit 3e7bc5b605f58376688f1cf195f51965becd5c3f
tree 1c53f8753ff9c31f0ff2692b64754ad48e45f143
parent 22ff47e9b3c5fc8aa2efbc5ac8690b06b868ef6f
author Randal L. Schwartz <merlyn@localhost.(none)> Sun, 20 Nov 2005 20:01:38 -0800
committer Randal L. Schwartz <merlyn@localhost.(none)> Sun, 20 Nov 2005 20:01:38 -0800
cg-fetch | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/cg-fetch b/cg-fetch
index 5a2039f..eb89ebe 100755
--- a/cg-fetch
+++ b/cg-fetch
@@ -158,7 +158,7 @@ get_local()
cp_flags_l="$cp_flags_l -L"
shift
else
- cp_flags_l="$cp_flags_l -dpR"
+ cp_flags_l="$cp_flags_l -pR"
fi
[ "$1" = "-i" ] && shift
--
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 related
* Re: [RFC] Applying a graft to a tree and "rippling" the changes through
From: Matthias Urlichs @ 2005-11-21 2:24 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Yann Dirson, git
In-Reply-To: <Pine.LNX.4.63.0511210041370.24681@wbgn013.biozentrum.uni-wuerzburg.de>
[-- Attachment #1: Type: text/plain, Size: 2069 bytes --]
Hi,
Johannes Schindelin:
> > > ORIG1 .. ORIG2 .. .. ORIG_HEAD
> > > |
> > > | GIT1 .. GIT2 .. .. GIT_HEAD
> > > | / /
> > > | / /
> > > UNIFYING_MERGE /
> > > \ /
> > > \ /
> > > NEW_HEAD_FOR_ARCHEOLOGICAL_PURPOSES
> > >
> > Note: it's not only about research (ie. something that would be static
> > for browsing only), it's also about using the results of the research
> > in further developement.
>
> Then you could base your future development on
> NEW_HEAD_FOR_ARCHEOLOGICAL_PURPOSES.
>
If you need a new HEAD *anyway*, then re-basing your trees would
IMHO be a better solution.
ORIG1 .. ORIG2 .. .. ORIG_HEAD
|
| GIT1 .. GIT2 .. .. GIT_HEAD
| // // // \
| // // // TAG
NEWGIT1 .. GIT2 .. .. NEW_HEAD
\
NEW_TAG
Those // links might be real parent pointers, which allows you to keep
your old tags -- or not, which allows you to have a sane history. The
good part is that you can do this incrementally, so you won't need a
flag day.
I seriously doubt that all of this is worth the effort, given that you
can do the same thing with a graft line... and most people could care
less whether their histor starts at 2.6.11-whatever, 2.4, or 0.11.
(*Has* anybody imported the old tarballs into git, by the way?)
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
lately waking up i'm not sure where i've been
-- Indigo Girls, "Language or the Kiss"
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Diffs "from" working directory
From: Chuck Lever @ 2005-11-21 1:53 UTC (permalink / raw)
To: J. Bruce Fields
Cc: Linus Torvalds, Blaisorblade, Chuck Lever, Catalin Marinas, git
In-Reply-To: <20051120205855.GA30346@fieldses.org>
[-- Attachment #1: Type: text/plain, Size: 660 bytes --]
J. Bruce Fields wrote:
> On Sun, Nov 20, 2005 at 10:13:32AM -0800, Linus Torvalds wrote:
>
>>On Sun, 20 Nov 2005, J. Bruce Fields wrote:
>>
>>>That's a diff *to* the working directory. My complaint was that there
>>>wasn't a convenient way to get a diff *from* the working directory.
>>
>>Something like
>>
>> git diff -R -M -p
>>
>>should do it, no?
>
>
> A "-R" option to "stg diff" would be convenient, sure.--b.
that might be an even more intuitive way to dig out what is wanted.
btw, catalin, this was bruce's patch. i'm not sure why i was listed as
the author (probably a mistake of mine when i imported his patch into my
repository). ah well.
[-- Attachment #2: cel.vcf --]
[-- Type: text/x-vcard, Size: 439 bytes --]
begin:vcard
fn:Chuck Lever
n:Lever;Charles
org:Network Appliance, Incorporated;Linux NFS Client Development
adr:535 West William Street, Suite 3100;;Center for Information Technology Integration;Ann Arbor;MI;48103-4943;USA
email;internet:cel@citi.umich.edu
title:Member of Technical Staff
tel;work:+1 734 763-4415
tel;fax:+1 734 763 4434
tel;home:+1 734 668-1089
x-mozilla-html:FALSE
url:http://www.monkey.org/~cel/
version:2.1
end:vcard
^ permalink raw reply
* [PATCH] Fix sparse warnings
From: Timo Hirvonen @ 2005-11-21 0:52 UTC (permalink / raw)
To: git, junkio
Make some functions static and convert func() function prototypes to to
func(void). Fix declaration after statement, missing declaration and
redundant declaration warnings.
Signed-off-by: Timo Hirvonen <tihirvon@gmail.com>
---
cache.h | 1 +
name-rev.c | 2 --
pack-redundant.c | 58 +++++++++++++++++++++++++++---------------------------
path.c | 2 +-
4 files changed, 31 insertions(+), 32 deletions(-)
applies-to: e12ceef6841365e64bb765294235a67e9263d7de
b29cab489ba0dbd6daf69b491978615a1a96f781
diff --git a/cache.h b/cache.h
index a7c1bbd..c7c6637 100644
--- a/cache.h
+++ b/cache.h
@@ -203,6 +203,7 @@ int git_mkstemp(char *path, size_t n, co
int safe_create_leading_directories(char *path);
char *safe_strncpy(char *, const char *, size_t);
+char *enter_repo(char *path, int strict);
/* Read and unpack a sha1 file into memory, write memory to a sha1 file */
extern int unpack_sha1_header(z_stream *stream, void *map, unsigned long mapsize, void *buffer, unsigned long size);
diff --git a/name-rev.c b/name-rev.c
index 59194f1..817e36b 100644
--- a/name-rev.c
+++ b/name-rev.c
@@ -230,8 +230,6 @@ int main(int argc, char **argv)
fwrite(p_start, p - p_start, 1, stdout);
}
} else if (all) {
- extern struct object **objs;
- extern int nr_objs;
int i;
for (i = 0; i < nr_objs; i++)
diff --git a/pack-redundant.c b/pack-redundant.c
index fb6cb48..1519385 100644
--- a/pack-redundant.c
+++ b/pack-redundant.c
@@ -11,19 +11,19 @@
static const char pack_redundant_usage[] =
"git-pack-redundant [ --verbose ] [ --alt-odb ] < --all | <.pack filename> ...>";
-int load_all_packs = 0, verbose = 0, alt_odb = 0;
+static int load_all_packs = 0, verbose = 0, alt_odb = 0;
struct llist_item {
struct llist_item *next;
char *sha1;
};
-struct llist {
+static struct llist {
struct llist_item *front;
struct llist_item *back;
size_t size;
} *all_objects; /* all objects which must be present in local packfiles */
-struct pack_list {
+static struct pack_list {
struct pack_list *next;
struct packed_git *pack;
struct llist *unique_objects;
@@ -36,7 +36,7 @@ struct pll {
size_t pl_size;
};
-inline void llist_free(struct llist *list)
+static inline void llist_free(struct llist *list)
{
while((list->back = list->front)) {
list->front = list->front->next;
@@ -45,14 +45,14 @@ inline void llist_free(struct llist *lis
free(list);
}
-inline void llist_init(struct llist **list)
+static inline void llist_init(struct llist **list)
{
*list = xmalloc(sizeof(struct llist));
(*list)->front = (*list)->back = NULL;
(*list)->size = 0;
}
-struct llist * llist_copy(struct llist *list)
+static struct llist * llist_copy(struct llist *list)
{
struct llist *ret;
struct llist_item *new, *old, *prev;
@@ -79,7 +79,7 @@ struct llist * llist_copy(struct llist *
return ret;
}
-inline struct llist_item * llist_insert(struct llist *list,
+static inline struct llist_item * llist_insert(struct llist *list,
struct llist_item *after, char *sha1)
{
struct llist_item *new = xmalloc(sizeof(struct llist_item));
@@ -102,12 +102,12 @@ inline struct llist_item * llist_insert(
return new;
}
-inline struct llist_item * llist_insert_back(struct llist *list, char *sha1)
+static inline struct llist_item * llist_insert_back(struct llist *list, char *sha1)
{
return llist_insert(list, list->back, sha1);
}
-inline struct llist_item * llist_insert_sorted_unique(struct llist *list,
+static inline struct llist_item * llist_insert_sorted_unique(struct llist *list,
char *sha1, struct llist_item *hint)
{
struct llist_item *prev = NULL, *l;
@@ -129,7 +129,7 @@ inline struct llist_item * llist_insert_
}
/* returns a pointer to an item in front of sha1 */
-inline struct llist_item * llist_sorted_remove(struct llist *list, char *sha1,
+static inline struct llist_item * llist_sorted_remove(struct llist *list, char *sha1,
struct llist_item *hint)
{
struct llist_item *prev, *l;
@@ -164,7 +164,7 @@ redo_from_start:
}
/* computes A\B */
-void llist_sorted_difference_inplace(struct llist *A,
+static void llist_sorted_difference_inplace(struct llist *A,
struct llist *B)
{
struct llist_item *hint, *b;
@@ -178,7 +178,7 @@ void llist_sorted_difference_inplace(str
}
}
-inline struct pack_list * pack_list_insert(struct pack_list **pl,
+static inline struct pack_list * pack_list_insert(struct pack_list **pl,
struct pack_list *entry)
{
struct pack_list *p = xmalloc(sizeof(struct pack_list));
@@ -188,7 +188,7 @@ inline struct pack_list * pack_list_inse
return p;
}
-inline size_t pack_list_size(struct pack_list *pl)
+static inline size_t pack_list_size(struct pack_list *pl)
{
size_t ret = 0;
while(pl) {
@@ -198,7 +198,7 @@ inline size_t pack_list_size(struct pack
return ret;
}
-struct pack_list * pack_list_difference(struct pack_list *A,
+static struct pack_list * pack_list_difference(struct pack_list *A,
struct pack_list *B)
{
struct pack_list *ret, *pl;
@@ -218,7 +218,7 @@ struct pack_list * pack_list_difference(
return ret;
}
-void cmp_two_packs(struct pack_list *p1, struct pack_list *p2)
+static void cmp_two_packs(struct pack_list *p1, struct pack_list *p2)
{
int p1_off, p2_off;
void *p1_base, *p2_base;
@@ -250,7 +250,7 @@ void cmp_two_packs(struct pack_list *p1,
}
}
-void pll_insert(struct pll **pll, struct pll **hint_table)
+static void pll_insert(struct pll **pll, struct pll **hint_table)
{
struct pll *prev;
int i = (*pll)->pl_size - 1;
@@ -276,7 +276,7 @@ void pll_insert(struct pll **pll, struct
/* all the permutations have to be free()d at the same time,
* since they refer to each other
*/
-struct pll * get_all_permutations(struct pack_list *list)
+static struct pll * get_all_permutations(struct pack_list *list)
{
struct pll *subset, *pll, *new_pll = NULL; /*silence warning*/
static struct pll **hint = NULL;
@@ -323,7 +323,7 @@ struct pll * get_all_permutations(struct
return hint[0];
}
-int is_superset(struct pack_list *pl, struct llist *list)
+static int is_superset(struct pack_list *pl, struct llist *list)
{
struct llist *diff;
@@ -342,7 +342,7 @@ int is_superset(struct pack_list *pl, st
return 0;
}
-size_t sizeof_union(struct packed_git *p1, struct packed_git *p2)
+static size_t sizeof_union(struct packed_git *p1, struct packed_git *p2)
{
size_t ret = 0;
int p1_off, p2_off;
@@ -373,14 +373,14 @@ size_t sizeof_union(struct packed_git *p
}
/* another O(n^2) function ... */
-size_t get_pack_redundancy(struct pack_list *pl)
+static size_t get_pack_redundancy(struct pack_list *pl)
{
struct pack_list *subset;
+ size_t ret = 0;
if (pl == NULL)
return 0;
- size_t ret = 0;
while ((subset = pl->next)) {
while(subset) {
ret += sizeof_union(pl->pack, subset->pack);
@@ -391,7 +391,7 @@ size_t get_pack_redundancy(struct pack_l
return ret;
}
-inline size_t pack_set_bytecount(struct pack_list *pl)
+static inline size_t pack_set_bytecount(struct pack_list *pl)
{
size_t ret = 0;
while (pl) {
@@ -402,7 +402,7 @@ inline size_t pack_set_bytecount(struct
return ret;
}
-void minimize(struct pack_list **min)
+static void minimize(struct pack_list **min)
{
struct pack_list *pl, *unique = NULL,
*non_unique = NULL, *min_perm = NULL;
@@ -469,7 +469,7 @@ void minimize(struct pack_list **min)
}
}
-void load_all_objects()
+static void load_all_objects(void)
{
struct pack_list *pl = local_packs;
struct llist_item *hint, *l;
@@ -497,7 +497,7 @@ void load_all_objects()
}
/* this scales like O(n^2) */
-void cmp_local_packs()
+static void cmp_local_packs(void)
{
struct pack_list *subset, *pl = local_packs;
@@ -508,7 +508,7 @@ void cmp_local_packs()
}
}
-void scan_alt_odb_packs()
+static void scan_alt_odb_packs(void)
{
struct pack_list *local, *alt;
@@ -524,7 +524,7 @@ void scan_alt_odb_packs()
}
}
-struct pack_list * add_pack(struct packed_git *p)
+static struct pack_list * add_pack(struct packed_git *p)
{
struct pack_list l;
size_t off;
@@ -550,7 +550,7 @@ struct pack_list * add_pack(struct packe
return pack_list_insert(&altodb_packs, &l);
}
-struct pack_list * add_pack_file(char *filename)
+static struct pack_list * add_pack_file(char *filename)
{
struct packed_git *p = packed_git;
@@ -565,7 +565,7 @@ struct pack_list * add_pack_file(char *f
die("Filename %s not found in packed_git\n", filename);
}
-void load_all()
+static void load_all(void)
{
struct packed_git *p = packed_git;
diff --git a/path.c b/path.c
index d635470..84b3272 100644
--- a/path.c
+++ b/path.c
@@ -131,7 +131,7 @@ int validate_symref(const char *path)
return -1;
}
-static char *current_dir()
+static char *current_dir(void)
{
return getcwd(pathname, sizeof(pathname));
}
---
0.99.9.GIT
^ permalink raw reply related
* Re: [PATCH] merge-one-file: remove empty directories
From: Johannes Schindelin @ 2005-11-21 0:00 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0511200901450.13959@g5.osdl.org>
On Sun, 20 Nov 2005, Linus Torvalds wrote:
> [...] although if git is ever ported to VMS, I'll just have to shoot
> myself. I used VMS in -88, and the scars are _still_ fresh.
Does that mean you are opposed to my plans on porting git to C64? Hmm?
^ permalink raw reply
* Re: Get rid of .git/branches/ and .git/remotes/?
From: Johannes Schindelin @ 2005-11-20 23:58 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <200511210026.30280.Josef.Weidendorfer@gmx.de>
Hi,
On Mon, 21 Nov 2005, Josef Weidendorfer wrote:
> On Sunday 20 November 2005 19:09, Linus Torvalds wrote:
> > [branches.origin]
> > url = master.kernel.org:/pub/scm/git/git.git
> > pull = master:origin
>
> Two things:
> * base names are case insensitive. Repository shortcuts are case
> sensitive (and head names, too)
> * to get rid of .git/branches/XXX, XXX has to be allowed as
> base name. But XXX can contain anything a head name can (including ".").
Is it that important that nicks can be case sensitive or contain spaces or
dots? I.e. is it sensible to make a difference between
git pull Weidendorfer
and
git pull weidendorfer
???
Also, I'd rather write
git pull josef
than
git pull "Josef Weidendorfer, III"
> Not really a problem. Use the ' for ' syntax:
>
> [remotes]
> url = master.kernel.org:/pub/scm/git/git.git for origin
> pull = master:origin for origin
>
> Not really nice. We can not have "for" as head name.
Not really nice. Looks ugly. Violates DRY. ("for blabla" would not need to
be a problem; just enforce quotes around the name.)
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] Applying a graft to a tree and "rippling" the changes through
From: Johannes Schindelin @ 2005-11-20 23:46 UTC (permalink / raw)
To: Yann Dirson; +Cc: Matthias Urlichs, git
In-Reply-To: <20051120223249.GI3393@nowhere.earth>
Hi,
On Sun, 20 Nov 2005, Yann Dirson wrote:
> On Sun, Nov 20, 2005 at 02:24:53AM +0100, Johannes Schindelin wrote:
> >
> > ORIG1 .. ORIG2 .. .. ORIG_HEAD
> > |
> > | GIT1 .. GIT2 .. .. GIT_HEAD
> > | / /
> > | / /
> > UNIFYING_MERGE /
> > \ /
> > \ /
> > NEW_HEAD_FOR_ARCHEOLOGICAL_PURPOSES
> >
> Note: it's not only about research (ie. something that would be static
> for browsing only), it's also about using the results of the research
> in further developement.
Then you could base your future development on
NEW_HEAD_FOR_ARCHEOLOGICAL_PURPOSES.
> Well, no doubt this approach can be used in many cases. But it makes
> IMHO the history somewhat confusing, and has limitations. Let's say I
> had a patch against ORIG2, and at a later date I find a successor for
> it, based on GIT2. I would not have an incarnation of GIT2 with ORIG2
> as ancestor: to be on the safe side I would have had to duplicate the
> whole GIT1..* history.
You could still branch from GIT2, cherry picking from the patch to ORIG2,
and then committing the successor based on GIT2, thus reinstating the
hypothetical history.
Note: the history may be confusing, but ask any history teacher: history
*is* confusing! It is all about people. If you want to make it less
confusing, I am afraid you have to leave the path of true history.
> And after I have done some work on my branch of duplicate commits, if
> I used the type of unifying merges you suggest, I'm stuck forever with
> the old GIT1..GIT_HEAD line, whether I need it or not (if it comes
> from import of 2.4 patches, and thus has no signed tags whatsoever, I
> do not need it any more).
But the GIT1..GIT_HEAD line was actually the correct history! Remember: He
who forgets his past is doomed to repeat his mistakes! Don't pretend that
the past was different than it was. It's not worth the hassle.
Ciao,
Dscho
^ permalink raw reply
* Re: non-trivial merge failures
From: Johannes Schindelin @ 2005-11-20 23:39 UTC (permalink / raw)
To: Ismail Donmez; +Cc: git
In-Reply-To: <200511202351.42320.ismail@uludag.org.tr>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 477 bytes --]
Hi,
On Sun, 20 Nov 2005, Ismail Donmez wrote:
> Sunday 20 November 2005 23:49 tarihinde ÿÿunlarÿÿ yazmÿÿÿÿtÿÿnÿÿz:
> > ImportError: No module named subprocess
>
> You need Python 2.4.x, subprocess is a new module in Python 2.4
No, you don't need 2.4, but at least 2.3. If you don't install git, but
run it from where you compile it, be sure to set GIT_PYTHON_PATH in your
config.mak. In any case, you need to set WITH_OWN_SUBPROCESS_PY for 2.3
Hth,
Dscho
^ permalink raw reply
* Re: Teach "approxidate" about weekday syntax
From: Johannes Schindelin @ 2005-11-20 23:36 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: git
In-Reply-To: <pan.2005.11.18.18.07.37.819505@smurf.noris.de>
Hi,
On Fri, 18 Nov 2005, Matthias Urlichs wrote:
> Linus Torvalds wrote:
> > I'm sorry, but having "git log --since=confusion" would just be
> > irresponsible.
> >
> Possibly, but on the other hand there'd be a lot more truth in these than
> in our current month names. (November hasn't been the ninth month for
> *some* time now...)
Well, I know a girl who gave birth to her child in November. And I guess
she's not the only one.
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