* Re: [PATCH] Add git-shell.
From: Linus Torvalds @ 2005-10-24 0:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0510231751040.10477@g5.osdl.org>
On Sun, 23 Oct 2005, Linus Torvalds wrote:
>
> Did you actually test that it works as somebody's login-shell and can be
> used for pushing?
>
> I think it should add "pull" functionality too
Gaah, I only read your description, didn't look closer at the patch. The
description just said "push", but you added the pull side too, and
apparently even tested it. Goodie.
Never mind me.
Linus
^ permalink raw reply
* Re: LCA2006 Git/Cogito tutorial
From: Junio C Hamano @ 2005-10-24 0:58 UTC (permalink / raw)
To: Martin Langhoff (CatalystIT); +Cc: git
In-Reply-To: <4358597A.6000306@catalyst.net.nz>
"Martin Langhoff (CatalystIT)" <martin@catalyst.net.nz> writes:
>>>(ii) You say:
>>>
>>> - Very fast stupid merge
>>> ... and very smart, slow merges when stupid won't do
>
> Almost. No, truly, I'm very impressed with git-merge.sh, which first
> does the simple git-read-tree -m, and it can then try several merger
> scripts to resolve the index. The "smartest" merge resolver we have
> follows renames, but we could have language-specific and
> project-specific resolvers, for instance.
I should not be saying this because I am the primary guilty
party, but you should not be so impressed.
Being able to specify which merge strategy to use is a useful
thing, but I do not think being able to try more than one merge
strategies automatically, while it has some coolness value, is
very useful in practice.
The language-specific or project-specific part should be made
orthogonal to merge strategy modules, which currently is not.
The primary thing Daniel's git-merge-resolve and Fredrik's
git-merge-recursive do is to figure out which paths can be
resolved without merging the file contents, and which paths need
to be resolved with file contents merge, and they use different
strategies to find which 3 variants of the contents to use for
that final merge.
But at the end of the day, merging the contents is done by
running 'merge' in either case. This should be made either
customizable, or we ship our standard one that can be extended
to first run 'file' to see the file content type of what is
being merged and run content specific merge program if there is
one.
Even if we did that, we are still doing 3-way merge; git-merge
framework may not mesh very well when we want to use something
like codeville merge which is not based on 3-way.
^ permalink raw reply
* Re: User-relative paths
From: H. Peter Anvin @ 2005-10-24 1:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Andreas Ericsson, git
In-Reply-To: <7v8xwjx2f9.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Linus Torvalds <torvalds@osdl.org> writes:
>
>
>>It's incomplete and almost certainly buggy and generally broken, but
>>here's somethign that you _could_ install as "git-shell", and then put
>>that as somebodys shell in /etc/passwd, and it's a start. A very rough
>>start.
>>
>>Somebody else gets to test it out ;)
>>
>>+ if (c != '\'') {
>>+ *dst++ = c;
>>+ continue;
>>+ }
>>+ switch (*++src) {
>>+ case '\0':
>>+ *dst = 0;
>>+ return arg;
>>+ case '\\':
>>+ if (*++src == '\'' &&
>>+ *++src == '\'') {
>>+ *dst = '\'';
>>+ continue;
>>+ }
>>+ /* Fallthrough */
>>+ default:
>
> I think this misses HPA's addition to minimally suppport csh
> braindamage (bang bang).
>
If this is meant to dequote shell-quoted paths, it really should be modal.
-hpa
^ permalink raw reply
* Re: LCA2006 Git/Cogito tutorial
From: Linus Torvalds @ 2005-10-24 1:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Martin Langhoff (CatalystIT), git
In-Reply-To: <7vu0f7u3xc.fsf@assigned-by-dhcp.cox.net>
On Sun, 23 Oct 2005, Junio C Hamano wrote:
>
> Even if we did that, we are still doing 3-way merge; git-merge
> framework may not mesh very well when we want to use something
> like codeville merge which is not based on 3-way.
Oh, the git merge is about a million times better than any silly weave
merge with extra BonusPoints and MagicCapitalizedNames.
Why? Because if you want to be slow and careful, you can always just
create the weave after-the-fact and do a weave merge.
And because well-behaved git merges as so fast, you can actually afford
to so so.
There's nothing magic in a weave merge. It's just a trick. It doesn't need
the files to be in weave format beforehand, even though people seem to
believe that file formats go together with it.
If somebody thinks a weave merge is wonderful and fixes everything, I have
to rain on their parade. You still need to manually fix real conflicts up,
and regardless, what kind of merge you do has _nothing_ to do with how you
maintain your files.
If you want to do a weave merge inside git, then the way to do that is to
just create the weave on demand in the (rare) case where it's needed. We
have all the history. You might even just do a "lazy weave", which just
starts from the common parent, and ignores the history before that.
Much cheaper that way, and arguably nicer (others will argue that you want
to take history into account, to decide about undo's etc. It's a matter of
taste).
The thing is, automatic merging isn't all _that_ important. The thing that
made BK wonderful at merging was that it had a wonderful tool for merging
for when there were real clashes, which is where the _really_ nasty cases
are. The actual automatic merge wasn't necessarily anything magical.
(Same went for applying diffs, btw. What made BK nice was "renametool". Of
course, it was also what made me decide that tracking renames was the
wrong thing to do in the first place, but if you make a CMS that does
renames, you'd better have a "renametool").
And if you have a tool that helps you visually merge the _real_ clashes,
it doesn't much matter if you are only half-way decent on the automatic
ones. They'll be so trivial that nobody cares.
And it doesn't matter _how_ good your automatic merges are, there always
_will_ be real clashes.
[ Side note. Think about this for a while. Git did three-way merges
pretty much since day one, but they only became _useful_ when we made it
easy to see the merge conflicts and fix them up. That's a fundamental
lesson right there: you don't have to be perfect, you have to make it
easy for the user to fix up your imperfections. ]
So we should spend time on making it easy to see what the clash was, and
on tools to help resolve them. Some random merge-strategy-of-the-day is
just bling-bling.
The reason people like merge strategies is that it's a nice area for some
mental masturbation. You can create all these fancy examples. And then can
ignore the fact that most real merge problems end up being two people
changing the same code in different ways, that just need manual merging.
Don't get me wrong - if somebody does a nice automated merge for git, it's
a good thing, but it's probably much more important to try to integrate
something like xxdiff to a git workflow. And _that_ level is probably
where you want to have special language-based coloring etc to further help
things out.
So keep your eyes on the ball. And "automatic merge" isn't it.
Linus
^ permalink raw reply
* Re: [PATCH] Add git-shell.
From: Junio C Hamano @ 2005-10-24 1:36 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0510231751040.10477@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Sun, 23 Oct 2005, Junio C Hamano wrote:
>>
>> This adds a very git specific restricted shell, that can be
>> added to /etc/shells and set to the pw_shell in the /etc/passwd
>> file, to give users ability to push into repositories over ssh
>> without giving them full interactive shell acount.
>
> Did you actually test that it works as somebody's login-shell and can be
> used for pushing?
I made a temporary user on my notebook, set it as his login
shell, and run peek-remote against it (which means the git-shell
spawned upload-pack on the other end). No, I did not try pushing
when I sent the patch
But I just did, and it seems to work, so this should hit the
master branch soon ;-).
^ permalink raw reply
* Re: User-relative paths
From: Linus Torvalds @ 2005-10-24 1:37 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Junio C Hamano, Andreas Ericsson, git
In-Reply-To: <435C3427.30803@zytor.com>
On Sun, 23 Oct 2005, H. Peter Anvin wrote:
>
> If this is meant to dequote shell-quoted paths, it really should be modal.
It _only_ accepts quoted strings, so it "is" modal. It has one mode:
string. And it's a bitch about enforcing it, too (it just dies if it
wasn't one).
Linus
^ permalink raw reply
* Re: User-relative paths
From: H. Peter Anvin @ 2005-10-24 1:44 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Andreas Ericsson, git
In-Reply-To: <Pine.LNX.4.64.0510231836020.10477@g5.osdl.org>
Linus Torvalds wrote:
>
> On Sun, 23 Oct 2005, H. Peter Anvin wrote:
>
>>If this is meant to dequote shell-quoted paths, it really should be modal.
>
> It _only_ accepts quoted strings, so it "is" modal. It has one mode:
> string. And it's a bitch about enforcing it, too (it just dies if it
> wasn't one).
>
That wasn't what I meant. '...' is a modal escape in the shell. Thus,
something like this which actually mimics the state machine, at least
for the potential characters we care about.
#define EMIT(x) { ( ++len < n ) && *dst++ = (x) )
int unquote(char *dst, size_t n, const char *src)
{
enum state st = { st_zero, st_quote, st_escape };
int len = 0;
char c;
while ( (c = *src++) ) {
switch ( st ) {
case st_zero:
if ( c == '\'' )
st = st_quote;
else if ( c == '\\' )
st = st_escape;
else
EMIT(c);
break;
case st_quote:
if ( c == '\'' )
st = st_zero;
else
EMIT(c);
break;
case st_escape:
EMIT(c);
st = st_zero;
break;
}
}
if ( n )
*dst = 0;
return (st == st_zero) ? len : -1;
}
^ permalink raw reply
* Re: LCA2006 Git/Cogito tutorial
From: Junio C Hamano @ 2005-10-24 1:48 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Martin Langhoff (CatalystIT), git
In-Reply-To: <Pine.LNX.4.64.0510231804430.10477@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Sun, 23 Oct 2005, Junio C Hamano wrote:
>>
>> Even if we did that, we are still doing 3-way merge; git-merge
>> framework may not mesh very well when we want to use something
>> like codeville merge which is not based on 3-way.
>
> Oh, the git merge is about a million times better than any silly weave
> merge with extra BonusPoints and MagicCapitalizedNames.
>
> Why? Because if you want to be slow and careful, you can always just
> create the weave after-the-fact and do a weave merge.
Yes, I know that as the one who did the convention between
git-merge and merge strategy backends. The convention feeds two
(or more) heads and the common ancestors git-merge already
figured out to the strategy backends.
The current callers only feed commits for "$heads" parameters,
so the merge strategy backends are free to figure out the common
ancestor or even generate weave on the fly, but an unwritten
rule was that strategy backends are expected to do something
sensible even when the "common ancestors" and "heads" fed to
them are tree objects, which was my comment about 3-way was
about.
^ permalink raw reply
* Re: User-relative paths
From: Junio C Hamano @ 2005-10-24 1:56 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Linus Torvalds, Andreas Ericsson, git
In-Reply-To: <435C3427.30803@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
> If this is meant to dequote shell-quoted paths, it really should be modal.
You are right, but this is not meant to dequote arbitrary shell
quoted paths. It specifically is for unwrapping what sq_quote()
produced, and refuses to proceed if you feed some shell-valid
but not sq_quote() produced string. The reason is because it is
part of the git-shell "login shell" -- the input validation is
enforced there.
And the reason it lives next to quote.c::sq_quote() is that you
would hopefully notice sq_dequote() needs matching changes when
you ever update sq_quote.
^ permalink raw reply
* Re: User-relative paths
From: Junio C Hamano @ 2005-10-24 2:08 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <7v1x2cyplw.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> * In a URL, a colon after hostname means "port number
> follows". So it was a good intention to make these
> consistent:
>
> git fetch ssh://kernel.org:git
> git fetch kernel.org:git
>
> it should not be done. IOW, if I wanted to use the former
> form (which I do not think I'd use myself), I should say either one
> of:
>
> git fetch ssh://kernel.org:~/git
> git fetch ssh://kernel.org:~junio/git
>
> Oh, I just noticed you do not handle the former, because you
> did not have to, but now you need to.
The "should be this way" examples should have been something
like this:
git fetch ssh://kernel.org/~/git
git fetch ssh://kernel.org/~junio/git
Otherwise what I said does not make *any* sense.
Junio "Oh, I am an idiot" Hamano
^ permalink raw reply
* Re: LCA2006 Git/Cogito tutorial
From: Linus Torvalds @ 2005-10-24 3:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Martin Langhoff (CatalystIT), git
In-Reply-To: <7vy84jsn1o.fsf@assigned-by-dhcp.cox.net>
On Sun, 23 Oct 2005, Junio C Hamano wrote:
>
> The current callers only feed commits for "$heads" parameters,
> so the merge strategy backends are free to figure out the common
> ancestor or even generate weave on the fly, but an unwritten
> rule was that strategy backends are expected to do something
> sensible even when the "common ancestors" and "heads" fed to
> them are tree objects, which was my comment about 3-way was
> about.
Ahh. Yes, if you use raw trees, you're screwed - you can only ever do a
3-way merge, since you can't try to figure out any history.
I agree that the "tree only" case is interesting too - it's how you can
merge trees that may be related content-wise but don't share a history (eg
the same project maintained in separate source trees), and it's obviously
how you can merge totally unrelated projects (eg the gitk merge). At the
same time, I think that's a different kind of merge, in general. And we
definitely shouldn't limit ourselves to things where such merges work.
Yes, tree-merges are wonderful, and they work really quite well, but I
definitely want to keep the window open for merges that end up taking the
full history into account.
I just don't think they are nearly as important as some people seem to
think. They should be a very special and unusual case, rather than
something you expect to happen.
Linus
^ permalink raw reply
* daemon.c broken on OpenBSD
From: Randal L. Schwartz @ 2005-10-24 4:06 UTC (permalink / raw)
To: git
Wow.
gcc -o daemon.o -c -g -O2 -Wall -I/usr/local/include -L/usr/local/lib -Dstrcasestr=gitstrcasestr -DNO_STRCASESTR=1 -DSHA1_HEADER='<openssl/sha.h>' daemon.c
In file included from /usr/include/sys/poll.h:54,
from daemon.c:7:
/usr/include/ctype.h:67: error: syntax error before ']' token
/usr/include/ctype.h:68: error: syntax error before ']' token
/usr/include/ctype.h:70: error: syntax error before ']' token
/usr/include/ctype.h:75: error: syntax error before ']' token
/usr/include/ctype.h:78: error: syntax error before '(' token
/usr/include/ctype.h:79: error: syntax error before '(' token
/usr/include/ctype.h:93: error: syntax error before "c"
In file included from /usr/include/sys/poll.h:54,
from daemon.c:7:
/usr/include/ctype.h:91:1: unterminated #if
/usr/include/ctype.h:40:1: unterminated #ifndef
In file included from daemon.c:7:
/usr/include/sys/poll.h:53:1: unterminated #ifndef
/usr/include/sys/poll.h:28:1: unterminated #ifndef
gmake: *** [daemon.o] Error 1
Apparently something in the early lines of daemon.c (before line 7)
is defining something that breaks the core /usr/include/ctype.h.
Lines 66 to 68 of ctype.h look like:
#if defined(__GNUC__) || defined(_ANSI_LIBRARY) || defined(lint)
int isalnum(int);
int isalpha(int);
If that rings a bell, help me out here. I'm guessing "isalnum" is getting
defined (wrongly). Yeah, looks like in cache.h. Why is this getting
defined?
--
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: daemon.c broken on OpenBSD
From: Junio C Hamano @ 2005-10-24 5:20 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <867jc336f4.fsf@blue.stonehenge.com>
merlyn@stonehenge.com (Randal L. Schwartz) writes:
> Wow.
>...
> If that rings a bell, help me out here. I'm guessing "isalnum" is getting
> defined (wrongly). Yeah, looks like in cache.h. Why is this getting
> defined?
Wow indeed. It comes from this thread:
http://marc.theaimsgroup.com/?l=git&m=112917422812418&w=2
Maybe something like this would help?
------------
[PATCH] do not override standard ctype macros, but use our own.
...since it can cause breakage in system supplied header files...
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
It would be easier for *you* to grok if I say this patch is
essentially this ;-):
$ git-ls-files |
xargs perl -i -p -e '
s/\bis(space|digit|alpha|alnum)\b/is_$1/g;
s/\bto(lower|upper)\b/to_$1/g;
'
except that I did not touch gitk.
diff --git a/apply.c b/apply.c
index e5c0b7d..9608f92 100644
--- a/apply.c
+++ b/apply.c
@@ -113,7 +113,7 @@ static unsigned long linelen(const char
static int is_dev_null(const char *str)
{
- return !memcmp("/dev/null", str, 9) && isspace(str[9]);
+ return !memcmp("/dev/null", str, 9) && is_space(str[9]);
}
#define TERM_SPACE 1
@@ -167,7 +167,7 @@ static char * find_name(const char *line
for (;;) {
char c = *line;
- if (isspace(c)) {
+ if (is_space(c)) {
if (c == '\n')
break;
if (name_terminate(start, line-start, c, terminate))
@@ -447,7 +447,7 @@ static char *git_header_name(char *line,
/* second points at one past closing dq of name.
* find the second name.
*/
- while ((second < line + llen) && isspace(*second))
+ while ((second < line + llen) && is_space(*second))
second++;
if (line + llen <= second)
@@ -508,7 +508,7 @@ static char *git_header_name(char *line,
len = strlen(np);
if (len < cp - name &&
!strncmp(np, name, len) &&
- isspace(name[len])) {
+ is_space(name[len])) {
/* Good */
memmove(sp, np, len + 1);
return sp;
@@ -615,7 +615,7 @@ static int parse_num(const char *line, u
{
char *ptr;
- if (!isdigit(*line))
+ if (!is_digit(*line))
return 0;
*p = strtoul(line, &ptr, 10);
return ptr - line;
diff --git a/cache.h b/cache.h
index d776016..3f6ff0d 100644
--- a/cache.h
+++ b/cache.h
@@ -388,23 +388,17 @@ extern char git_default_email[MAX_GITNAM
extern char git_default_name[MAX_GITNAME];
/* Sane ctype - no locale, and works with signed chars */
-#undef isspace
-#undef isdigit
-#undef isalpha
-#undef isalnum
-#undef tolower
-#undef toupper
extern unsigned char sane_ctype[256];
#define GIT_SPACE 0x01
#define GIT_DIGIT 0x02
#define GIT_ALPHA 0x04
#define sane_istest(x,mask) ((sane_ctype[(unsigned char)(x)] & (mask)) != 0)
-#define isspace(x) sane_istest(x,GIT_SPACE)
-#define isdigit(x) sane_istest(x,GIT_DIGIT)
-#define isalpha(x) sane_istest(x,GIT_ALPHA)
-#define isalnum(x) sane_istest(x,GIT_ALPHA | GIT_DIGIT)
-#define tolower(x) sane_case((unsigned char)(x), 0x20)
-#define toupper(x) sane_case((unsigned char)(x), 0)
+#define is_space(x) sane_istest(x,GIT_SPACE)
+#define is_digit(x) sane_istest(x,GIT_DIGIT)
+#define is_alpha(x) sane_istest(x,GIT_ALPHA)
+#define is_alnum(x) sane_istest(x,GIT_ALPHA | GIT_DIGIT)
+#define to_lower(x) sane_case((unsigned char)(x), 0x20)
+#define to_upper(x) sane_case((unsigned char)(x), 0)
static inline int sane_case(int x, int high)
{
diff --git a/commit.c b/commit.c
index 8f40318..4d094b5 100644
--- a/commit.c
+++ b/commit.c
@@ -379,7 +379,7 @@ static int add_user_info(const char *wha
static int is_empty_line(const char *line, int len)
{
- while (len && isspace(line[len-1]))
+ while (len && is_space(line[len-1]))
len--;
return !len;
}
diff --git a/compat/strcasestr.c b/compat/strcasestr.c
index b96414d..d1a4253 100644
--- a/compat/strcasestr.c
+++ b/compat/strcasestr.c
@@ -12,7 +12,7 @@ char *gitstrcasestr(const char *haystack
for (j = 0; j < nlen; j++) {
unsigned char c1 = haystack[i+j];
unsigned char c2 = needle[j];
- if (toupper(c1) != toupper(c2))
+ if (to_upper(c1) != to_upper(c2))
goto next;
}
return (char *) haystack + i;
diff --git a/config.c b/config.c
index 519fecf..24b017f 100644
--- a/config.c
+++ b/config.c
@@ -40,7 +40,7 @@ static char *parse_value(void)
}
if (comment)
continue;
- if (isspace(c) && !quote) {
+ if (is_space(c) && !quote) {
space = 1;
continue;
}
@@ -97,9 +97,9 @@ static int get_value(config_fn_t fn, cha
c = get_next_char();
if (c == EOF)
break;
- if (!isalnum(c))
+ if (!is_alnum(c))
break;
- name[len++] = tolower(c);
+ name[len++] = to_lower(c);
if (len >= MAXNAME)
return -1;
}
@@ -128,11 +128,11 @@ static int get_base_var(char *name)
return -1;
if (c == ']')
return baselen;
- if (!isalnum(c))
+ if (!is_alnum(c))
return -1;
if (baselen > MAXNAME / 2)
return -1;
- name[baselen++] = tolower(c);
+ name[baselen++] = to_lower(c);
}
}
@@ -151,7 +151,7 @@ static int git_parse_file(config_fn_t fn
comment = 0;
continue;
}
- if (comment || isspace(c))
+ if (comment || is_space(c))
continue;
if (c == '#' || c == ';') {
comment = 1;
@@ -165,9 +165,9 @@ static int git_parse_file(config_fn_t fn
var[baselen] = 0;
continue;
}
- if (!isalpha(c))
+ if (!is_alpha(c))
break;
- var[baselen] = tolower(c);
+ var[baselen] = to_lower(c);
if (get_value(fn, var, baselen+1) < 0)
break;
}
diff --git a/convert-objects.c b/convert-objects.c
index a892013..621c1bb 100644
--- a/convert-objects.c
+++ b/convert-objects.c
@@ -166,7 +166,7 @@ static unsigned long parse_oldstyle_date
const char **fmt = formats;
p = buffer;
- while (isspace(c = *buf))
+ while (is_space(c = *buf))
buf++;
while ((c = *buf++) != '\n')
*p++ = c;
@@ -181,7 +181,7 @@ static unsigned long parse_oldstyle_date
buf = next;
} else {
const char **p = timezones;
- while (isspace(*buf))
+ while (is_space(*buf))
buf++;
while (*p) {
if (!memcmp(buf, *p, strlen(*p))) {
@@ -217,7 +217,7 @@ static int convert_date_line(char *dst,
dst += len;
/* Is it already in new format? */
- if (isdigit(*date)) {
+ if (is_digit(*date)) {
int datelen = next - date;
memcpy(dst, date, datelen);
return len + datelen;
diff --git a/date.c b/date.c
index 63f5a09..340052d 100644
--- a/date.c
+++ b/date.c
@@ -131,9 +131,9 @@ static int match_string(const char *date
for (i = 0; *date; date++, str++, i++) {
if (*date == *str)
continue;
- if (toupper(*date) == toupper(*str))
+ if (to_upper(*date) == to_upper(*str))
continue;
- if (!isalnum(*date))
+ if (!is_alnum(*date))
break;
return 0;
}
@@ -145,7 +145,7 @@ static int skip_alpha(const char *date)
int i = 0;
do {
i++;
- } while (isalpha(date[i]));
+ } while (is_alpha(date[i]));
return i;
}
@@ -229,7 +229,7 @@ static int match_multi_number(unsigned l
num2 = strtol(end+1, &end, 10);
num3 = -1;
- if (*end == c && isdigit(end[1]))
+ if (*end == c && is_digit(end[1]))
num3 = strtol(end+1, &end, 10);
/* Time? Date? */
@@ -295,7 +295,7 @@ static int match_digit(const char *date,
case ':':
case '/':
case '-':
- if (isdigit(end[1])) {
+ if (is_digit(end[1])) {
int match = match_multi_number(num, *end, date, end, tm);
if (match)
return match;
@@ -310,7 +310,7 @@ static int match_digit(const char *date,
n = 0;
do {
n++;
- } while (isdigit(date[n]));
+ } while (is_digit(date[n]));
/* Four-digit year or a timezone? */
if (n == 4) {
@@ -420,11 +420,11 @@ int parse_date(const char *date, char *r
if (!c || c == '\n')
break;
- if (isalpha(c))
+ if (is_alpha(c))
match = match_alpha(date, &tm, &offset);
- else if (isdigit(c))
+ else if (is_digit(c))
match = match_digit(date, &tm, &offset, &tm_gmt);
- else if ((c == '-' || c == '+') && isdigit(date[1]))
+ else if ((c == '-' || c == '+') && is_digit(date[1]))
match = match_tz(date, &offset);
if (!match) {
diff --git a/diff-tree.c b/diff-tree.c
index 382011a..f7b16eb 100644
--- a/diff-tree.c
+++ b/diff-tree.c
@@ -137,7 +137,7 @@ static int diff_tree_stdin(char *line)
line[len-1] = 0;
if (get_sha1_hex(line, commit))
return -1;
- if (isspace(line[40]) && !get_sha1_hex(line+41, parent)) {
+ if (is_space(line[40]) && !get_sha1_hex(line+41, parent)) {
line[40] = 0;
line[81] = 0;
sprintf(this_header, "%s (from %s)\n", line, line+41);
diff --git a/ident.c b/ident.c
index bc89e1d..0a3d735 100644
--- a/ident.c
+++ b/ident.c
@@ -34,7 +34,7 @@ static void copy_gecos(struct passwd *w,
}
if (len + nlen < sz) {
/* Sorry, Mr. McDonald... */
- *dst++ = toupper(*w->pw_name);
+ *dst++ = to_upper(*w->pw_name);
memcpy(dst, w->pw_name + 1, nlen - 1);
dst += nlen - 1;
}
diff --git a/mailinfo.c b/mailinfo.c
index cb853df..3a06240 100644
--- a/mailinfo.c
+++ b/mailinfo.c
@@ -6,9 +6,10 @@
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
-#include <ctype.h>
#include <iconv.h>
+#include "cache.h"
+
#ifdef NO_STRCASESTR
extern char *gitstrcasestr(const char *haystack, const char *needle);
#endif
@@ -61,7 +62,7 @@ static int handle_from(char *line)
*/
while (at > line) {
char c = at[-1];
- if (isspace(c))
+ if (is_space(c))
break;
if (c == '<') {
at[-1] = ' ';
@@ -72,7 +73,7 @@ static int handle_from(char *line)
dst = email;
for (;;) {
unsigned char c = *at;
- if (!c || c == '>' || isspace(c)) {
+ if (!c || c == '>' || is_space(c)) {
if (c == '>')
*at = ' ';
break;
@@ -90,7 +91,7 @@ static int handle_from(char *line)
at = line + strlen(line);
while (at > line) {
unsigned char c = *--at;
- if (!isspace(c)) {
+ if (!is_space(c)) {
at[(c == ')') ? 0 : 1] = 0;
break;
}
@@ -99,7 +100,7 @@ static int handle_from(char *line)
at = line;
for (;;) {
unsigned char c = *at;
- if (!c || !isspace(c)) {
+ if (!c || !is_space(c)) {
if (c == '(')
at++;
break;
@@ -164,7 +165,7 @@ static int handle_subcontent_type(char *
if (*charset) {
int i, c;
for (i = 0; (c = charset[i]) != 0; i++)
- charset[i] = tolower(c);
+ charset[i] = to_lower(c);
}
return 0;
}
@@ -199,7 +200,7 @@ static int is_multipart_boundary(const c
static int eatspace(char *line)
{
int len = strlen(line);
- while (len > 0 && isspace(line[len-1]))
+ while (len > 0 && is_space(line[len-1]))
line[--len] = 0;
return len;
}
@@ -211,27 +212,27 @@ static int eatspace(char *line)
/* First lines of body can have From:, Date:, and Subject: */
static int handle_inbody_header(int *seen, char *line)
{
- if (!memcmp("From:", line, 5) && isspace(line[5])) {
+ if (!memcmp("From:", line, 5) && is_space(line[5])) {
if (!(*seen & SEEN_FROM) && handle_from(line+6)) {
*seen |= SEEN_FROM;
return 1;
}
}
- if (!memcmp("Date:", line, 5) && isspace(line[5])) {
+ if (!memcmp("Date:", line, 5) && is_space(line[5])) {
if (!(*seen & SEEN_DATE)) {
handle_date(line+6);
*seen |= SEEN_DATE;
return 1;
}
}
- if (!memcmp("Subject:", line, 8) && isspace(line[8])) {
+ if (!memcmp("Subject:", line, 8) && is_space(line[8])) {
if (!(*seen & SEEN_SUBJECT)) {
handle_subject(line+9);
*seen |= SEEN_SUBJECT;
return 1;
}
}
- if (!memcmp("[PATCH]", line, 7) && isspace(line[7])) {
+ if (!memcmp("[PATCH]", line, 7) && is_space(line[7])) {
if (!(*seen & SEEN_SUBJECT)) {
handle_subject(line);
*seen |= SEEN_SUBJECT;
@@ -282,10 +283,10 @@ static void cleanup_space(char *buf)
unsigned char c;
while ((c = *buf) != 0) {
buf++;
- if (isspace(c)) {
+ if (is_space(c)) {
buf[-1] = ' ';
c = *buf;
- while (isspace(c)) {
+ while (is_space(c)) {
int len = strlen(buf);
memmove(buf, buf+1, len);
c = *buf;
@@ -312,7 +313,7 @@ static void check_header(char *line, int
for (i = 0; header[i].name; i++) {
int len = header[i].namelen;
if (!strncasecmp(line, header[i].name, len) &&
- line[len] == ':' && isspace(line[len + 1])) {
+ line[len] == ':' && is_space(line[len + 1])) {
header[i].func(line + len + 2);
break;
}
@@ -491,7 +492,7 @@ static void decode_header_bq(char *it)
if (!cp)
return; /* no munging */
for (sp = ep; sp < cp; sp++)
- charset_q[sp - ep] = tolower(*sp);
+ charset_q[sp - ep] = to_lower(*sp);
charset_q[cp - ep] = 0;
encoding = cp[1];
if (!encoding || cp[2] != '?')
@@ -499,7 +500,7 @@ static void decode_header_bq(char *it)
ep = strstr(cp + 3, "?=");
if (!ep)
return; /* no munging */
- switch (tolower(encoding)) {
+ switch (to_lower(encoding)) {
default:
return; /* no munging */
case 'b':
@@ -709,11 +710,6 @@ static void handle_body(void)
static const char mailinfo_usage[] =
"git-mailinfo [-k] [-u] msg patch <mail >info";
-static void usage(void) {
- fprintf(stderr, "%s\n", mailinfo_usage);
- exit(1);
-}
-
int main(int argc, char **argv)
{
while (1 < argc && argv[1][0] == '-') {
@@ -722,12 +718,12 @@ int main(int argc, char **argv)
else if (!strcmp(argv[1], "-u"))
metainfo_utf8 = 1;
else
- usage();
+ usage(mailinfo_usage);
argc--; argv++;
}
if (argc != 3)
- usage();
+ usage(mailinfo_usage);
cmitmsg = fopen(argv[1], "w");
if (!cmitmsg) {
perror(argv[1]);
diff --git a/mailsplit.c b/mailsplit.c
index 189f4ed..de9fb2b 100644
--- a/mailsplit.c
+++ b/mailsplit.c
@@ -33,11 +33,11 @@ static int is_from_line(const char *line
break;
}
- if (!isdigit(colon[-4]) ||
- !isdigit(colon[-2]) ||
- !isdigit(colon[-1]) ||
- !isdigit(colon[ 1]) ||
- !isdigit(colon[ 2]))
+ if (!is_digit(colon[-4]) ||
+ !is_digit(colon[-2]) ||
+ !is_digit(colon[-1]) ||
+ !is_digit(colon[ 1]) ||
+ !is_digit(colon[ 2]))
return 0;
/* year */
diff --git a/pack-objects.c b/pack-objects.c
index b3e6152..314616d 100644
--- a/pack-objects.c
+++ b/pack-objects.c
@@ -464,7 +464,7 @@ int main(int argc, char **argv)
p = line+40;
while (*p) {
unsigned char c = *p++;
- if (isspace(c))
+ if (is_space(c))
continue;
hash = hash * 11 + c;
}
diff --git a/patch-id.c b/patch-id.c
index edbc4aa..ba09d2a 100644
--- a/patch-id.c
+++ b/patch-id.c
@@ -21,7 +21,7 @@ static int remove_space(char *line)
unsigned char c;
while ((c = *src++) != '\0') {
- if (!isspace(c))
+ if (!is_space(c))
*dst++ = c;
}
return dst - line;
diff --git a/refs.c b/refs.c
index 97506a4..4d202ee 100644
--- a/refs.c
+++ b/refs.c
@@ -43,7 +43,7 @@ int validate_symref(const char *path)
return -1;
buf = buffer + 4;
len -= 4;
- while (len && isspace(*buf))
+ while (len && is_space(*buf))
buf++, len--;
if (len >= 5 && !memcmp("refs/", buf, 5))
return 0;
@@ -103,9 +103,9 @@ const char *resolve_ref(const char *path
break;
buf = buffer + 4;
len -= 4;
- while (len && isspace(*buf))
+ while (len && is_space(*buf))
buf++, len--;
- while (len && isspace(buf[len-1]))
+ while (len && is_space(buf[len-1]))
buf[--len] = 0;
path = git_path("%.*s", len, buf);
}
diff --git a/stripspace.c b/stripspace.c
index 96cd0a8..a6204b6 100644
--- a/stripspace.c
+++ b/stripspace.c
@@ -1,6 +1,6 @@
#include <stdio.h>
#include <string.h>
-#include <ctype.h>
+#include "cache.h"
/*
* Remove empty lines from the beginning and end.
@@ -15,7 +15,7 @@ static void cleanup(char *line)
if (len > 1 && line[len-1] == '\n') {
do {
unsigned char c = line[len-2];
- if (!isspace(c))
+ if (!is_space(c))
break;
line[len-2] = '\n';
len--;
^ permalink raw reply related
* Re: Problem getting older version
From: Nico -telmich- Schottelius @ 2005-10-24 5:23 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20051020014230.GV30889@pasky.or.cz>
[-- Attachment #1: Type: text/plain, Size: 1433 bytes --]
Thanks Petr!
Didn't have the time (and network connection, writing offline currently) to
test latest cogito/git for the other errors, but will do that on monday.
Nico
Petr Baudis [Thu, Oct 20, 2005 at 03:42:30AM +0200]:
> Hello,
>
> Dear diary, on Wed, Oct 19, 2005 at 10:00:46AM CEST, I got a letter
> where Nico -telmich- Schottelius <nico-linux-git@schottelius.org> told me that...
> > The following situation:
> >
> > - The last commit was a merge, mhich broke some files
> > - We want three files from the commit before
> ..snip..
> > Is this really the standard way to recover a file? As a developer / end user I would expect that:
> >
> > cg-recover <filename> <commit id> and -f for overwriting the file if it exists
>
> thanks for the suggestion. I've revamped cg-restore to support this
> kind of syntax, so now if you do
>
> cg-restore -r ID [-f] FILENAME
>
> it should do what you want.
>
> --
> Petr "Pasky" Baudis
> Stuff: http://pasky.or.cz/
> VI has two modes: the one in which it beeps and the one in which
> it doesn't.
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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: LCA2006 Git/Cogito tutorial
From: Martin Langhoff @ 2005-10-24 6:25 UTC (permalink / raw)
To: Petr Baudis
Cc: Horst von Brand, Martin Langhoff (CatalystIT), Dmitry Torokhov,
git
In-Reply-To: <20051023224022.GX30889@pasky.or.cz>
On 10/24/05, Petr Baudis <pasky@suse.cz> wrote:
> Dear diary, on Sun, Oct 23, 2005 at 05:33:43PM CEST, I got a letter
> where Horst von Brand <vonbrand@inf.utfsm.cl> told me that...
> > Martin Langhoff (CatalystIT) <martin@catalyst.net.nz> wrote:
> > [...]
> > > MERGE ERROR: : Not handling case -> ->
> >
> > It happens when a new file with the same name appears in both parents. For
> > example, we both see the need for a README file, and then I pull from you
> > and try to merge into my version.
>
> It certainly shouldn't happen with precisely that error message - there
> should be at least something written between the arrows. And yes, there
> are unhandled cases like that, as I wrote in one of my other mails.
As I painfully discovered later, I had updated my tree at the wrong
time, and got caught with a cg-Xmerge.sh that had lost all its
parameters over the numbered params/named params transition. I got a
fresh checkout, rebased my local patches, and life is good again.
Sorry about the noise!
martin
^ permalink raw reply
* Re: User-relative paths
From: Daniel Barkalow @ 2005-10-24 6:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
In-Reply-To: <7voe5gypvi.fsf@assigned-by-dhcp.cox.net>
On Sun, 23 Oct 2005, Junio C Hamano wrote:
> Petr Baudis <pasky@suse.cz> writes:
>
> >> diff --git a/Makefile b/Makefile
> >> index 903c57c..87188ea 100644
> >> --- a/Makefile
> >> +++ b/Makefile
> >> @@ -359,6 +362,9 @@ git-cherry-pick: git-revert
> >> %.o: %.S
> >> $(CC) -o $*.o -c $(ALL_CFLAGS) $<
> >>
> >> +$(SERVERSIDE_PROGRAMS) : git-%$X : %.o srvside-ssh.o $(LIB_FILE)
> >> + $(CC) $(ALL_CFLAGS) -o $@ $(filter %o,$^) $(LIBS)
> >> +
> >> git-%$X: %.o $(LIB_FILE)
> >> $(CC) $(ALL_CFLAGS) -o $@ $(filter %.o,$^) $(LIBS)
> >>
> >
> > Why are you adding own compilation command, and why is it inconsistent
> > with the git-%$X's one?
>
> Although I'd prefer the simplicity of putting srvside-ssh.o in
> LIB_OBJS, this is arguably defensible; it avoids relinking of
> everything else merely because srvside-ssh.c is changed.
The line:
$(SERVERSIDE_PROGRAMS): srvside-ssh.o
would suffice for that.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: git-snapshot.sh
From: Nico -telmich- Schottelius @ 2005-10-24 7:10 UTC (permalink / raw)
To: Johannes Schindelin, Petr Baudis; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0510180021120.15669@wbgn013.biozentrum.uni-wuerzburg.de>
[-- Attachment #1: Type: text/plain, Size: 1440 bytes --]
Hmpf, didn't know of those two alternatives, thanks!
Nico
Johannes Schindelin [Tue, Oct 18, 2005 at 12:21:50AM +0200]:
> Hi,
>
> On Tue, 18 Oct 2005, Nico -telmich- Schottelius wrote:
>
> > I really like to have a snapshot available from my sources in VCS.
> >
> > Therefore I wrote the attached script.
> >
> > git-tar-tree $(git-log | head -n1 | awk '{ print $2 }')
>
> And why not "git-tar-tree HEAD"?
>
> Ciao,
> Dscho
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Petr Baudis [Thu, Oct 20, 2005 at 11:01:02AM +0200]:
> Hello,
>
> Dear diary, on Tue, Oct 18, 2005 at 12:06:15AM CEST, I got a letter
> where Nico -telmich- Schottelius <nico-linux-git@schottelius.org> told me that...
> > I really like to have a snapshot available from my sources in VCS.
> >
> > Therefore I wrote the attached script.
> >
> > Just wanted to send it, perhaps someone can use it.
>
> and the others can use
>
> cg-export snapshot.tar.bz2
>
> ;-)
>
> --
> Petr "Pasky" Baudis
> Stuff: http://pasky.or.cz/
> VI has two modes: the one in which it beeps and the one in which
> it doesn't.
--
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
* gitweb: charset problem
From: Nico -telmich- Schottelius @ 2005-10-24 7:18 UTC (permalink / raw)
To: Kay Sievers, Git Mailing List; +Cc: Christian Gierke, Peter Portmann
[-- Attachment #1: Type: text/plain, Size: 1034 bytes --]
Hello!
gitweb (my $version = "247";) seems to send utf-8 as meta tag encoding
(<meta http-equiv="content-type" content="text/html; charset=utf-8"/>).
The problem is that the name of the user "HansjOErg" (OE is the german umlaut)
is in iso8859-1 in /etc/passwd.
This is guessed, but it does not look like utf-8, as it's a one byte encoding:
00007b0: 3031 323a 3130 303a 4861 6e73 6af6 7267 012:100:Hansj.rg
What would be the correct way to fix that? Change the username to utf-8?
(Is this possible without causing problems in other programs?)
Or tell gitweb that it should convert non-UTF-8 to UTF-8?
But we also have another problem: Sometimes we have umlauts in the commit messages.
Those are also displayed incorrectly. When I switch to iso-8859-1 encoding in mozilla,
the characters in the username and in the commit message are ok.
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: LCA2006 Git/Cogito tutorial
From: Petr Baudis @ 2005-10-24 7:54 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Martin Langhoff (CatalystIT), git
In-Reply-To: <Pine.LNX.4.64.0510231804430.10477@g5.osdl.org>
Dear diary, on Mon, Oct 24, 2005 at 03:35:43AM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> told me that...
> Oh, the git merge is about a million times better than any silly weave
> merge with extra BonusPoints and MagicCapitalizedNames.
>
> Why? Because if you want to be slow and careful, you can always just
> create the weave after-the-fact and do a weave merge.
This doesn't make sense. Those silly weave merges only describe what to
do with the weave to do the merge, not how you got the weave in the
first place.
> So we should spend time on making it easy to see what the clash was, and
> on tools to help resolve them. Some random merge-strategy-of-the-day is
> just bling-bling.
The *primary* reason for new merge strategies is not reducing number
of conflicts, but actually being able to force a conflict at places
where it isn't crystal-clear what the resolution should be (but not
conflicting where it should be clear), and especially at places where
the three-way merge *silently* gets it *wrong* without throwing any
conflicts. And weren't it you who wanted a conservative merge strategy
which wouldn't ever do that?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: LCA2006 Git/Cogito tutorial
From: Fredrik Kuivinen @ 2005-10-24 8:32 UTC (permalink / raw)
To: Petr Baudis; +Cc: Martin Langhoff (CatalystIT), Dmitry Torokhov, git
In-Reply-To: <20051021091551.GE30889@pasky.or.cz>
On Fri, Oct 21, 2005 at 11:15:51AM +0200, Petr Baudis wrote:
> Dear diary, on Fri, Oct 21, 2005 at 04:59:06AM CEST, I got a letter
> where "Martin Langhoff (CatalystIT)" <martin@catalyst.net.nz> told me that...
> > Almost. No, truly, I'm very impressed with git-merge.sh, which first
> > does the simple git-read-tree -m, and it can then try several merger
> > scripts to resolve the index. The "smartest" merge resolver we have
> > follows renames, but we could have language-specific and
> > project-specific resolvers, for instance.
>
> Yes, following renames is nice. But as long as it is three-way, it
> suffers of inherent and rather nasty problems. Well, I'm watching the
> weave merge effort and plan to give it a try to port it to GIT when I
> have some time.
>
Which "inherent and rather nasty problems" are you referring to?
I do not know of any merge case which is either cleanly merged to the
wrong result by git-merge -s recursive, or cleanly merged when it
should be a conflict. (At least not if there aren't any directory
renames going on) If you know about such an example I would be very
interested in taking a look at it.
- Fredrik
^ permalink raw reply
* [RFC] GIT paths
From: Junio C Hamano @ 2005-10-24 8:50 UTC (permalink / raw)
To: git
Our networking commands can take either URL or non URL to
specify remote repository. This note first attempts to clarify
what <path> means in the current implementation, and then
discusses two possible enhancements.
A non URL always refers to the pack protocol going over an SSH
connection:
<host> ':' <path>
. path that starts with a slash '/' is absolute path on
the remote site.
. path that does not start with a slash '/' is relative
to the home directory of the incoming user.
However, note that the administrator could futz with the login
shell of the user to give restricted access (chroot to change
the former). The latter can be made different from the home
directory, if git-shell is changed to chdir() to somewhere else
first. I am not suggesting this as a best practice -- just
mentioning the possibility for completeness.
A URL form is:
<proto> ':' <host> ( ':' <port> ) '/' <rest-of-path>
and <proto> is either 'git', or 'ssh' (also spelled as 'ssh+git'
or 'git+ssh'). In addition, you can use 'http' or 'rsync', but
these transports are not discussed further here. They already
have established semantics for <path> = '/' + <rest-of-path>.
For connections over plain TCP talking with git-daemon, or over
SSH in this form, path is always relative to the root directory
on the remote site, because '/' that terminate either <host> or
<port> starts the <path> = '/' + <rest-of-path>.
There are two things I would like to discuss here.
- It might make sense to have SERVER_ROOT (similar to
DOCUMENT_ROOT in Apache) for git-daemon, so <path> does not
have to be relative to the true filesystem root. Note that
this is not a security measure, but meant for administration
convenience [*1*].
- Over a git-daemon connection, supporting ~user expansion
makes sense. E.g git://host.xz/~junio/ refers to my home
directory on that machine. It would make it impossible to
have a directory literally named '~junio' directly underneath
the root directory, but that is a good limitation anyway.
The above enhancements, especially SERVER_ROOT, however make
paths inconsistent between non URL form and URL form. This
probably is OK -- people are used to using different paths when
uploading to HTTP server and testing a download from it. That
leaves one issue. Do we want to support ~user expansion, and if
so how, on non git-daemon connections?
I would propose that
git fetch host.xz:~junio/repo
git fetch ssh://host.xz/~junio/repo
mean the same thing (i.e. both understand ~user expansion).
Also these are equivalent (i.e. no ~user expansion; both mean
absolute filesystem path without SERVER_ROOT prefixing):
git fetch host.xz:/frotz/repo
git fetch ssh://host.xz/frotz/repo
While these two might not mean the same thing (the former is
prefixed with SERVER_ROOT, but not the latter):
git fetch git://host.xz/frotz/repo
git fetch ssh://host.xz/frotz/repo
There are small technical issues.
- connect.c should not be affected at all, since it does not
know how the remote site arranges SERVER_ROOT (if we support
it) or user home directories.
- ssh://host.xz/path and host.xz:path connections spawn
upload-pack or receive-pack directly, without being mediated
by git-daemon. This means that ~user expansion, if we want
to support it, needs to be done by these programs themselves.
- git-daemon needs to validate the incoming requested path and
in order to avoid aliasing issues, we should resolve ~user
expansion and SERVER_ROOT prefixing first, then validate the
resulting path against white/black list, before calling
upload-pack or receive-pack. However, after git-daemon
decides to run these programs, they could find out some
problems with the specified repository and may need to report
them. Arguably, this reporting should not reveal the real
path used to address the repository [*2*].
Although we _could_ forget about the "error reporting exposing
real path" issue for now, I think we should at least have a plan
to make things consistent and well defined. Here is a strawman:
- Have a common library code that takes user supplied path and
does SERVER_ROOT prefixing and ~user expansion.
- Have git-daemon use it to canonicalize the requested path
before validating. Make it invoke the programs with the path
received from the other end (before SERVER_ROOT prefixing, or
~user expansion).
- Give --server-root=/path/to/root flag to programs that can be
called by git-daemon, and have git-daemon run them with this
flag. Have them use the same library to canonicalize the
requested path to the real path. When these programs are run
via direct SSH connection (i.e. ssh://host/path and
host:path), this flag is not given so they see filesystem
path as-is, but make the ~user expansion still available.
[Footnote]
*1* You do not want to advertise your repo is at /mnt/disk1/repo
and find out that you need to move the disks around next day.
Of course you could plan ahead and have a symlink hanging below
the root directory (e.g. '/pub -> /mnt/disk1/git'), but it is so
much more convenient if you can just tell git-daemon that the
root level used to be /mnt/disk1/git but it is now somewhere
else.
*2* This is theoretical right now, since packed transfer
protocols cannot report errors back, but Andreas' patch
addresses this issue by dying carefully in srvside_chdir(). It
falls into security-by-obscurity category, so we may choose not
to worry about it, though.
^ permalink raw reply
* "Racy" GIT
From: Petr Baudis @ 2005-10-24 9:29 UTC (permalink / raw)
To: git
Hello,
I've thought that I might describe the race I've hit the last night
here so that if you meet it too, you will have an idea what is going on
and won't waste your time debugging it, like I did. ;-)
What did I do:
echo v1 >file
cg-add file
cg-commit -m"v1"
echo v2 >file
cg-commit -m"v2"
Guess what - the second cg-commit didn't commit the new version of the
file. git-diff-index didn't show anything. GIT just didn't care about
the change.
Obviously, the problem was that the stat information was exactly the
same after the change (it was in a script, so no ctime change, and the
size was the same as well). The solution is to tell git/Cogito about the
change explicitly (in Cogito, you can do that e.g. by calling cg-add on
the file again). This can be obviously very confusing (and dangerous),
but if we want to keep the stat caching, I guess there is no way around
this (except for sub-second ctimes, but that effectively killed the stat
caching on the filesystems which didn't support it).
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: LCA2006 Git/Cogito tutorial
From: Junio C Hamano @ 2005-10-24 9:44 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20051024075431.GY30889@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Dear diary, on Mon, Oct 24, 2005 at 03:35:43AM CEST, I got a letter
> where Linus Torvalds <torvalds@osdl.org> told me that...
>> Oh, the git merge is about a million times better than any silly weave
>> merge with extra BonusPoints and MagicCapitalizedNames.
>>
>> Why? Because if you want to be slow and careful, you can always just
>> create the weave after-the-fact and do a weave merge.
>
> This doesn't make sense. Those silly weave merges only describe what to
> do with the weave to do the merge, not how you got the weave in the
> first place.
True, but it should not be a problem that is made harder for you
to solve by the fact that our repository is not based on weaves.
Unless an weave-based SCM comes with an integrated editor that
records line insertion and deletion user actions and forces
users to use that editor and nothing else, it also has to work
on two whole files (pre- and post-modification) in order to find
the matching lines and figure out the weave to record, on top of
the history before pre-modification image. I think you have the
same information as they have to create the weave after the fact
for each commit in that sense.
^ permalink raw reply
* Re: gitweb: charset problem
From: Kay Sievers @ 2005-10-24 12:34 UTC (permalink / raw)
To: Nico -telmich- Schottelius
Cc: Git Mailing List, Christian Gierke, Peter Portmann
In-Reply-To: <20051024071839.GB4608@schottelius.org>
On Mon, Oct 24, 2005 at 09:18:39AM +0200, Nico -telmich- Schottelius wrote:
> gitweb (my $version = "247";) seems to send utf-8 as meta tag encoding
> (<meta http-equiv="content-type" content="text/html; charset=utf-8"/>).
Yes, that's is intentional, also the http header is overwritten, if the
webserver's default is not utf8.
> The problem is that the name of the user "HansjOErg" (OE is the german umlaut)
> is in iso8859-1 in /etc/passwd.
Huh, not sure if it's a good idea to put that into a username,
never tried or ever seen that.
> This is guessed, but it does not look like utf-8, as it's a one byte encoding:
>
> 00007b0: 3031 323a 3130 303a 4861 6e73 6af6 7267 012:100:Hansj.rg
Sure, 0xf6 is the single letter 'ö' (oe) in iso-8859.
> What would be the correct way to fix that? Change the username to utf-8?
> (Is this possible without causing problems in other programs?)
> Or tell gitweb that it should convert non-UTF-8 to UTF-8?
Don't know. At best get rid of the non-ascii chars in /etc/passwd
if you don't want to get in trouble... :)
All other programs sure, should definitely use utf8.
> But we also have another problem: Sometimes we have umlauts in the commit messages.
> Those are also displayed incorrectly. When I switch to iso-8859-1 encoding in mozilla,
> the characters in the username and in the commit message are ok.
utf8 is the one and only sane encoding if you need more than ascii chars.
Just convert everything to utf8 from your locale to your webserver and
all that pain will go away immediately. :)
Best,
Kay
^ permalink raw reply
* Re: LCA2006 Git/Cogito tutorial
From: Horst von Brand @ 2005-10-24 0:22 UTC (permalink / raw)
To: Petr Baudis
Cc: Horst von Brand, Martin Langhoff (CatalystIT), Dmitry Torokhov,
git
In-Reply-To: <20051023224022.GX30889@pasky.or.cz>
Petr Baudis <pasky@suse.cz> wrote:
> Dear diary, on Sun, Oct 23, 2005 at 05:33:43PM CEST, I got a letter
> where Horst von Brand <vonbrand@inf.utfsm.cl> told me that...
> > Martin Langhoff (CatalystIT) <martin@catalyst.net.nz> wrote:
> > [...]
> > > MERGE ERROR: : Not handling case -> ->
> > It happens when a new file with the same name appears in both parents. For
> > example, we both see the need for a README file, and then I pull from you
> > and try to merge into my version.
> It certainly shouldn't happen with precisely that error message - there
> should be at least something written between the arrows.
It does now.
> And yes, there
> are unhandled cases like that, as I wrote in one of my other mails.
Yep, thanks!
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ 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