* Re: Strangely broken git repo
From: Linus Torvalds @ 2005-10-10 15:21 UTC (permalink / raw)
To: Junio C Hamano
Cc: Martin Langhoff (CatalystIT), Nick Hengeveld, Daniel Barkalow,
git
In-Reply-To: <Pine.LNX.4.64.0510100742070.14597@g5.osdl.org>
On Mon, 10 Oct 2005, Linus Torvalds wrote:
>
> It seems to be the space.
Doing an strace on curl vs wget shows that curl seems to do no quoting at
all. I'd personally argue that that is a serious bug in curl: it sure as
hell knows that it's a http transport, and it seems to be just doing
GET %s HTTP/1.0\r\nUser-agent:...
without any sanity checking at all.
Linus
^ permalink raw reply
* Re: [PATCH] Fix cygwin install issues
From: H. Peter Anvin @ 2005-10-10 15:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonas Fonseca, git
In-Reply-To: <7vmzlh7n7h.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jonas Fonseca <fonseca@diku.dk> writes:
>
>
>>Support installing to paths including spaces.
>>Remove any old .exe files so ln will succeed.
>>
>
> This is not a complaint but I am just wondering if:
>
>
>>- $(INSTALL) -d -m755 $(DESTDIR)$(bindir)
>>+ $(INSTALL) -d -m755 "$(DESTDIR)$(bindir)"
>
> this is the right way to quote things. I suspect it might be
> the responsibility of the user to quote them if she chooses to
> set bindir or DESTDIR to a funky value, like this:
>
> $ make bindir="'My Documents\Programs'"
I don't think that's the right approach.
$(INSTALL) -d -m755 '$(DESTDIR)$(bindir)'
... at least handles everything except embedded single quotes. Note
that the single quote is not a special character for make.
> Because depending on how funky the values of bindir and DESTDIR
> are, we cannot say double-quote you are giving them is even the
> right quoting (think double-quote itself as part of the name).
>
> The other "$X" change to cmd-renames is a good change (I thought
> I heard HPA talking about that; maybe he sent one to me and I
> dropped it on the floor by mistake, I dunno). Thanks.
If I dropped it on the floor, it was mentally :-/
-hpa
^ permalink raw reply
* Re: Strangely broken git repo
From: Linus Torvalds @ 2005-10-10 14:54 UTC (permalink / raw)
To: Junio C Hamano
Cc: Martin Langhoff (CatalystIT), Nick Hengeveld, Daniel Barkalow,
git
In-Reply-To: <7v4q7p927d.fsf@assigned-by-dhcp.cox.net>
On Mon, 10 Oct 2005, Junio C Hamano wrote:
>
> Hmph. Interesting. I just tried.
>
> $ curl 'http://locke.catalyst.net.nz/git/moodle.git/refs/tags/MOODLE_15_MERGED **INVALID**'
>
> gives an error page "404 Not Found", while
>
> $ wget -O - -o /dev/null 'http://locke.catalyst.net.nz/git/moodle.git/refs/tags/MOODLE_15_MERGED **INVALID**'
>
> works fine and gives 2ddfec0dfd0cffd4892af9aaf48ee29c40c7ada3
> back. So we do need to fix things up somewhat in our scripts as
> well.
It seems to be the space. Doing
$ curl 'http://locke.catalyst.net.nz/git/moodle.git/refs/tags/MOODLE_15_MERGED%20**INVALID**'
works ok (ie %20 instead of ' ').
As far as I can tell, we should probably _also_ quote any curl-specific
stuff. As far as I can tell from the manual, if the tag were to have
special characters like '[' and '{', curl might confuse them with being
range specifiers.
Linus
^ permalink raw reply
* Re: SVN import
From: Matthias Urlichs @ 2005-10-10 13:32 UTC (permalink / raw)
To: git
In-Reply-To: <20051010113933.GL567@kiste.smurf.noris.de>
Hi, Matthias Urlichs wrote:
> Hi,
>
> Elfyn McBratney:
>> Worth noting that the URL is actually:
>> http://netz.smurf.noris.de/git/git.git ;)
The current version seems to actually work with nontrivial repositories
(I'm importing gnupg at the moment, which recently switched from CVS to
SVN).
Also worth noting is that cvs->svn->git is somewhat more faithful WRT
importing CVS archives with "incomplete" or "funky" tags -- it exports
their state correctly to SVN, and my importer should be able to get them
out again. On the minus side, the two cannot generate the same changesets
because cvs2svn rounds timestamps to the next full minute.
Speed: Comparable to the CVS importer when crossing the network: both need
one roundtrip per file. I haven't done any tests with local repositories.
--
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
- -
Each morning puts a man on trial and each evening passes judgment.
-- Roy L. Smith
^ permalink raw reply
* Re: SVN import
From: Matthias Urlichs @ 2005-10-10 11:39 UTC (permalink / raw)
To: Elfyn McBratney, git
In-Reply-To: <20051010111428.GC30202@gentoo.org>
[-- Attachment #1: Type: text/plain, Size: 502 bytes --]
Hi,
Elfyn McBratney:
> Worth noting that the URL is actually:
> http://netz.smurf.noris.de/git/git.git ;)
>
*Grumble*
NB: Worth noting: the importer actually *requires* a current Perl SVN
module (i.e., 1.2.1). Debian Sarge's version 1.1.4 doesn't work.
--
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
- -
The best way to get rid of worries is to let them die of neglect.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: SVN import
From: Elfyn McBratney @ 2005-10-10 11:14 UTC (permalink / raw)
To: Matthias Urlichs, git
In-Reply-To: <20051010102651.GA30202@gentoo.org>
[-- Attachment #1: Type: text/plain, Size: 1033 bytes --]
On Mon, Oct 10, 2005 at 11:26:51AM +0100, Elfyn McBratney wrote:
> On Mon, Oct 10, 2005 at 11:45:05 +0200, Matthias Urlichs wrote:
> > Hi, Matthias Urlichs wrote:
> >
> > > Quick note: I'm working on importing from SVN.
> >
> > The first version seems to be finished.
> >
> > http:/netz/smurf.noris.de/git/git.git, branch "svn".
> >
> > Should be ready for merging, though I wouldn't say no to a few testers
> > before that happens. ;-)
>
> Ah cool, was going to work on an SVN counterpart to git-{arch,cvs}import,
> but now won't have to. ;) Will test and report back. :)
Worth noting that the URL is actually:
http://netz.smurf.noris.de/git/git.git ;)
Best,
Elfyn
--
Elfyn McBratney
Gentoo Developer/Perl Team Lead
beu/irc.freenode.net http://dev.gentoo.org/~beu/
+------------O.o--------------------- http://dev.gentoo.org/~beu/pubkey.asc
PGP Key ID: 0x69DF17AD
PGP Key Fingerprint:
DBD3 B756 ED58 B1B4 47B9 B3BD 8D41 E597 69DF 17AD
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: SVN import
From: Matthias Urlichs @ 2005-10-10 11:04 UTC (permalink / raw)
To: Elfyn McBratney, git
In-Reply-To: <20051010102651.GA30202@gentoo.org>
[-- Attachment #1: Type: text/plain, Size: 558 bytes --]
Hi,
Elfyn McBratney:
> Ah cool, was going to work on an SVN counterpart to git-{arch,cvs}import,
> but now won't have to. ;) Will test and report back. :)
>
Please do. I've just pushed a few fixes.
--
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
- -
When competing for a section of road or a parking space, remember
that the vehicle in need of the most body work has the right-of-way.
-- Massachusetts Driver Education Manual
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [RFC] Cleaning up die() error messages
From: Elfyn McBratney @ 2005-10-10 10:50 UTC (permalink / raw)
To: git mailing list
[-- Attachment #1: Type: text/plain, Size: 1681 bytes --]
Hello git list,
I've started working on cleaning up the various die() error messages
found throughout git, and had a few thoughts along the way.
Currently, I've been adding missing program name prefixes, and quoting path
names (e.g., "%s" -> "'%s'"), but before I go any further, I'm wondering
if this is a) desired, or perhaps b) superfluous? This may be best
discussed with along-side the patch - which'll follow shortly. ;)
Also, I got to thinking whether it might be an idea to use the following
idiom in the code:
[shell scripts]
prog="`basename $0`"
..
foo || die "${prog}: foo failed"
[C sources]
static char *prog;
..
static inline void set_prog_name (char *argv0)
{
prog = strrchr(argv0, '/');
if (prog)
prog++;
else
prog = argv0;
}
..
int main (int argc, char **argv)
{
set_prog_name(argv[0]);
..
if (!do_bar())
die("%s: do_bar() failed", prog);
..
}
The idea behind this being that, if any of the git programs get renamed
(again :) there won't be a need for s/git-foo/git-bar/g just to fix-up
die() error messages, and it'll also shave a *bit* off of the size of the
compiled binaries. ;)
(Of course, the C parts (`prog' and `set_prog_name()') would go into a
header, and not in every single C source file. ;)
So, any thoughts/comments/flames? :)
Best,
Elfyn
--
Elfyn McBratney
Gentoo Developer/Perl Team Lead
beu/irc.freenode.net http://dev.gentoo.org/~beu/
+------------O.o--------------------- http://dev.gentoo.org/~beu/pubkey.asc
PGP Key ID: 0x69DF17AD
PGP Key Fingerprint:
DBD3 B756 ED58 B1B4 47B9 B3BD 8D41 E597 69DF 17AD
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: SVN import
From: Elfyn McBratney @ 2005-10-10 10:26 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: git
In-Reply-To: <pan.2005.10.10.09.45.00.468989@smurf.noris.de>
[-- Attachment #1: Type: text/plain, Size: 840 bytes --]
On Mon, Oct 10, 2005 at 11:45:05 +0200, Matthias Urlichs wrote:
> Hi, Matthias Urlichs wrote:
>
> > Quick note: I'm working on importing from SVN.
>
> The first version seems to be finished.
>
> http:/netz/smurf.noris.de/git/git.git, branch "svn".
>
> Should be ready for merging, though I wouldn't say no to a few testers
> before that happens. ;-)
Ah cool, was going to work on an SVN counterpart to git-{arch,cvs}import,
but now won't have to. ;) Will test and report back. :)
Best,
Elfyn
--
Elfyn McBratney
Gentoo Developer/Perl Team Lead
beu/irc.freenode.net http://dev.gentoo.org/~beu/
+------------O.o--------------------- http://dev.gentoo.org/~beu/pubkey.asc
PGP Key ID: 0x69DF17AD
PGP Key Fingerprint:
DBD3 B756 ED58 B1B4 47B9 B3BD 8D41 E597 69DF 17AD
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: SVN import
From: Matthias Urlichs @ 2005-10-10 9:45 UTC (permalink / raw)
To: git
In-Reply-To: <pan.2005.08.19.10.00.49.401829@smurf.noris.de>
Hi, Matthias Urlichs wrote:
> Quick note: I'm working on importing from SVN.
The first version seems to be finished.
http:/netz/smurf.noris.de/git/git.git, branch "svn".
Should be ready for merging, though I wouldn't say no to a few testers
before that happens. ;-)
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
^ permalink raw reply
* [PATCH] git.sh: quote all paths
From: Jonas Fonseca @ 2005-10-10 9:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20051010092638.GC18009@diku.dk>
This makes it handle spaces in paths.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
Sorry I am so sloppy: s/.exe/@@X@@/ ...
diff --git a/git.sh b/git.sh
index 7400c16..b424055 100755
--- a/git.sh
+++ b/git.sh
@@ -1,7 +1,7 @@
#!/bin/sh
cmd=
-path=$(dirname $0)
+path=$(dirname "$0")
case "$#" in
0) ;;
*) cmd="$1"
@@ -12,13 +12,13 @@ case "$#" in
exit 0 ;;
esac
- test -x $path/git-$cmd && exec $path/git-$cmd "$@"
+ test -x "$path/git-$cmd" && exec "$path/git-$cmd" "$@"
case '@@X@@' in
'')
;;
*)
- test -x $path/git-$cmd@@X@@ && exec $path/git-$cmd@@X@@ "$@"
+ test -x "$path/git-$cmd.exe" && exec "$path/git-$cmd@@X@@" "$@"
;;
esac
;;
--
Jonas Fonseca
^ permalink raw reply related
* [PATCH] git.sh: quote all paths
From: Jonas Fonseca @ 2005-10-10 9:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmzlh7n7h.fsf@assigned-by-dhcp.cox.net>
This makes it handle spaces in paths.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
Junio C Hamano <junkio@cox.net> wrote Mon, Oct 10, 2005:
> Jonas Fonseca <fonseca@diku.dk> writes:
>
> > Support installing to paths including spaces.
> > Remove any old .exe files so ln will succeed.
> >
>
> This is not a complaint but I am just wondering if:
>
> > - $(INSTALL) -d -m755 $(DESTDIR)$(bindir)
> > + $(INSTALL) -d -m755 "$(DESTDIR)$(bindir)"
>
> this is the right way to quote things. I suspect it might be
> the responsibility of the user to quote them if she chooses to
> set bindir or DESTDIR to a funky value, like this:
>
> $ make bindir="'My Documents\Programs'"
>
> Because depending on how funky the values of bindir and DESTDIR
> are, we cannot say double-quote you are giving them is even the
> right quoting (think double-quote itself as part of the name).
Yeah, ok, it could end up very wrong. I hope that this patch is
acceptable. I've tested it lightly, and the core commands seems to work,
there might be other git scripts that needs to be changed.
> The other "$X" change to cmd-renames is a good change (I thought
> I heard HPA talking about that; maybe he sent one to me and I
> dropped it on the floor by mistake, I dunno). Thanks.
I also sent a 'disguised' patch in <20051005131631.GA9442@diku.dk> ...
---
diff --git a/git.sh b/git.sh
index 7400c16..19f89d8 100755
--- a/git.sh
+++ b/git.sh
@@ -1,7 +1,7 @@
#!/bin/sh
cmd=
-path=$(dirname $0)
+path=$(dirname "$0")
case "$#" in
0) ;;
*) cmd="$1"
@@ -12,13 +12,13 @@ case "$#" in
exit 0 ;;
esac
- test -x $path/git-$cmd && exec $path/git-$cmd "$@"
+ test -x "$path/git-$cmd" && exec "$path/git-$cmd" "$@"
case '@@X@@' in
'')
;;
*)
- test -x $path/git-$cmd@@X@@ && exec $path/git-$cmd@@X@@ "$@"
+ test -x "$path/git-$cmd.exe" && exec "$path/git-$cmd.exe" "$@"
;;
esac
;;
--
Jonas Fonseca
^ permalink raw reply related
* Re: [PATCH] Fix cygwin install issues
From: Junio C Hamano @ 2005-10-10 9:09 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git
In-Reply-To: <20051010085259.GA18009@diku.dk>
Jonas Fonseca <fonseca@diku.dk> writes:
> Support installing to paths including spaces.
> Remove any old .exe files so ln will succeed.
>
This is not a complaint but I am just wondering if:
> - $(INSTALL) -d -m755 $(DESTDIR)$(bindir)
> + $(INSTALL) -d -m755 "$(DESTDIR)$(bindir)"
this is the right way to quote things. I suspect it might be
the responsibility of the user to quote them if she chooses to
set bindir or DESTDIR to a funky value, like this:
$ make bindir="'My Documents\Programs'"
Because depending on how funky the values of bindir and DESTDIR
are, we cannot say double-quote you are giving them is even the
right quoting (think double-quote itself as part of the name).
The other "$X" change to cmd-renames is a good change (I thought
I heard HPA talking about that; maybe he sent one to me and I
dropped it on the floor by mistake, I dunno). Thanks.
^ permalink raw reply
* Re: [PATCH] Fix cygwin install issues
From: Jonas Fonseca @ 2005-10-10 9:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20051010085259.GA18009@diku.dk>
Jonas Fonseca <fonseca@diku.dk> wrote Mon, Oct 10, 2005:
> Support installing to paths including spaces.
> Remove any old .exe files so ln will succeed.
I see that there are problems in the git porcelain commands that needs
to also be fixed so please ignore this for now.
Instead, is this something that should be supported? (It is quite
absurd, although it is required for 'make install' to work out of the
box on some systems).
--
Jonas Fonseca
^ permalink raw reply
* Re: Strangely broken git repo
From: Junio C Hamano @ 2005-10-10 9:00 UTC (permalink / raw)
To: Martin Langhoff (CatalystIT); +Cc: Nick Hengeveld, Daniel Barkalow, git
In-Reply-To: <4349ED5D.6020703@catalyst.net.nz>
"Martin Langhoff (CatalystIT)" <martin@catalyst.net.nz> writes:
> $ cg-clone http://locke.catalyst.net.nz/git/moodle.git#moodle--topnz
> ...
> Getting index for pack 3e3492f365bb0d4a1ae11dfa7cee9ebbf345e647
> Getting pack 3113eb34ef85482c87c3575721ce978c7232071f
> which contains 007a0323cf0941476dc262f6e3aff6bb9600dcd8
> error: The requested file was not found
> ... (many more like these)
So it failed to grab 007a0323cf0941476dc262f6e3aff6bb9600dcd8,
but that is OK. That object is in a pack:
pack-3113eb34ef85482c87c3575721ce978c7232071f has it.
> FINISHED --15:56:38--
> Downloaded: 4,723 bytes in 1 files
> New branch: 6759e2800c0cef00017c63b7dbbed80e481dbe2c
> Cloned to moodle.git#moodle--topnz/ (origin
> http://locke.catalyst.net.nz/git/moodle.git#moodle--topnz available as
> branch "origin")
> aporo:~/tmp/moodle.git#moodle--topnz martin$ git-fsck-objects
> bad sha1 file: .git/objects/00/7a0323cf0941476dc262f6e3aff6bb9600dcd8.temp
> ... (many more like these)
This *.temp file is what git-http-fetch creates while retrieving
the object. After successfully downloading it, it is renamed to
its final name (i.e. sans .temp), but that rename did not
happen. Well, this object is in a pack, so after failing to
retrieve that, we should have got the list of packs, retrieved
pack index files, and grabbed the pack that contained that
object. We *should* clean up the *.temp file for this object
whe we do this, but I do not think we do. But I do not think
this is the _cause_ of your problem. It is a symptom that
something is going wrong -- namely, the question is why it was
not found in pack-3113eb34ef85482c87c3575721ce978c7232071f. Did
the client download that pack?
I just tried to clone your repository with 'git clone', and saw
something failing, but I think the object trasfer went fine all
the way down to the initial commit. I can see this object in my
cloned repository:
commit 34cc394a7427adf730cfd3fb482dc6d6d5b58775
Author: Martin Langhoff <martin@catalyst.net.nz>
Date: Tue Aug 3 02:50:51 2004 +0000
initial import
There are funky tag names in your refs/tags directory. The
really core tools should be able to grok them just fine, but
git-http-fetch failed with this from curl library:
The requested URL returned error: 404
error: Couldn't get http://locke.catalyst.net.nz/git/moodle.git/refs/tags/MOODLE_15_MERGED **INVALID** for tags/MOODLE_15_MERGED **INVALID**
I do not speak curl, but I wonder if we should be quoting
these funky characters like SP and asterisk in the URL when we
make that request, or it is what the library does for us.
Hmph. Interesting. I just tried.
$ curl 'http://locke.catalyst.net.nz/git/moodle.git/refs/tags/MOODLE_15_MERGED **INVALID**'
gives an error page "404 Not Found", while
$ wget -O - -o /dev/null 'http://locke.catalyst.net.nz/git/moodle.git/refs/tags/MOODLE_15_MERGED **INVALID**'
works fine and gives 2ddfec0dfd0cffd4892af9aaf48ee29c40c7ada3
back. So we do need to fix things up somewhat in our scripts as
well.
Anyway, I think I know the problems 'git-clone' would have had
if you tried to clone it with it (not cg-clone which I do not
know much about), and luckily it is only towards the end (after
fetching most of the heads, but hitting the first funky tag).
We should be able to fix this relatively easily.
Oh, Daniel and Nick, while I was reading the http-fetch.c code,
I noticed another thing.
The fetch_alternates() function was supposed to be call-once and
we have a static variable got_alternates that becomes 1 when it
runs for the first time. However, there are other 'return 0's
introduced that does not set got_alternates to 1.
I am wondering if the semantics has changed that now we chain
the alternates? Initially, if we are cloning/fetching from
repository A, which borrows from repository B (i.e. alternates
we retrieve from A would name B), and if B in turn borrows from
C, then we assumed that A's alternates would also name C, and
that was the reason why fetch_alternates() was call-once
function. I do not mind if we change it to chain the alternates
file, but if that is the case we should move the got_alternates
variable into "struct alt_base", and pass the struct, not just
alt->base, to fetch_alternates(), like this (untested, of
course):
diff --git a/http-fetch.c b/http-fetch.c
index 5821c9e..2301f88 100644
--- a/http-fetch.c
+++ b/http-fetch.c
@@ -38,6 +38,7 @@ struct alt_base
{
char *base;
int got_indices;
+ int got_alternates;
struct packed_git *packs;
struct alt_base *next;
};
@@ -529,8 +530,6 @@ void prefetch(unsigned char *sha1)
#endif
}
-static int got_alternates = 0;
-
static int fetch_index(struct alt_base *repo, unsigned char *sha1)
{
char *hex = sha1_to_hex(sha1);
@@ -611,8 +610,9 @@ static int setup_index(struct alt_base *
return 0;
}
-static int fetch_alternates(char *base)
+static int fetch_alternates(struct alt_base *this_alt)
{
+ char *base = this_alt->base;
int ret = 0;
struct buffer buffer;
char *url;
@@ -622,15 +622,17 @@ static int fetch_alternates(char *base)
struct alt_base *tail = alt;
struct active_request_slot *slot;
- if (got_alternates)
+ if (this_alt->got_alternates)
return 0;
+ this_alt->got_alternates = 1;
data = xmalloc(4096);
buffer.size = 4095;
buffer.posn = 0;
buffer.buffer = data;
if (get_verbosely)
- fprintf(stderr, "Getting alternates list\n");
+ fprintf(stderr, "Getting alternates list for %s\n",
+ base);
url = xmalloc(strlen(base) + 31);
sprintf(url, "%s/objects/info/http-alternates", base);
@@ -721,7 +723,6 @@ static int fetch_alternates(char *base)
}
i = posn + 1;
}
- got_alternates = 1;
return ret;
}
@@ -1092,9 +1093,10 @@ int main(int argc, char **argv)
alt = xmalloc(sizeof(*alt));
alt->base = url;
alt->got_indices = 0;
+ alt->got_alternates = 0;
alt->packs = NULL;
alt->next = NULL;
- fetch_alternates(alt->base);
+ fetch_alternates(alt);
if (pull(commit_id))
return 1;
^ permalink raw reply related
* [PATCH] Fix cygwin install issues
From: Jonas Fonseca @ 2005-10-10 8:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Support installing to paths including spaces.
Remove any old .exe files so ln will succeed.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
diff --git a/Makefile b/Makefile
index ac384c7..9ae0dfd 100644
--- a/Makefile
+++ b/Makefile
@@ -397,13 +397,13 @@ check:
### Installation rules
install: $(PROGRAMS) $(SCRIPTS)
- $(INSTALL) -d -m755 $(DESTDIR)$(bindir)
- $(INSTALL) $(PROGRAMS) $(SCRIPTS) $(DESTDIR)$(bindir)
- $(INSTALL) git-revert $(DESTDIR)$(bindir)/git-cherry-pick
- sh ./cmd-rename.sh $(DESTDIR)$(bindir)
+ $(INSTALL) -d -m755 "$(DESTDIR)$(bindir)"
+ $(INSTALL) $(PROGRAMS) $(SCRIPTS) "$(DESTDIR)$(bindir)"
+ $(INSTALL) git-revert "$(DESTDIR)$(bindir)/git-cherry-pick"
+ sh ./cmd-rename.sh "$(DESTDIR)$(bindir)" "$X"
$(MAKE) -C templates install
- $(INSTALL) -d -m755 $(DESTDIR)$(GIT_PYTHON_DIR)
- $(INSTALL) $(PYMODULES) $(DESTDIR)$(GIT_PYTHON_DIR)
+ $(INSTALL) -d -m755 "$(DESTDIR)$(GIT_PYTHON_DIR)"
+ $(INSTALL) $(PYMODULES) "$(DESTDIR)$(GIT_PYTHON_DIR)"
install-doc:
$(MAKE) -C Documentation install
diff --git a/cmd-rename.sh b/cmd-rename.sh
index 34e7f49..c9d3171 100755
--- a/cmd-rename.sh
+++ b/cmd-rename.sh
@@ -1,9 +1,10 @@
#!/bin/sh
d="$1"
+X="$2"
test -d "$d" || exit
while read old new
do
- rm -f "$d/$old"
+ rm -f "$d/$old" "$d/$old$X"
if test -f "$d/$new"
then
ln -s "$new" "$d/$old" || exit
--
Jonas Fonseca
^ permalink raw reply related
* Re: Seeing various mode changes on cygwin
From: Junio C Hamano @ 2005-10-10 7:38 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0510100220330.23242@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> Perhaps have a bit in the index mode for the file to say that the mode in
> the filesystem is unreliable, which gets set if a stat of the
> newly-written file doesn't match the mode it was supposed to have, or if
> git chmod is used to change it; then, if the bit is set, ignore the mode
> in the filesystem and just use the mode in the index.
In effect, you are making the "per-repo configuration" Linus
mentioned a non configuration but a property recorded in the
index file. I think this is a clever solution which is very
helpful to the end user. I have to think about this a bit, but
my gut feeling tells me that it is the right direction if it
works.
I do not think you have to necessarily record it in the "index
mode" -- which implies this is per path -- nor even in the index
file itself. We might even be able to get away with doing this
check at git-init-db time just once, and record it in a file,
say ".git/fs-mode-unreliable".
^ permalink raw reply
* Re: Seeing various mode changes on cygwin
From: Daniel Barkalow @ 2005-10-10 6:48 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Alex Riesen, git
In-Reply-To: <Pine.LNX.4.64.0510081909250.31407@g5.osdl.org>
On Sat, 8 Oct 2005, Linus Torvalds wrote:
> 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?
Perhaps have a bit in the index mode for the file to say that the mode in
the filesystem is unreliable, which gets set if a stat of the
newly-written file doesn't match the mode it was supposed to have, or if
git chmod is used to change it; then, if the bit is set, ignore the mode
in the filesystem and just use the mode in the index.
This should prevent modes from magically changing, even if the user
doesn't do anything special.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Strangely broken git repo
From: Martin Langhoff (CatalystIT) @ 2005-10-10 4:26 UTC (permalink / raw)
To: git
In-Reply-To: <46a038f90510082014i6b296f2bvbac56e25344cbdf2@mail.gmail.com>
Hi!
We are having strange problems pushing (and pulling) with a particular
head in a git repo. The repo is publicly available via http, and when
I clone it it gives me a lot of errors
$ cg-clone http://locke.catalyst.net.nz/git/moodle.git#moodle--topnz
...
Getting index for pack 3e3492f365bb0d4a1ae11dfa7cee9ebbf345e647
Getting pack 3113eb34ef85482c87c3575721ce978c7232071f
which contains 007a0323cf0941476dc262f6e3aff6bb9600dcd8
error: The requested file was not found
... (many more like these)
FINISHED --15:56:38--
Downloaded: 4,723 bytes in 1 files
New branch: 6759e2800c0cef00017c63b7dbbed80e481dbe2c
Cloned to moodle.git#moodle--topnz/ (origin
http://locke.catalyst.net.nz/git/moodle.git#moodle--topnz available as
branch "origin")
aporo:~/tmp/moodle.git#moodle--topnz martin$ git-fsck-objects
bad sha1 file: .git/objects/00/7a0323cf0941476dc262f6e3aff6bb9600dcd8.temp
... (many more like these)
When using git+ssh, we are seeing very strange stalls during the
fetch, and when trying to push a couple of small new commits, it has
given us (from a Debian etch-ppc, git 0.99.8.b) gives us "fatal unpack
should have generated <sha1> but I can't find it".
This has been discussed earlier here
http://www.gelato.unsw.edu.au/archives/git/0508/7152.html -- but our
scenario doesn't involve rewinding or any strange trickery, it's just
clone - edit - commit - push.
From a different machine (Debian sarge, i386, git 0.99.8b) the same
operation succeeds.
On the repo itself, I've run git-fsck-objects --full --strict and it
only complained about dangling tags. There are some heads on that repo
that I have deleted a while ago without purging unreachable objects,
so I kind of expected those.
There are some automated jobs that touch this repo and may have messed
things up:
- cronjobs running git-cvsimport and git-archimport and pushing to
this repo
- weekly git-repack run over the repo
Uff. I have the feeling that this isn't a very complete picture, but
I'm not sure what else to do to debug this one. Pointers welcome.
cheers,
martin
^ permalink raw reply
* [PATCH] testsuite fails with locale diff output; set locale vars
From: Junichi Uekawa @ 2005-10-10 4:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
From: Junichi Uekawa <dancer@debian.org>
git testsuite depends on diff output, which can change
depending on LC_MESSAGES.
set LANG and LC_ALL environment vars to allow
locale to be set to an expected value of 'C'.
Signed-off-by: Junichi Uekawa <dancer@debian.org>
diff --git a/t/Makefile b/t/Makefile
index e71da77..47eea74 100644
--- a/t/Makefile
+++ b/t/Makefile
@@ -8,6 +8,8 @@ SHELL_PATH ?= $(SHELL)
TAR ?= $(TAR)
T = $(wildcard t[0-9][0-9][0-9][0-9]-*.sh)
+export LC_ALL=C
+export LANG=C
all:
@$(foreach t,$T,echo "*** $t ***"; $(SHELL_PATH) $t $(GIT_TEST_OPTS) || exit; )
^ permalink raw reply related
* Commit text BEFORE the dashes (Re: First cut at git port to Cygwin)
From: Matthias Urlichs @ 2005-10-09 20:40 UTC (permalink / raw)
To: git
In-Reply-To: <20051007212250.GA1423@steel.home>
Hi, Alex Riesen wrote:
> [ some text ]
> ---
> [ the actual commit text ]
REMINDER: These need to be swapped.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
^ permalink raw reply
* Re: no "uname -o" on Mac OSX
From: Junio C Hamano @ 2005-10-09 19:34 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <864q7qlc77.fsf@blue.stonehenge.com>
merlyn@stonehenge.com (Randal L. Schwartz) writes:
> How about a chain of elsif's?
Makes much more sense. Thanks.
^ permalink raw reply
* Re: no "uname -o" on Mac OSX
From: Randal L. Schwartz @ 2005-10-09 19:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: H. Peter Anvin, git
In-Reply-To: <7voe5yebjv.fsf@assigned-by-dhcp.cox.net>
>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
Junio> Peter, I noticed the same on Solaris recently.
Junio> The following seems to work but is quite yucky, and I prefer
Junio> somebody to come up with a better alternative.
How about a chain of elsif's?
Doesn't make support that?
I mean, when you know it's Darwin, no point in checking if it's OpenBSD. :)
--
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: [PATCH 1/2] Fix git-verify-tag for local tags
From: Junio C Hamano @ 2005-10-09 19:29 UTC (permalink / raw)
To: git
In-Reply-To: <20051009181246.17885.81654.stgit@zion.home.lan>
Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> writes:
> 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).
Good spotting, but checking for type being not a tag (not
limited to commit object) would be a better approach. I'll fix
it up that way and apply (no need to resend). Thanks.
^ permalink raw reply
* 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
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