* Re: no "uname -o" on Mac OSX
From: Junio C Hamano @ 2005-10-09 19:27 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Randal L. Schwartz, git
In-Reply-To: <86k6gnm0sz.fsf@blue.stonehenge.com>
merlyn@stonehenge.com (Randal L. Schwartz) writes:
> Recently, a change was made to git/Makefile to invoke "uname -o".
> This isn't portable to OSX/Darwin. Is there a chance this information
> can be obtained some other way, or not invoked on darwni?
Peter, I noticed the same on Solaris recently.
The following seems to work but is quite yucky, and I prefer
somebody to come up with a better alternative.
------------
Makefile: 'uname -o' is not portable.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/Makefile b/Makefile
index 7ba3eeb..ba048cb 100644
--- a/Makefile
+++ b/Makefile
@@ -180,7 +180,7 @@ ifeq ($(shell uname -s),SunOS)
TAR = gtar
PLATFORM_DEFINES += -D__EXTENSIONS__
endif
-ifeq ($(shell uname -o),Cygwin)
+ifeq ($(shell sh -c 'uname -o 2>/dev/null || echo not'),Cygwin)
NO_STRCASESTR = YesPlease
NEEDS_LIBICONV = YesPlease
NO_IPV6 = YesPlease
^ permalink raw reply related
* [PATCH 1/2] Fix git-verify-tag for local tags
From: Paolo 'Blaisorblade' Giarrusso @ 2005-10-09 18:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
From: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
It currently exits printing "git-cat-file SHA1: bad file", while instead we must
just abort the verification for local tags (i.e. referring to commit objects).
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
---
git-verify-tag.sh | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/git-verify-tag.sh b/git-verify-tag.sh
--- a/git-verify-tag.sh
+++ b/git-verify-tag.sh
@@ -3,6 +3,10 @@
tag=$(git-rev-parse $1) || exit 1
+type=$(git-cat-file -t $tag) || exit 1
+[ "$type" = "commit" ] && die "Light tag - verification impossible"
+[ "$type" = "tag" ] || die "Bad tag - SHA1 doesn't refer to a tag object nor to a commit one."
+
git-cat-file tag $tag > .tmp-vtag || exit 1
cat .tmp-vtag | sed '/-----BEGIN PGP/Q' | gpg --verify .tmp-vtag - || exit 1
rm -f .tmp-vtag
^ permalink raw reply
* [PATCH 2/2] git-verify-tag: detect wrong syntax
From: Paolo 'Blaisorblade' Giarrusso @ 2005-10-09 18:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20051009181246.17885.81654.stgit@zion.home.lan>
From: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Print proper error messages when failing, and handle -h/--help to avoid, if
possible, to print double error message (from git-cat-file and from
git-verify-tag).
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
---
git-verify-tag.sh | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/git-verify-tag.sh b/git-verify-tag.sh
--- a/git-verify-tag.sh
+++ b/git-verify-tag.sh
@@ -1,9 +1,16 @@
#!/bin/sh
. git-sh-setup || die "Not a git archive"
+usage() {
+ die "usage: git-verify-tag <tag>"
+}
+
+[ $# = 1 ] || usage
+[ "$1" = "-h" -o "$1" = "--help" ] && usage
+
tag=$(git-rev-parse $1) || exit 1
-type=$(git-cat-file -t $tag) || exit 1
+type=$(git-cat-file -t $tag) || usage
[ "$type" = "commit" ] && die "Light tag - verification impossible"
[ "$type" = "tag" ] || die "Bad tag - SHA1 doesn't refer to a tag object nor to a commit one."
^ permalink raw reply
* Problems cloning
From: Nico -telmich- Schottelius @ 2005-10-09 14:15 UTC (permalink / raw)
To: Git Mailing List
[-- Attachment #1: Type: text/plain, Size: 1287 bytes --]
Cloning gitweb from kernel.org fails:
----------------------------------------------------------------------
[16:10] hydrogenium:build% cg-clone http://www.kernel.org/pub/scm/git/gitweb.git
defaulting to local storage area
16:10:35 URL:http://www.kernel.org/pub/scm/git/gitweb.git/HEAD [41/41] -> "refs/heads/.origin-fetching" [1]
progress: 84 objects, 295012 bytes
Getting pack list
Getting alternates list
error: Unable to find d263a6bd453df849c9f9211f1966c830c3cf913a under http://www.kernel.org/pub/scm/git/gitweb.git/
Cannot obtain needed commit d263a6bd453df849c9f9211f1966c830c3cf913a
while processing commit f5dfb3f6a6655d4d60fdd0aaeef7b5b14226147f.
cg-fetch: objects fetch failed
cg-clone: fetch failed
----------------------------------------------------------------------
Info:
----------------------------------------------------------------------
[16:01] hydrogenium:cinit% cg --version
cogito-0.15.1 (cfeac5893d97b830ac31b9d41951c30f80967410)
[16:13] hydrogenium:cinit% git --version
git version 0.99.7d
----------------------------------------------------------------------
Greetings,
Nico
--
Latest project: cconfig (http://nico.schotteli.us/papers/linux/cconfig/)
Open Source nutures open minds and free, creative developers.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 827 bytes --]
^ permalink raw reply
* Re: Seeing various mode changes on cygwin
From: Alex Riesen @ 2005-10-09 13:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzmpjoa32.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano, Sun, Oct 09, 2005 01:36:17 +0200:
> > These are not real attributes, cygwin emulates them from the names,
> > like .exe will always be 0755, for example.
>
> Ouch. Is this true in general, or only on FAT-derived
> filesystems?
>
Before they are chmod'ed by cygwin (with chmod): probably everywhere
on windows (I'm sure about vfat, were chmod wont help at all). Even
if you can save user (unix) attributes somewhere, initial clone will
still always have this problem.
^ permalink raw reply
* Use the same move_temp_to_file in git-http-fetch.
From: Junio C Hamano @ 2005-10-09 10:42 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <Pine.LNX.4.63.0510072124290.23242@iabervon.org>
The http commit walker cannot use the same temporary file
creation code because it needs to use predictable temporary
filename for partial fetch continuation purposes, but the code
to move the temporary file to the final location should be
usable from the ordinary object creation case.
Export move_temp_to_file from sha1_file.c and use it, while
losing the custom relink_or_rename function from http-fetch.c.
Also the temporary object file creation part needs to make sure
the leading path exists, in preparation of the really lazy
fan-out directory creation.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Daniel Barkalow <barkalow@iabervon.org> writes:
> This looks right to me, but it would be nice to also split out and
> share the temp file creation. Also, http-fetch.c writes object files and
> needs at least move_temp_to_file() if it's going to do special stuff.
I agree. The proposed updates branch has this patch.
cache.h | 1 +
http-fetch.c | 47 ++++++++++++++++++-----------------------------
sha1_file.c | 2 +-
3 files changed, 20 insertions(+), 30 deletions(-)
applies-to: f3741b89b850db8d343d3cde58416e076964c952
07d374bffd6fcd0c67c671902dde9402335776f5
diff --git a/cache.h b/cache.h
index 5987d4c..28077fc 100644
--- a/cache.h
+++ b/cache.h
@@ -221,6 +221,7 @@ extern int read_tree(void *buffer, unsig
extern int write_sha1_from_fd(const unsigned char *sha1, int fd, char *buffer,
size_t bufsize, size_t *bufposn);
extern int write_sha1_to_fd(int fd, const unsigned char *sha1);
+extern int move_temp_to_file(const char *tmpfile, char *filename);
extern int has_sha1_pack(const unsigned char *sha1);
extern int has_sha1_file(const unsigned char *sha1);
diff --git a/http-fetch.c b/http-fetch.c
index 5d0e3e3..c617583 100644
--- a/http-fetch.c
+++ b/http-fetch.c
@@ -138,25 +138,6 @@ static size_t fwrite_sha1_file(void *ptr
return size;
}
-int relink_or_rename(char *old, char *new) {
- int ret;
-
- ret = link(old, new);
- if (ret < 0) {
- /* Same Coda hack as in write_sha1_file(sha1_file.c) */
- ret = errno;
- if (ret == EXDEV && !rename(old, new))
- return 0;
- }
- unlink(old);
- if (ret) {
- if (ret != EEXIST)
- return ret;
- }
-
- return 0;
-}
-
#ifdef USE_CURL_MULTI
void process_curl_messages();
void process_request_queue();
@@ -295,6 +276,20 @@ void start_request(struct transfer_reque
request->local = open(request->tmpfile,
O_WRONLY | O_CREAT | O_EXCL, 0666);
+ /* This could have failed due to the "lazy directory creation";
+ * try to mkdir the last path component.
+ */
+ if (request->local < 0 && errno == ENOENT) {
+ char *dir = strrchr(request->tmpfile, '/');
+ if (dir) {
+ *dir = 0;
+ mkdir(request->tmpfile, 0777);
+ *dir = '/';
+ }
+ request->local = open(request->tmpfile,
+ O_WRONLY | O_CREAT | O_EXCL, 0666);
+ }
+
if (request->local < 0) {
request->state = ABORTED;
error("Couldn't create temporary file %s for %s: %s\n",
@@ -408,7 +403,7 @@ void finish_request(struct transfer_requ
return;
}
request->rename =
- relink_or_rename(request->tmpfile, request->filename);
+ move_temp_to_file(request->tmpfile, request->filename);
if (request->rename == 0)
pull_say("got %s\n", sha1_to_hex(request->sha1));
@@ -599,12 +594,7 @@ static int fetch_index(struct alt_base *
fclose(indexfile);
- ret = relink_or_rename(tmpfile, filename);
- if (ret)
- return error("unable to write index filename %s: %s",
- filename, strerror(ret));
-
- return 0;
+ return move_temp_to_file(tmpfile, filename);
}
static int setup_index(struct alt_base *repo, unsigned char *sha1)
@@ -869,10 +859,9 @@ static int fetch_pack(struct alt_base *r
fclose(packfile);
- ret = relink_or_rename(tmpfile, filename);
+ ret = move_temp_to_file(tmpfile, filename);
if (ret)
- return error("unable to write pack filename %s: %s",
- filename, strerror(ret));
+ return ret;
lst = &repo->packs;
while (*lst != target)
diff --git a/sha1_file.c b/sha1_file.c
index baaa4c0..6e3ea23 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1287,7 +1287,7 @@ static int link_temp_to_file(const char
/*
* Move the just written object into its final resting place
*/
-static int move_temp_to_file(const char *tmpfile, char *filename)
+int move_temp_to_file(const char *tmpfile, char *filename)
{
int ret = link_temp_to_file(tmpfile, filename);
if (ret) {
---
0.99.8.GIT
^ permalink raw reply related
* Re: [PATCH] Try URI quoting for embedded TAB and LF in pathnames
From: Junio C Hamano @ 2005-10-09 10:42 UTC (permalink / raw)
To: Robert Fitzsimons; +Cc: Alex Riesen, git, Kai Ruemmler
In-Reply-To: <20051008133032.GA32079@localhost>
Robert Fitzsimons <robfitz@273k.net> writes:
> Instead of using //{LF}// and //{TAG}// to quote embedded tab and
> linefeed characters in pathnames use URI quoting.
I changed my mind, although I still do not particularly like the
innocuous looking C-style or URI-style quoting, simply because I
feel these funny characters should stand out loudly, but at the
same time I realize that is just a matter of personal taste.
Also the list does not seem to mind losing an extra unusual
character (either backslash or per-cent) for quoting too much.
After futzing with this a bit more, I decided that C-style
quoting is the cleanest way in the longer run. I'll be talking
with the current maintainer of GNU patch about making it
understand C-style quoting in its input, when the program
operates under --quoting-style=c flag (or maybe some other
flag).
In addition to git-diff output, git-ls-files output is also
quoted for TAB and LF (and backslash) when not using '-z' in the
version I have in the "pu" branch. I haven't converted
git-ls-tree yet, but that should also be done before these
changes can graduate out of "pu" branch.
Existing Porcelains or people's scripts should not break (any
more than they currently are broken ;-). Any self-respecting
Porcelain should be either parsing '-z' output (in which case
there is no change), or parsing non '-z' output after declaring
that it does not support filenames with embedded TAB or LF (in
which case there is no new breakage, except that they have one
more character that their users cannot have in the filename --
backslash).
Here is an example output from my random repository, that has
files with TAB, LF and backslash in their names (Note that the
file "pc" + one backslash + "h.c" is shown with two backslashes).
: siamese; git status
# Updated but not checked in:
# (will commit)
#
# new file: ab\n\tc/mno
# modified: abc/mno
# renamed: def\nghi/pqr -> dee/pqr
# new file: dee/www
# modified: j k l
#
#
# Changed but not updated:
# (use git-update-index to mark for commit)
#
# deleted: abc/mno
#
#
# Ignored files:
# (use "git add" to add to commit)
#
# diff-sample
# pc\\h.c
# pch.c.orig
# quote\targ.c
# quotearg.c.orig
: siamese; git diff HEAD
diff --git a/abc/mno b/ab\n\tc/mno
similarity index 72%
rename from abc/mno
rename to ab\n\tc/mno
index 0ac2a8c..3deac99 100644
--- a/abc/mno
+++ b/ab\n\tc/mno
@@ -1 +1,3 @@
Fri Oct 7 23:18:45 PDT 2005
+foo
+foo
...
: siamese; git diff HEAD | git apply --index-info
100644 0ac2a8c8cad088c3e843689dbd833aeabf6b1870 abc/mno
100644 9ee055c103e84ffdd9ec15457481c92699d12fc8 def\nghi/pqr
...
Anyway, I'll keep this in the "pu" branch a bit longer to let
the discussion simmer.
^ permalink raw reply
* no "uname -o" on Mac OSX
From: Randal L. Schwartz @ 2005-10-09 10:39 UTC (permalink / raw)
To: git
Recently, a change was made to git/Makefile to invoke "uname -o".
This isn't portable to OSX/Darwin. Is there a chance this information
can be obtained some other way, or not invoked on darwni?
--
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: Seeing various mode changes on cygwin
From: Junio C Hamano @ 2005-10-09 6:46 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Alex Riesen, git
In-Reply-To: <Pine.LNX.4.64.0510081909250.31407@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> The more interesting issue is how to set the _flag_ that we should do
> this. We may have to add a config file, and it should be per-repository
> (ie something like ".git/config" or ".git/info/config"). Or do we just do
> yet another environment variable?
Per-repository configuration file like .git/info/config sounds
like the way to go. Long time ago, the core never read any
per-repository nor per-odb configuration file, but after grafts
and then now alternates, we started doing it, and there is no
reason to shy away from having an official configuration file
mechanism. Maybe recent HTTP related environment variables
could also be folded into it.
While we are at it, we may want to move things around to
consolidate per-repository configuration into a single placek.
Specifically, I have moving .git/remotes/ in mind.
^ permalink raw reply
* Re: Seeing various mode changes on cygwin
From: H. Peter Anvin @ 2005-10-09 3:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, git
In-Reply-To: <7vzmpjoa32.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Alex Riesen <raa.lkml@gmail.com> writes:
>
>>These are not real attributes, cygwin emulates them from the names,
>>like .exe will always be 0755, for example.
>
> Ouch. Is this true in general, or only on FAT-derived
> filesystems?
>
> We may need to worry about this on the core side after all.
> Some people need to mount FAT even on Linux systems,
>
At least on Cygwin/NTFS, you can do chmod just fine.
-hpa
^ permalink raw reply
* Re: Seeing various mode changes on cygwin
From: Linus Torvalds @ 2005-10-09 2:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, git
In-Reply-To: <7vzmpjoa32.fsf@assigned-by-dhcp.cox.net>
On Sat, 8 Oct 2005, Junio C Hamano wrote:
>
> Alex Riesen <raa.lkml@gmail.com> writes:
> > These are not real attributes, cygwin emulates them from the names,
> > like .exe will always be 0755, for example.
>
> Ouch. Is this true in general, or only on FAT-derived
> filesystems?
>
> We may need to worry about this on the core side after all.
> Some people need to mount FAT even on Linux systems,
I think we might want to have a flag that says "don't care about
filesystem modes". That should be pretty easy, I think we'd get most of
them by just adding some logic to "ce_match_stat()".
Then add a "git chmod" to set the mode in the index (which should end up
being just a wrapper around the regular "git-update-index" using the
"--cacheinfo" flag, I think).
Those parts should be trivial.
The more interesting issue is how to set the _flag_ that we should do
this. We may have to add a config file, and it should be per-repository
(ie something like ".git/config" or ".git/info/config"). Or do we just do
yet another environment variable?
Linus
^ permalink raw reply
* Re: Seeing various mode changes on cygwin
From: Junio C Hamano @ 2005-10-08 23:36 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20051008213612.GA5794@steel.home>
Alex Riesen <raa.lkml@gmail.com> writes:
> These are not real attributes, cygwin emulates them from the names,
> like .exe will always be 0755, for example.
Ouch. Is this true in general, or only on FAT-derived
filesystems?
We may need to worry about this on the core side after all.
Some people need to mount FAT even on Linux systems,
^ permalink raw reply
* Re: First cut at git port to Cygwin
From: Johannes Schindelin @ 2005-10-08 22:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Linus Torvalds
In-Reply-To: <7vk6gnpvf9.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sat, 8 Oct 2005, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Sure. Something like this?
>
> Not, really. What I meant was to rip out the writing out
> altogether, and perhaps making sure that the caller never calls
> us without MAP_PRIVATE.
How about this, then?
[PATCH] If NO_MMAP is defined, fake mmap() and munmap()
Since some platforms do not support mmap() at all, and others do only just so,
this patch introduces the option to fake mmap() and munmap() by malloc()ing the
region explicitely.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
Makefile | 6 ++++++
cache.h | 16 ++++++++++++++++
compat/mmap.c | 51 +++++++++++++++++++++++++++++++++++++++++++++++++++
mailsplit.c | 1 -
4 files changed, 73 insertions(+), 1 deletions(-)
create mode 100644 compat/mmap.c
applies-to: 274542bcbc891cca353c2728ac4075df3d1d2c0d
ed334e3e2276fe9d41ed78917544ef6a3fa87eb7
diff --git a/Makefile b/Makefile
index 1bdf4de..7ca77cf 100644
--- a/Makefile
+++ b/Makefile
@@ -27,6 +27,8 @@
# Define NEEDS_SOCKET if linking with libc is not enough (SunOS,
# Patrick Mauritz).
#
+# Define NO_MMAP if you want to avoid mmap.
+#
# Define WITH_OWN_SUBPROCESS_PY if you want to use with python 2.3.
#
# Define NO_IPV6 if you lack IPv6 support and getaddrinfo().
@@ -258,6 +260,10 @@ ifdef NO_STRCASESTR
DEFINES += -Dstrcasestr=gitstrcasestr
LIB_OBJS += compat/strcasestr.o
endif
+ifdef NO_MMAP
+ DEFINES += -Dmmap=gitfakemmap -Dmunmap=gitfakemunmap -DNO_MMAP
+ LIB_OBJS += compat/mmap.o
+endif
ifdef NO_IPV6
DEFINES += -DNO_IPV6 -Dsockaddr_storage=sockaddr_in
endif
diff --git a/cache.h b/cache.h
index 514adb8..5987d4c 100644
--- a/cache.h
+++ b/cache.h
@@ -11,7 +11,9 @@
#include <string.h>
#include <errno.h>
#include <limits.h>
+#ifndef NO_MMAP
#include <sys/mman.h>
+#endif
#include <sys/param.h>
#include <netinet/in.h>
#include <sys/types.h>
@@ -356,4 +358,18 @@ extern void packed_object_info_detail(st
/* Dumb servers support */
extern int update_server_info(int);
+#ifdef NO_MMAP
+
+#ifndef PROT_READ
+#define PROT_READ 1
+#define PROT_WRITE 2
+#define MAP_PRIVATE 1
+#define MAP_FAILED ((void*)-1)
+#endif
+
+extern void *gitfakemmap(void *start, size_t length, int prot , int flags, int fd, off_t offset);
+extern int gitfakemunmap(void *start, size_t length);
+
+#endif
+
#endif /* CACHE_H */
diff --git a/compat/mmap.c b/compat/mmap.c
new file mode 100644
index 0000000..3f035a0
--- /dev/null
+++ b/compat/mmap.c
@@ -0,0 +1,51 @@
+#include <stdio.h>
+#include <stdlib.h>
+#include <unistd.h>
+#include <errno.h>
+#include "../cache.h"
+
+void *gitfakemmap(void *start, size_t length, int prot , int flags, int fd, off_t offset)
+{
+ int n = 0;
+
+ if(start != NULL || !(flags & MAP_PRIVATE))
+ die("Invalid usage of gitfakemmap.");
+
+ if(lseek(fd, offset, SEEK_SET)<0) {
+ errno = EINVAL;
+ return MAP_FAILED;
+ }
+
+ start = xmalloc(length);
+ if(start == NULL) {
+ errno = ENOMEM;
+ return MAP_FAILED;
+ }
+
+ while(n < length) {
+ int count = read(fd, start+n, length-n);
+
+ if(count == 0) {
+ memset(start+n, 0, length-n);
+ break;
+ }
+
+ if(count < 0) {
+ free(start);
+ errno = EACCES;
+ return MAP_FAILED;
+ }
+
+ n += count;
+ }
+
+ return start;
+}
+
+int gitfakemunmap(void *start, size_t length)
+{
+ free(start);
+
+ return 0;
+}
+
diff --git a/mailsplit.c b/mailsplit.c
index 7981f87..0f8100d 100644
--- a/mailsplit.c
+++ b/mailsplit.c
@@ -9,7 +9,6 @@
#include <fcntl.h>
#include <sys/types.h>
#include <sys/stat.h>
-#include <sys/mman.h>
#include <string.h>
#include <stdio.h>
#include <ctype.h>
---
0.99.8.GIT
^ permalink raw reply related
* Re: Seeing various mode changes on cygwin
From: Alex Riesen @ 2005-10-08 21:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfyrbrgdw.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano, Sat, Oct 08, 2005 20:51:55 +0200:
> > ... It seems that cygwin overrides the previous modes and sets the
> > executable bit. git-reset doesn't fix it. Can this even be fixed
> > then?
> >
> > A few examples below ...
> >
> > jonas@cygwin /usr/local/dev/git/git
> > $ git reset
> > Documentation/sort_glossary.pl: needs update
> > t/lib-read-tree-m-3way.sh: needs update
>
> I do not have an access to Cygwin environment so cannot be of
> help on this directly, but 'git reset' without flags defaults
> "--mixed" and leaves the modified files intact. Maybe hard
> reset would help here, but the real solution is to figure out
> why these files acquired the extra executable bits in the first
> place.
These are not real attributes, cygwin emulates them from the names,
like .exe will always be 0755, for example.
^ permalink raw reply
* Re: First cut at git port to Cygwin
From: Junio C Hamano @ 2005-10-08 21:10 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Linus Torvalds
In-Reply-To: <Pine.LNX.4.63.0510082100020.26626@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> PROT_WRITE is true, but we do MAP_PRIVATE, and if I recall
>> correctly we do not write file via mmap -- at least we do not
>> intend to.
>
> Ahh! Reading the man page helps!
>
>> Yes. It might have been overkill that you supported writing
>> changes back, though.
>
> Sure. Something like this?
Not, really. What I meant was to rip out the writing out
altogether, and perhaps making sure that the caller never calls
us without MAP_PRIVATE.
^ permalink raw reply
* Re: [PATCH] Try URI quoting for embedded TAB and LF in pathnames
From: Junio C Hamano @ 2005-10-08 20:19 UTC (permalink / raw)
To: Robert Fitzsimons; +Cc: Alex Riesen, git, Kai Ruemmler, eggert
In-Reply-To: <7v64s7svya.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Robert Fitzsimons <robfitz@273k.net> writes:
>
>> '\t' becomes %09
>> '\n' becomes %10
>> '%' becomes %25
>>
>> Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
>
> This would break existing setup where people *has* per-cent
> letter in their pathname -- which I think is worse than the
> backslash proposal.
Having said that, I think something along the lines of backslash
or URI encoding is the cleanest way to go in the long run, with
one condition: diffs generated with git-diff should be
applicable with 'GNU patch', especially if there is no funnies
like renames and the recipient does not mind losing mode
information.
Although 'GNU patch' has --quoting-style flag, it seems to be
used only on its output side (i.e. reporting which file it is
patching, etc.). If we can sell changes to teach the filename
encoding convention to its util.c::fetchname() upstream, we
could tell people that 'diff --git' can be applied with newer
'GNU patch' when the patch is about a file whose name contains
'%' character (which is not that unusual, compared to TAB and
LF). While we are selling those changes to 'GNU patch', we
might be even be able to sell the other extended 'diff --git'
metainformation support.
The same filename quoting rules change should probably be sold
to 'GNU diff' as well, so that plain diff can natively quote
funny characters in its output without forcing us to fake it
by using the -L flag.
If all of the above is what we aim for, I would say that is a
good direction to go in the longer term. The double-slash hack
was just to avoid all these hassles of having to muck with other
people's tools.
^ permalink raw reply
* Re: First cut at git port to Cygwin
From: Johannes Schindelin @ 2005-10-08 19:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Linus Torvalds
In-Reply-To: <7vr7avrgr2.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sat, 8 Oct 2005, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Am I missing something? I don't see where the changes are written back to
> > the fd. After all, mmap() is called with PROT_WRITE...
>
> PROT_WRITE is true, but we do MAP_PRIVATE, and if I recall
> correctly we do not write file via mmap -- at least we do not
> intend to.
Ahh! Reading the man page helps!
> Yes. It might have been overkill that you supported writing
> changes back, though.
Sure. Something like this?
diff --git a/compat/mmap.c b/compat/mmap.c
index fca6321..fda39fc 100644
--- a/compat/mmap.c
+++ b/compat/mmap.c
@@ -49,7 +49,7 @@ void *gitfakemmap(void *start, size_t le
n += count;
}
- if(prot & PROT_WRITE) {
+ if((prot & PROT_WRITE) && !(flags & MAP_PRIVATE)) {
fakemmapwritable *next = xmalloc(sizeof(fakemmapwritable));
next->start = start;
next->length = length;
^ permalink raw reply related
* Re: Seeing various mode changes on cygwin
From: Junio C Hamano @ 2005-10-08 18:51 UTC (permalink / raw)
To: git
In-Reply-To: <20051008180023.GC28875@diku.dk>
Jonas Fonseca <fonseca@diku.dk> writes:
> ... It seems that cygwin overrides the previous
> modes and sets the executable bit. git-reset doesn't fix it. Can this even be
> fixed then?
>
> A few examples below ...
>
> jonas@cygwin /usr/local/dev/git/git
> $ git reset
> Documentation/sort_glossary.pl: needs update
> t/lib-read-tree-m-3way.sh: needs update
I do not have an access to Cygwin environment so cannot be of
help on this directly, but 'git reset' without flags defaults
"--mixed" and leaves the modified files intact. Maybe hard
reset would help here, but the real solution is to figure out
why these files acquired the extra executable bits in the first
place.
^ permalink raw reply
* Re: First cut at git port to Cygwin
From: Alex Riesen @ 2005-10-08 18:49 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Linus Torvalds, Chuck Lever, Git Mailing List, Junio C Hamano,
Christopher Faylor, H. Peter Anvin
In-Reply-To: <Pine.LNX.4.63.0510082023130.25971@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin, Sat, Oct 08, 2005 20:27:06 +0200:
> > I really think that you should just get rid of the mmap.
> >
> > As it is, you're just slowing the code down on sane architectures. That's
> > not good.
> >
> > So I'd suggest something like this instead.
> >
> > Totally untested, of course.
>
> Am I missing something? I don't see where the changes are written back to
> the fd. After all, mmap() is called with PROT_WRITE...
It's just becase the file is open for reading only.
Also, it is not an mmap/unmap implementation. Just reading cache in.
^ permalink raw reply
* Re: [PATCH] Restore functionality to allow proxies to cache objects
From: Junio C Hamano @ 2005-10-08 18:45 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: git
In-Reply-To: <20051008164045.GA8736@reactrix.com>
Nick Hengeveld <nickh@reactrix.com> writes:
> Reading the revision history is useful...
Yes, 'git whatchanged' is quite powerful.
^ permalink raw reply
* Re: First cut at git port to Cygwin
From: Junio C Hamano @ 2005-10-08 18:44 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Linus Torvalds
In-Reply-To: <Pine.LNX.4.63.0510082023130.25971@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Am I missing something? I don't see where the changes are written back to
> the fd. After all, mmap() is called with PROT_WRITE...
PROT_WRITE is true, but we do MAP_PRIVATE, and if I recall
correctly we do not write file via mmap -- at least we do not
intend to.
- index file is mapped for reading, long ago it was mapped
read-only but these days we do PROT_WRITE, but updates are
done via opening a new file and writing afresh.
- objects are mapped for reading, but, never updated once
created. Creation side is regular open - write - close.
- diff reads original by mapping, but obviously has no business
writing.
- local-fetch reads original by mapping for copying.
> *shameless plug* Of course, this problem does not come up with
> my NO_MMAP patch.
Yes. It might have been overkill that you supported writing
changes back, though.
.
^ permalink raw reply
* Re: [PATCH] Try URI quoting for embedded TAB and LF in pathnames
From: Junio C Hamano @ 2005-10-08 18:30 UTC (permalink / raw)
To: Robert Fitzsimons; +Cc: Alex Riesen, git, Kai Ruemmler
In-Reply-To: <20051008133032.GA32079@localhost>
Robert Fitzsimons <robfitz@273k.net> writes:
> Instead of using //{LF}// and //{TAG}// to quote embedded tab and
> linefeed characters in pathnames use URI quoting.
>
> '\t' becomes %09
> '\n' becomes %10
> '%' becomes %25
>
> Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
This would break existing setup where people *has* per-cent
letter in their pathname -- which I think is worse than the
backslash proposal.
^ permalink raw reply
* Re: First cut at git port to Cygwin
From: Johannes Schindelin @ 2005-10-08 18:27 UTC (permalink / raw)
To: Linus Torvalds
Cc: Alex Riesen, Chuck Lever, Git Mailing List, Junio C Hamano,
Christopher Faylor, H. Peter Anvin
In-Reply-To: <Pine.LNX.4.64.0510080900510.31407@g5.osdl.org>
Hi,
On Sat, 8 Oct 2005, Linus Torvalds wrote:
> I really think that you should just get rid of the mmap.
>
> As it is, you're just slowing the code down on sane architectures. That's
> not good.
>
> So I'd suggest something like this instead.
>
> Totally untested, of course.
Am I missing something? I don't see where the changes are written back to
the fd. After all, mmap() is called with PROT_WRITE...
*shameless plug* Of course, this problem does not come up with my NO_MMAP
patch.
Ciao,
Dscho
^ permalink raw reply
* Seeing various mode changes on cygwin
From: Jonas Fonseca @ 2005-10-08 18:00 UTC (permalink / raw)
To: git
Hi,
It seems that git on cygwin still have a few problems. I've experienced it both
when cloning with git and Cogito. It seems that cygwin overrides the previous
modes and sets the executable bit. git-reset doesn't fix it. Can this even be
fixed then?
A few examples below ...
jonas@cygwin /usr/local/dev/git/git
$ git reset
Documentation/sort_glossary.pl: needs update
t/lib-read-tree-m-3way.sh: needs update
t/t4109-apply-multifrag.sh: needs update
t/t4110-apply-scan.sh: needs update
t/t6000lib.sh: needs update
t/t6101-rev-parse-parents.sh: needs update
templates/hooks--applypatch-msg: needs update
templates/hooks--commit-msg: needs update
templates/hooks--post-commit: needs update
templates/hooks--post-update: needs update
templates/hooks--pre-applypatch: needs update
templates/hooks--pre-commit: needs update
templates/hooks--update: needs update
jonas@cygwin /usr/local/dev/git/git
$ git diff
diff --git a/Documentation/sort_glossary.pl b/Documentation/sort_glossary.pl
old mode 100644
new mode 100755
diff --git a/t/lib-read-tree-m-3way.sh b/t/lib-read-tree-m-3way.sh
old mode 100755
new mode 100644
diff --git a/t/t4109-apply-multifrag.sh b/t/t4109-apply-multifrag.sh
old mode 100644
new mode 100755
diff --git a/t/t4110-apply-scan.sh b/t/t4110-apply-scan.sh
old mode 100644
new mode 100755
diff --git a/t/t6000lib.sh b/t/t6000lib.sh
old mode 100755
new mode 100644
diff --git a/t/t6101-rev-parse-parents.sh b/t/t6101-rev-parse-parents.sh
old mode 100644
new mode 100755
diff --git a/templates/hooks--applypatch-msg b/templates/hooks--applypatch-msg
old mode 100644
new mode 100755
diff --git a/templates/hooks--commit-msg b/templates/hooks--commit-msg
old mode 100644
new mode 100755
diff --git a/templates/hooks--post-commit b/templates/hooks--post-commit
old mode 100644
new mode 100755
diff --git a/templates/hooks--post-update b/templates/hooks--post-update
old mode 100644
new mode 100755
diff --git a/templates/hooks--pre-applypatch b/templates/hooks--pre-applypatch
old mode 100644
new mode 100755
diff --git a/templates/hooks--pre-commit b/templates/hooks--pre-commit
old mode 100644
new mode 100755
diff --git a/templates/hooks--update b/templates/hooks--update
old mode 100644
new mode 100755
jonas@cygwin /usr/local/dev/git/cogito
$ cg diff debian/
diff --git a/debian/helper-scripts/make-orig.tgz
b/debian/helper-scripts/make-orig.tgz
old mode 100644
new mode 100755
diff --git a/debian/helper-scripts/make-package
b/debian/helper-scripts/make-package
old mode 100644
new mode 100755
diff --git a/debian/helper-scripts/make-test
b/debian/helper-scripts/make-test
old mode 100644
new mode 100755
jonas@cygwin /usr/local/dev/elinks/0.11
$ cg diff
diff --git a/config/config.guess b/config/config.guess
old mode 100644
new mode 100755
diff --git a/config/config.sub b/config/config.sub
old mode 100644
new mode 100755
diff --git a/contrib/conv/w3m2links.awk.in b/contrib/conv/w3m2links.awk.in
old mode 100644
new mode 100755
diff --git a/contrib/lua/bm-to-elinks-bookmarks.lua b/contrib/lua/bm-to-elinks-bookmarks.lua
old mode 100644
new mode 100755
diff --git a/contrib/wipe-out-ssl.awk b/contrib/wipe-out-ssl.awk
old mode 100644
new mode 100755
diff --git a/debian/elinks.postinst b/debian/elinks.postinst
old mode 100644
new mode 100755
diff --git a/debian/elinks.preinst b/debian/elinks.preinst
old mode 100644
new mode 100755
diff --git a/debian/elinks.prerm b/debian/elinks.prerm
old mode 100644
new mode 100755
diff --git a/po/gen_translations_stats.sh b/po/gen_translations_stats.sh
old mode 100644
new mode 100755
--
Jonas Fonseca
^ permalink raw reply
* [PATCH Cogito] cg-fetch: fix local cloning with symbolic refs
From: Jonas Fonseca @ 2005-10-08 17:48 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
Ugly workaround for making the HEAD getter use 'git-symbolic-ref HEAD'
so that git-local-fetch is passed the proper ID and not 'ref: ...'.
---
Yeah, it is ugly, it assumes we are getting the HEAD (which is currently
the only one using the -b flag.
diff --git a/cg-fetch b/cg-fetch
index d0d37e1..57096cd 100755
--- a/cg-fetch
+++ b/cg-fetch
@@ -248,9 +248,10 @@ fetch_ssh()
get_local()
{
+ symref=
cp_flags_l="-vdpR"
if [ "$1" = "-b" ]; then
- cp_flags_l="-vb" # Dereference symlinks
+ symref=1
shift
fi
@@ -270,6 +271,7 @@ get_local()
src="$1"
dest="$2"
+ [ "$symref" ] && src="$(dirname $src)/$(git-symbolic-ref HEAD)"
[ "$cut_last" ] && dest=${dest%/*}
cp $cp_flags_l "$src" "$dest"
--
Jonas Fonseca
^ permalink raw reply related
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