* Re: [RFC] Applying a graft to a tree and "rippling" the changes through
From: Linus Torvalds @ 2005-11-19 1:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3bltea1t.fsf@assigned-by-dhcp.cox.net>
On Fri, 18 Nov 2005, Junio C Hamano wrote:
>
> At the same time, I am sympathetic if somebody wants to be able to say
> just "The change this commit brings in can be used to modify the
> behaviour X to Y".
Well, you can obviously use a commit that way, and indeed, every time we
do a "rebase", that's effectively saying "I know the commit has history,
but now I want to use it purely as a tree conversion".
I'm not convinced we ever really _need_ a pure "tree-to-tree" thing,
although you can always do that by creating an extra commit with no parent
and thus no history ;)
Linus
^ permalink raw reply
* Re: Rss produced by git is not valid xml?
From: Linus Torvalds @ 2005-11-19 1:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vek5deam6.fsf@assigned-by-dhcp.cox.net>
On Fri, 18 Nov 2005, Junio C Hamano wrote:
>
> Pulls are "too late, sorry you have to live with it"; for
> patches, mailinfo and am have -u (I do not remember if I added
> it to applymbox -- I do not use applymbox anymore myself).
It's in applymbox too, although the default is not to use it (and
applymbox only supports the short "-u" form, not the "--utf8" one).
> Maybe we should make -u the default and countermand with -U to
> encourage the use of utf8 further?
Probably.
Although right now "-u" doesn't actually _force_ a conversion: if you have
an email with 8-bit characters and no character set mentioned, it will
silently just do nothing, and the end result won't be valid UTF-8 after
all.
I think. You're the one who wrote all the conversion stuff ;)
If we want utf-8, we should probably force it, and default to the latin1
translation (with some way to specify alternatives).
Linus
^ permalink raw reply
* Re: [RFC] Applying a graft to a tree and "rippling" the changes through
From: Junio C Hamano @ 2005-11-19 0:49 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0511180915560.13959@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Fri, 18 Nov 2005, sf wrote:
>>
>> A commit is really just the statement: "I changed the tree from state A to
>> state B". After all, the commit message does not describe the new state
>> (neither the old state) but does describe the changes.
>
> There are lots of changelog entries that don't necessarily make sense
> without knowing what went before them, so history is actually important
> even in a local sense - it's often what allows the explanation to make
> sense.
I agree with what you said about commit objects and what they
are meant to describe. At the same time, I am sympathetic if
somebody wants to be able to say just "The change this commit
brings in can be used to modify the behaviour X to Y". An
implied prerequisite for such a statement is that you can apply
such a change only to something that has behaviour X, and
internally works in a certain way to exhibit that behaviour, to
begin with (IOW, otherwise the patch does not apply). While
your "commit describes all the history leading to it" obviously
satisfies that prerequisite, it is stronger than necessary.
For that matter, "tree A changed into tree B" is stronger than
necessary as well. There are trees other than tree A that has
the same behaviour X, and applying such a change would be valid
to modify its behaviour to Y.
You are absolutely right that commit messages should be taken in
the context of the history leading to it. However, when we
exchange patches via e-mail, or do "rebase" in the repository,
we also use the commit message to label the change -- and with
that usage, the log message becomes less about describing the
history and more about "modifies X to Y", so it is easy to get
confused.
^ permalink raw reply
* Re: Teach "approxidate" about weekday syntax
From: Linus Torvalds @ 2005-11-19 0:48 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Junio C Hamano, git
In-Reply-To: <437E6CAB.8060200@op5.se>
On Sat, 19 Nov 2005, Andreas Ericsson wrote:
>
> nox!exon:~$ date --iso-8601=seconds
> 2005-11-19T01:04:56+0100
>
> No human will spell it with T though.
Git doesn't care.
./test-date 2005-11-19T01:04:56+0100
results in
2005-11-19T01:04:56+0100 -> 1132358696 +0100 -> Fri Nov 18 16:04:56 2005
which should be correct: I'm in PST, test-date shows the "git time"
(seconds since the epoch plus TZ) and then the local time in
human-readable ascii.
The "T" to the git date parser is just a superfluous character that just
happens to be a perfectly valid way to separate out the numbers ;)
Linus
^ permalink raw reply
* Re: Rss produced by git is not valid xml?
From: Junio C Hamano @ 2005-11-19 0:37 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0511181520390.13959@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Of course, you could equally easily (more so?) make it just a commit
> trigger instead, which might well be the right thing.
I think it is the right approach. As I repeatedly said (not
that repeating things makes them right) on this list, I think
that the interpretation of what is in commit log is a policy
issue that is local to each project.
> (And that still leaves the question open what to do about patches and
> pulls, but if people mainly worry about newly written commit messages
> itself, then at least that part is unambiguous).
Pulls are "too late, sorry you have to live with it"; for
patches, mailinfo and am have -u (I do not remember if I added
it to applymbox -- I do not use applymbox anymore myself).
Maybe we should make -u the default and countermand with -U to
encourage the use of utf8 further?
^ permalink raw reply
* Re: Rss produced by git is not valid xml?
From: Johannes Schindelin @ 2005-11-19 0:34 UTC (permalink / raw)
To: Linus Torvalds; +Cc: H. Peter Anvin, Kay Sievers, Ismail Donmez, git
In-Reply-To: <Pine.LNX.4.64.0511181520390.13959@g5.osdl.org>
Hi,
On Fri, 18 Nov 2005, Linus Torvalds wrote:
> This I agree with, btw. We could easily have a
>
> [core]
> utf=1
>
> thing, and make git-commit-tree refuse to commit a non-UTF8 message.
>
> Of course, you could equally easily (more so?) make it just a commit
> trigger instead, which might well be the right thing.
Actually, hooks have been introduced for exactly that purpose! Besides,
they are a much more powerful tool. For example, you can not only enforce
utf-8, but also replace words from a swear words list by "*beep*".
So, hooks are the way to go. Introducing another way to accomplish the
same thing would be like Microsoft, implementing hundreds of APIs for the
same task, none of them correct.
I can only underline what Linus said here: Software should work for
people, not the other way round. Please, before you send some BS like
"utf-8 is the only reasonable thing for everybody, everywhere, ever", read
that sentence in Linus' mail again. Software should *not* restrict anybody
for non-technical reasons. ever. Period.
Ciao,
Dscho
^ permalink raw reply
* Re: Rss produced by git is not valid xml?
From: Johannes Schindelin @ 2005-11-19 0:29 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Linus Torvalds, Kay Sievers, Ismail Donmez, git
In-Reply-To: <437E6AC2.3080905@zytor.com>
Hi,
On Fri, 18 Nov 2005, H. Peter Anvin wrote:
> And in *either* case you may want to convert commit messages.
You may, and you may not. Remember, this is *free* software. If there is
no technical point to it, you should not restrict people. Else you get
forked...
Hth,
Dscho
^ permalink raw reply
* Re: Teach "approxidate" about weekday syntax
From: Randal L. Schwartz @ 2005-11-19 0:28 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Junio C Hamano, Linus Torvalds, git
In-Reply-To: <437E6CAB.8060200@op5.se>
>>>>> "Andreas" == Andreas Ericsson <ae@op5.se> writes:
>>> [torvalds@g5 git]$ ./test-date "2005-11-02 14:45:00"
>> Doesn't ISO spell that as "2005-11-02T14:45:00"?
>>
Andreas> nox!exon:~$ date --iso-8601=seconds
Andreas> 2005-11-19T01:04:56+0100
Andreas> No human will spell it with T though.
But they might be getting it out of another tool like that.
And, let me apologize for derailing Linus for a week. Sorry. :)
--
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: Teach "approxidate" about weekday syntax
From: Andreas Ericsson @ 2005-11-19 0:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7vzmo1ecbf.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Linus Torvalds <torvalds@osdl.org> writes:
>
>
>>On Fri, 18 Nov 2005, Randy.Dunlap wrote:
>>
>>>~Randy [who would just use ISO standard date format]
>>
>>That actually _does_ work, and has done so since the beginning:
>>
>> [torvalds@g5 git]$ ./test-date "2005-11-02 14:45:00"
>
>
> Doesn't ISO spell that as "2005-11-02T14:45:00"?
>
nox!exon:~$ date --iso-8601=seconds
2005-11-19T01:04:56+0100
No human will spell it with T though.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Rss produced by git is not valid xml?
From: Johannes Schindelin @ 2005-11-19 0:04 UTC (permalink / raw)
To: Kay Sievers; +Cc: Ismail Donmez, git
In-Reply-To: <20051118200217.GA2831@vrfy.org>
Hi,
On Fri, 18 Nov 2005, Kay Sievers wrote:
> Yes, convince the git maintainers, that it's incredibly stupid not to
> enforce utf8 in commit messages. It makes absolutely zero sense in a
> SCM, which merges forth and back between people around the world to
> allow random encodings from the last century.
Oh, but it makes sense! Just because you happen to work on a very
international project does not mean everybody does.
Just because you happen to like utf-8 does not mean that you still do in
2046. The encoding-du-jour might well be a 64-bit wide char code by then,
since they'll laugh about our dreaming about terabytes.
BTW, utf-8 was designed on purpose to be easily distinguishable from other
encodings so that you don't have to rely on every document obeying a
certain encoding.
Hth,
Dscho
^ permalink raw reply
* Re: Teach "approxidate" about weekday syntax
From: Junio C Hamano @ 2005-11-19 0:00 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0511180857170.13959@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Fri, 18 Nov 2005, Randy.Dunlap wrote:
>>
>> ~Randy [who would just use ISO standard date format]
>
> That actually _does_ work, and has done so since the beginning:
>
> [torvalds@g5 git]$ ./test-date "2005-11-02 14:45:00"
Doesn't ISO spell that as "2005-11-02T14:45:00"?
^ permalink raw reply
* Re: Rss produced by git is not valid xml?
From: H. Peter Anvin @ 2005-11-18 23:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Kay Sievers, Ismail Donmez, git
In-Reply-To: <Pine.LNX.4.64.0511181554580.13959@g5.osdl.org>
Linus Torvalds wrote:
>
> On Fri, 18 Nov 2005, H. Peter Anvin wrote:
>
>>There is another usage mode: "we're dumping CVS and switching to this
>>new-fangled git thing." I have myself done this with several projects by now.
>
>
> I agree that in that case, the problem space is _much_ simpler, and you're
> able to do much more.
>
> And I suspect it works well for projects with a few developers that can
> just afford to do that. And it obviously works for a big project with
> hundreds of developers that is forced to do it.
>
> But I suspect it's not the common way of doing things. There's already a
> few projects that do the "maintain in parallel" thing, like the Wine tree
> discussed a few days ago.
>
Oh, agreed. However, if you want to convert your master repository you
may want to do conversion.
And in *either* case you may want to convert commit messages.
-hpa
^ permalink raw reply
* Re: Rss produced by git is not valid xml?
From: Linus Torvalds @ 2005-11-18 23:57 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Kay Sievers, Ismail Donmez, git
In-Reply-To: <437E6505.8000201@zytor.com>
On Fri, 18 Nov 2005, H. Peter Anvin wrote:
>
> There is another usage mode: "we're dumping CVS and switching to this
> new-fangled git thing." I have myself done this with several projects by now.
I agree that in that case, the problem space is _much_ simpler, and you're
able to do much more.
And I suspect it works well for projects with a few developers that can
just afford to do that. And it obviously works for a big project with
hundreds of developers that is forced to do it.
But I suspect it's not the common way of doing things. There's already a
few projects that do the "maintain in parallel" thing, like the Wine tree
discussed a few days ago.
Linus
^ permalink raw reply
* Re: Rss produced by git is not valid xml?
From: Andreas Ericsson @ 2005-11-18 23:53 UTC (permalink / raw)
To: git
In-Reply-To: <437E6505.8000201@zytor.com>
H. Peter Anvin wrote:
> Linus Torvalds wrote:
>
>>
>> On Fri, 18 Nov 2005, H. Peter Anvin wrote:
>>
>>> On the fly conversion on CVS import isn't particularly crazy, as long
>>> as it's
>>> under user control.
>>
>>
>> Actually, it is.
>>
>> Why?
>>
>> How are you going to feed your changes back to the original (and
>> initially main) project?
>>
>> Hint: they're not going to pull from your git tree, are they?
>>
>> Ahh. Maybe patches would be a good idea.
>>
>> Ooops.
>>
>
> You're assuming there *IS* an original (and initially main) project.
>
> There is another usage mode: "we're dumping CVS and switching to this
> new-fangled git thing." I have myself done this with several projects
> by now.
>
I'm guessing Linus' scenario is more common. I do it myself and I'd like
it to keep working.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH 5/5] git-daemon support for user-relative paths.
From: Andreas Ericsson @ 2005-11-18 23:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7voe4hfssj.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>
> I think it might make sense to inserting something like the
> attached untested patch in your series, between library and
> upload-pack.
I'll run the clone/fetch/push test-suite again tomorrow, with this
applied. It looks good though.
> The validation done by path_ok() in git-daemon
> probabaly needs to lose alternate checks and validate only the
> path returned by enter_repo(). This would make writing
> whitelist by git-daemon administrator a bit more cumbersome,
Not necessarily. The repositories in the whitelist should be validated
(and possibly converted) using the path_ok() function. This will also
make it possible to catch typos and permission errors that are just
plain annoying for the admins.
In non-strict mode this isn't really a problem so long as all
whitelist-paths are absolute and doesn't contain any symlinks, although
we could use the chdir() + getcwd() thingie since we don't need the
ability to go back to where we started and that's what will be used
later when serving the repos.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* [PATCH] Do not show .exe in git command list.
From: Junio C Hamano @ 2005-11-18 23:44 UTC (permalink / raw)
To: git
In-Reply-To: <437E5A79.9070402@gmail.com>
Truncate the result from readdir() in the exec-path if they end
with .exe, to make it a bit more readable on Cygwin.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Today I borrowed a Cygwin environment to build things without
any customization (no config.mak nor make command line
override), and I have to report that make test passed OK for
me.
git.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
applies-to: ff891e258456492507934e82d90fd8aacb124845
f9039f30d56e3815eaab870d8b19c7b94aded8aa
diff --git a/git.c b/git.c
index b9b8c62..bdd3f8d 100644
--- a/git.c
+++ b/git.c
@@ -59,7 +59,8 @@ static void add_cmdname(const char *name
if (!ent)
oom();
ent->len = len;
- memcpy(ent->name, name, len+1);
+ memcpy(ent->name, name, len);
+ ent->name[len] = 0;
cmdname[cmdname_cnt++] = ent;
}
@@ -132,6 +133,8 @@ static void list_commands(const char *ex
continue;
entlen = strlen(de->d_name);
+ if (4 < entlen && !strcmp(de->d_name + entlen - 4, ".exe"))
+ entlen -= 4;
if (longest < entlen)
longest = entlen;
---
0.99.9.GIT
^ permalink raw reply related
* Re: [PATCH rev-list.c] max-count in terms of intersection
From: Junio C Hamano @ 2005-11-18 23:42 UTC (permalink / raw)
To: ltuikov; +Cc: git
In-Reply-To: <20051118224233.50766.qmail@web31805.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> writes:
>> This makes sense, but I wonder if the same logic applies to
>> max_age as well. If we have clock-skewed commits that are
>> skipped by the DENSE processing, we probably do not want them to
>> be affecting what to do on the commits that matter.
>
> As far as I understand it, I think max-age is fine the way
> it is. After all, max-age depends on date/time which is
> absolute (i.e. applies to commits in the whole set and in
> the intersection just the same).
It is recorded absolutely but what if committer's clock is
broken on one commit but not others, and if you are not using
the default sort_by_date() (e.g. --topo-order)?
^ permalink raw reply
* Re: Rss produced by git is not valid xml?
From: H. Peter Anvin @ 2005-11-18 23:34 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Kay Sievers, Ismail Donmez, git
In-Reply-To: <Pine.LNX.4.64.0511181519100.13959@g5.osdl.org>
Linus Torvalds wrote:
>
> On Fri, 18 Nov 2005, H. Peter Anvin wrote:
>
>>On the fly conversion on CVS import isn't particularly crazy, as long as it's
>>under user control.
>
> Actually, it is.
>
> Why?
>
> How are you going to feed your changes back to the original (and initially
> main) project?
>
> Hint: they're not going to pull from your git tree, are they?
>
> Ahh. Maybe patches would be a good idea.
>
> Ooops.
>
You're assuming there *IS* an original (and initially main) project.
There is another usage mode: "we're dumping CVS and switching to this
new-fangled git thing." I have myself done this with several projects
by now.
-hpa
^ permalink raw reply
* Re: Rss produced by git is not valid xml?
From: Linus Torvalds @ 2005-11-18 23:25 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Kay Sievers, Ismail Donmez, git
In-Reply-To: <437E51EB.7050100@zytor.com>
On Fri, 18 Nov 2005, H. Peter Anvin wrote:
>
> Similarly, it may not be a bad idea to add an *option* -- now when we have a
> config file mechanism -- to signal error on invalid UTF-8 import. This would
> keep a correct UTF-8 repository from getting inadvertently messed up.
This I agree with, btw. We could easily have a
[core]
utf=1
thing, and make git-commit-tree refuse to commit a non-UTF8 message.
Of course, you could equally easily (more so?) make it just a commit
trigger instead, which might well be the right thing.
(And that still leaves the question open what to do about patches and
pulls, but if people mainly worry about newly written commit messages
itself, then at least that part is unambiguous).
Linus
^ permalink raw reply
* Re: [PATCH 1/5] Library code for user-relative paths, take three.
From: Andreas Ericsson @ 2005-11-18 23:23 UTC (permalink / raw)
Cc: H. Peter Anvin, Junio C Hamano, git
In-Reply-To: <437E5A90.3070405@op5.se>
Andreas Ericsson wrote:
> H. Peter Anvin wrote:
>
>> The whole point with --strict is that it shouldn't DWIM. DWIMming is
>> *NOT* safe if the data has previously passed through a security screen.
>>
>
> But it hasn't at this point. The security scan is done afterwards, when
> the canonical path is compared against the whitelist which, in strict
> mode, only matches if it matches exactly.
>
> But anyways, how about doing
>
> enter_repo(path, 2)
>
> from the daemon to make enter_repo() do the chdir(".git")?
>
... while preventing the later call from git-upload-pack from doing so.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Rss produced by git is not valid xml?
From: Linus Torvalds @ 2005-11-18 23:20 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Kay Sievers, Ismail Donmez, git
In-Reply-To: <437E51EB.7050100@zytor.com>
On Fri, 18 Nov 2005, H. Peter Anvin wrote:
>
> On the fly conversion on CVS import isn't particularly crazy, as long as it's
> under user control.
Actually, it is.
Why?
How are you going to feed your changes back to the original (and initially
main) project?
Hint: they're not going to pull from your git tree, are they?
Ahh. Maybe patches would be a good idea.
Ooops.
Linus
^ permalink raw reply
* Re: [PATCH 5/5] git-daemon support for user-relative paths.
From: Junio C Hamano @ 2005-11-18 23:19 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <437DAA66.6070301@op5.se>
Andreas Ericsson <ae@op5.se> writes:
>> I think this list was added relatively recently as a usability
>> measure. Maybe we would want an equivalent in enter_repo()?
>
> It's already there but in a different format.
I noticed that after I asked that question. Thanks.
>> Under strict-path, I think not doing any DWIM like this is fine,
>> but otherwise I suspect changing this would break existing
>> remotes/origin file people may have. In addition enter_repo()
>> as posted does its own DWIM to chdir to ".git" unconditionally
>> as I pointed out...
>
> DWIM? That's an acronym I don't know.
I think you got HPA's message about it and its security
implications.
>> Needs a bit more thought, but I think otherwise the basic idea
>> is right.
>
> Anything I should change before "take four" ?
I think it might make sense to inserting something like the
attached untested patch in your series, between library and
upload-pack. The validation done by path_ok() in git-daemon
probabaly needs to lose alternate checks and validate only the
path returned by enter_repo(). This would make writing
whitelist by git-daemon administrator a bit more cumbersome, but
I suspect at the same time would make auditing easier. So the
series would become:
[1/6] Library code for user-relative paths, take three.
[2/6] Do not DWIM in userpath library under strict mode.
[3/6] Server-side support for user-relative paths.
[4/6] Client side support for user-relative paths.
[5/6] Documentation update for user-relative paths.
[6/6] git-daemon support for user-relative paths.
-- >8 -- cut here -- >8 --
Subject: [PATCH] Do not DWIM in userpath library under strict mode.
This should force git-daemon administrator's job a bit harder
because the exact paths need to be given in the whitelist, but
at the same time makes the auditing easier.
This moves validate_symref() from refs.c to path.c, because we
need to link git-daemon with path.c for its "enter_repo()", but
we do not want to link the daemon with the rest of git libraries
and its requirements.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
path.c | 77 ++++++++++++++++++++++++++++++++++++++++++++++++++--------------
refs.c | 40 ---------------------------------
2 files changed, 60 insertions(+), 57 deletions(-)
applies-to: 7223b28ede4511977d1e71f45fb2867780027235
bd8770050ee2c8d7aa5b2c3f138bc65d83a974e8
diff --git a/path.c b/path.c
index 5b61709..d635470 100644
--- a/path.c
+++ b/path.c
@@ -91,20 +91,55 @@ char *safe_strncpy(char *dest, const cha
return dest;
}
+int validate_symref(const char *path)
+{
+ struct stat st;
+ char *buf, buffer[256];
+ int len, fd;
+
+ if (lstat(path, &st) < 0)
+ return -1;
+
+ /* Make sure it is a "refs/.." symlink */
+ if (S_ISLNK(st.st_mode)) {
+ len = readlink(path, buffer, sizeof(buffer)-1);
+ if (len >= 5 && !memcmp("refs/", buffer, 5))
+ return 0;
+ return -1;
+ }
+
+ /*
+ * Anything else, just open it and try to see if it is a symbolic ref.
+ */
+ fd = open(path, O_RDONLY);
+ if (fd < 0)
+ return -1;
+ len = read(fd, buffer, sizeof(buffer)-1);
+ close(fd);
+
+ /*
+ * Is it a symbolic ref?
+ */
+ if (len < 4 || memcmp("ref:", buffer, 4))
+ return -1;
+ buf = buffer + 4;
+ len -= 4;
+ while (len && isspace(*buf))
+ buf++, len--;
+ if (len >= 5 && !memcmp("refs/", buf, 5))
+ return 0;
+ return -1;
+}
+
static char *current_dir()
{
return getcwd(pathname, sizeof(pathname));
}
-/* Take a raw path from is_git_repo() and canonicalize it using Linus'
- * idea of a blind chdir() and getcwd(). */
-static const char *canonical_path(char *path, int strict)
+static int user_chdir(char *path)
{
char *dir = path;
- if(strict && *dir != '/')
- return NULL;
-
if(*dir == '~') { /* user-relative path */
struct passwd *pw;
char *slash = strchr(dir, '/');
@@ -125,19 +160,19 @@ static const char *canonical_path(char *
/* make sure we got something back that we can chdir() to */
if(!pw || chdir(pw->pw_dir) < 0)
- return NULL;
+ return -1;
if(!slash || !slash[1]) /* no path following username */
- return current_dir();
+ return 0;
dir = slash + 1;
}
/* ~foo/path/to/repo is now path/to/repo and we're in foo's homedir */
if(chdir(dir) < 0)
- return NULL;
+ return -1;
- return current_dir();
+ return 0;
}
char *enter_repo(char *path, int strict)
@@ -145,16 +180,24 @@ char *enter_repo(char *path, int strict)
if(!path)
return NULL;
- if(!canonical_path(path, strict)) {
- if(strict || !canonical_path(mkpath("%s.git", path), strict))
+ if (strict) {
+ if((path[0] != '/') || chdir(path) < 0)
return NULL;
}
+ else {
+ if (!*path)
+ ; /* happy -- no chdir */
+ else if (!user_chdir(path))
+ ; /* happy -- as given */
+ else if (!user_chdir(mkpath("%s.git", path)))
+ ; /* happy -- uemacs --> uemacs.git */
+ else
+ return NULL;
+ (void)chdir(".git");
+ }
- /* This is perfectly safe, and people tend to think of the directory
- * where they ran git-init-db as their repository, so humour them. */
- (void)chdir(".git");
-
- if(access("objects", X_OK) == 0 && access("refs", X_OK) == 0) {
+ if(access("objects", X_OK) == 0 && access("refs", X_OK) == 0 &&
+ validate_symref("HEAD") == 0) {
putenv("GIT_DIR=.");
return current_dir();
}
diff --git a/refs.c b/refs.c
index f324be5..ac26198 100644
--- a/refs.c
+++ b/refs.c
@@ -10,46 +10,6 @@
#define USE_SYMLINK_HEAD 1
#endif
-int validate_symref(const char *path)
-{
- struct stat st;
- char *buf, buffer[256];
- int len, fd;
-
- if (lstat(path, &st) < 0)
- return -1;
-
- /* Make sure it is a "refs/.." symlink */
- if (S_ISLNK(st.st_mode)) {
- len = readlink(path, buffer, sizeof(buffer)-1);
- if (len >= 5 && !memcmp("refs/", buffer, 5))
- return 0;
- return -1;
- }
-
- /*
- * Anything else, just open it and try to see if it is a symbolic ref.
- */
- fd = open(path, O_RDONLY);
- if (fd < 0)
- return -1;
- len = read(fd, buffer, sizeof(buffer)-1);
- close(fd);
-
- /*
- * Is it a symbolic ref?
- */
- if (len < 4 || memcmp("ref:", buffer, 4))
- return -1;
- buf = buffer + 4;
- len -= 4;
- while (len && isspace(*buf))
- buf++, len--;
- if (len >= 5 && !memcmp("refs/", buf, 5))
- return 0;
- return -1;
-}
-
const char *resolve_ref(const char *path, unsigned char *sha1, int reading)
{
int depth = MAXDEPTH, len;
---
0.99.9.GIT
^ permalink raw reply related
* Re: [PATCH 1/5] Library code for user-relative paths, take three.
From: Andreas Ericsson @ 2005-11-18 22:49 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Junio C Hamano, git
In-Reply-To: <437E3A9B.1070801@zytor.com>
H. Peter Anvin wrote:
> The whole point with --strict is that it shouldn't DWIM. DWIMming is
> *NOT* safe if the data has previously passed through a security screen.
>
But it hasn't at this point. The security scan is done afterwards, when
the canonical path is compared against the whitelist which, in strict
mode, only matches if it matches exactly.
But anyways, how about doing
enter_repo(path, 2)
from the daemon to make enter_repo() do the chdir(".git")?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: "make test" fails with current HEAD
From: John Benes @ 2005-11-18 22:49 UTC (permalink / raw)
To: Junio C Hamano, git
In-Reply-To: <7v7jb6o1kl.fsf@assigned-by-dhcp.cox.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Junio C Hamano wrote:
> I *think* this is the same problem as I fixed tonight with help
> from LASCM and John Benes, and I'm hoping to push the fix out
> before going to bed tonight. If you are impatient the patch has
> already been sent out.
I can verify that "make test" now passes on Cygwin without NO_MMAP
uncommented.
Commit: 2e67a5f449f4026097494569f871d79bf263ab28
Desc: Cygwin *might* be helped with NO_MMAP
- --
John Benes
GPG Fingerprint: D519 25DB BB5C 38FC 9D02 02E7 596D BC50 F880 27FA
"It is not only the living who are killed in war." - Isaac Asimov
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQIVAwUBQ35aeWF0oWcU9kCNAQIpgg/9GFi++HvW5J2GYZbcHhAld2cqd6KtgbPN
oUsbPuvGKSM9uP/9pKhOxp+DKJMuFd9mK5FG63jS8i8bthbEzegErLWcfbfM1+Js
0kYIfQEZpJu0+S1uMfsHX1CfS/OtjHebQCD7M9jgMFa1kgJXZl0Zu1rvG5hxTIZV
OwssVwxz9Z2/gWzKFlAwyL4UgI4/mr2f7t43AVSKI0gR0Dry8Ou6B7vjBid9clMd
JNoVHF437FVzAypoSUjmgHJJt+GHYn5noQTOMD0KnokznQckFVxNdALXaoAgkT1Q
adgY+8TObmTbctJ9q2Qi1Z9Y0CAncC0TEGt8D8FBxiH+eJKqEKdmL7JT3ckaQO6S
WZJf/u9SnkUJ089rYbYCvV10hqXz0y5XcGxo8kRKS6XGnY+Ff0hqtxVtHqbog8+y
RtPyeST3vymkPuxx3g/gHrGtXJSZStE2/uNTKyA6IHA9dRUkLn70vHRKZsKKyj/f
n5Ka1CJhIw+DzN4tANsQz9U/Q1olbQIr1khykds5DOhTvdSydSQtT3yOx9Wtt8QZ
OH16pbWSGRNuL/vtwmonnVDsX/JJkUKSn3Z5gwmIvThvrD5TbJjyyYBaYZ9xvtkK
XShm05Xf0yaryVlyUNCjlfNoLhi+gBoTVeaZmx/c1yrDZL6I53g3S79Bktdfd/rE
r0eQqS7GEWc=
=+a+2
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH rev-list.c] max-count in terms of intersection
From: Luben Tuikov @ 2005-11-18 22:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1x1dha6x.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> Luben Tuikov <ltuikov@yahoo.com> writes:
>
> > diff-tree 768b79de9eadc38a839332df0fcce021f7174d6d (from
> 2e67a5f449f4026097494569f871d79bf263ab28)
> > tree 6403fc730f8d5843043788f4c2f466727ba94bc0
> > parent 2e67a5f449f4026097494569f871d79bf263ab28
> > author Luben Tuikov <ltuikov@yahoo.com> 1132349344 -0500
> > committer Luben Tuikov <ltuikov@yahoo.com> 1132349344 -0500
> >
> > [PATCH rev-list.c] max-count in terms of intersection
> >
>
> Documentation/SubmittingPatches, perhaps?
Sorry, I just saw this document existed for GIT too.
Would you like me to resubmit?
> > When a path designation is given, max-count counts the number
> > of commits therein (intersection), not globally.
>
> This makes sense, but I wonder if the same logic applies to
> max_age as well. If we have clock-skewed commits that are
> skipped by the DENSE processing, we probably do not want them to
> be affecting what to do on the commits that matter.
As far as I understand it, I think max-age is fine the way
it is. After all, max-age depends on date/time which is
absolute (i.e. applies to commits in the whole set and in
the intersection just the same).
Luben
^ 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