* Re: git-daemon: path validation, export all option
From: Junio C Hamano @ 2005-09-27 4:19 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: git
In-Reply-To: <4338AACC.1050305@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
> A first attempt to make git-daemon a bit more suitable for kernel.org
> use: it allows the user to specify a whitelist of directories, rejects
> paths which have . or .. in them (to avoid bypassing the whitelist), and
> allows for an --export-all option.
>
> Signed-off-by: H. Peter Anvin <hpa@zytor.com>
I understand the motivation behind --export-all and directory
whitelist and these changes look good. Thanks.
> + if ( ok_paths && *ok_paths ) {
> + int ok = 0;
> +...
> + }
> +
> + return 1; /* Path acceptable */
> +}
A microNit. You could lose 'int ok' and return 1 directly where
you assign 1 to it and break.
> - chdir(".git");
I am unsure about this removal of "minor convenience feature".
Although I do not think git-daemon is widely used on the field,
this change breaks existing setup if there is any.
^ permalink raw reply
* [PATCH] Parallelize building rpm
From: H. Peter Anvin @ 2005-09-27 2:48 UTC (permalink / raw)
To: Git Mailing List
[-- Attachment #1: Type: text/plain, Size: 208 bytes --]
Allow parallelization of rpm build by adding %{_smp_mflags} to the
specfile. The absence of this macro in a specfile means a make should
not be parallelized.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
[-- Attachment #2: git-makej-patch --]
[-- Type: text/plain, Size: 1284 bytes --]
---
commit b8d5dfede58c6e787b06edf9a179b54876ef04db
tree fb5f6eabbc1cf9c57f0d6c2f52db334faa704269
parent 4ae95682694a1cd05ee2029fe241ad90d43c8c0e
author H. Peter Anvin <hpa@hera.kernel.org> Mon, 26 Sep 2005 19:43:24 -0700
committer H. Peter Anvin <hpa@hera.kernel.org> Mon, 26 Sep 2005 19:43:24 -0700
git-core.spec.in | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/git-core.spec.in b/git-core.spec.in
--- a/git-core.spec.in
+++ b/git-core.spec.in
@@ -23,12 +23,12 @@ elsewhere for tools for ordinary humans
%setup -q
%build
-make COPTS="$RPM_OPT_FLAGS" WITH_OWN_SUBPROCESS_PY=YesPlease \
+make %{_smp_mflags} COPTS="$RPM_OPT_FLAGS" WITH_OWN_SUBPROCESS_PY=YesPlease \
prefix=%{_prefix} all %{!?_without_docs: doc}
%install
rm -rf $RPM_BUILD_ROOT
-make DESTDIR=$RPM_BUILD_ROOT WITH_OWN_SUBPROCESS_PY=YesPlease \
+make %{_smp_mflags} DESTDIR=$RPM_BUILD_ROOT WITH_OWN_SUBPROCESS_PY=YesPlease \
prefix=%{_prefix} mandir=%{_mandir} \
install %{!?_without_docs: install-doc}
@@ -45,6 +45,9 @@ rm -rf $RPM_BUILD_ROOT
%{!?_without_docs: %{_mandir}/man7/*.7*}
%changelog
+* Mon Sep 26 2005 H. Peter Anvin <hpa@zytor.com>
+- add %{_smp_mflags}
+
* Fri Sep 16 2005 Chris Wright <chrisw@osdl.org> 0.99.6-1
- update to 0.99.6
^ permalink raw reply
* git-daemon: path validation, export all option
From: H. Peter Anvin @ 2005-09-27 2:13 UTC (permalink / raw)
To: Git Mailing List
[-- Attachment #1: Type: text/plain, Size: 299 bytes --]
A first attempt to make git-daemon a bit more suitable for kernel.org
use: it allows the user to specify a whitelist of directories, rejects
paths which have . or .. in them (to avoid bypassing the whitelist), and
allows for an --export-all option.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 3378 bytes --]
Support a modicum of path validation, and allow an export all trees option.
---
commit 4ae95682694a1cd05ee2029fe241ad90d43c8c0e
tree 4188c26501c852ba9c1b1a3f39276d3ac7dc3f8a
parent 152da3dfcf2c16d7c240a0dbdcb8a3ae1d332d81
author H. Peter Anvin <hpa@smyrno.hos.anvin.org> Mon, 26 Sep 2005 19:10:55 -0700
committer H. Peter Anvin <hpa@smyrno.hos.anvin.org> Mon, 26 Sep 2005 19:10:55 -0700
daemon.c | 72 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++----
1 files changed, 67 insertions(+), 5 deletions(-)
diff --git a/daemon.c b/daemon.c
--- a/daemon.c
+++ b/daemon.c
@@ -12,7 +12,13 @@
static int log_syslog;
static int verbose;
-static const char daemon_usage[] = "git-daemon [--verbose] [--syslog] [--inetd | --port=n]";
+static const char daemon_usage[] = "git-daemon [--verbose] [--syslog] [--inetd | --port=n] [--export-all] [directory...]";
+
+/* List of acceptable pathname prefixes */
+static char **ok_paths = NULL;
+
+/* If this is set, git-daemon-export-ok is not required */
+static int export_all_trees = 0;
static void logreport(int priority, const char *err, va_list params)
@@ -69,15 +75,61 @@ void loginfo(const char *err, ...)
va_end(params);
}
+static int path_ok(const char *dir)
+{
+ const char *p = dir;
+ char **pp;
+ int sl = 1, ndot = 0;
+
+ for (;;) {
+ if ( *p == '.' ) {
+ ndot++;
+ } else if ( *p == '/' || *p == '\0' ) {
+ if ( sl && ndot > 0 && ndot < 3 )
+ return 0; /* . or .. in path */
+ sl = 1;
+ if ( *p == '\0' )
+ break; /* End of string and all is good */
+ } else {
+ sl = ndot = 0;
+ }
+ p++;
+ }
+
+ if ( ok_paths && *ok_paths ) {
+ int ok = 0;
+ int dirlen = strlen(dir); /* read_packet_line can return embedded \0 */
+
+ for ( pp = ok_paths ; *pp ; pp++ ) {
+ int len = strlen(*pp);
+ if ( len <= dirlen &&
+ !strncmp(*pp, dir, len) &&
+ (dir[len] == '/' || dir[len] == '\0') ) {
+ ok = 1;
+ break;
+ }
+ }
+
+ if ( !ok )
+ return 0; /* Path not in whitelist */
+ }
+
+ return 1; /* Path acceptable */
+}
static int upload(char *dir, int dirlen)
{
loginfo("Request for '%s'", dir);
+
+ if (!path_ok(dir)) {
+ logerror("Forbidden directory: %s\n", dir);
+ return -1;
+ }
+
if (chdir(dir) < 0) {
logerror("Cannot chdir('%s'): %s", dir, strerror(errno));
return -1;
}
- chdir(".git");
/*
* Security on the cheap.
@@ -86,10 +138,10 @@ static int upload(char *dir, int dirlen)
* a "git-daemon-export-ok" flag that says that the other side
* is ok with us doing this.
*/
- if (access("git-daemon-export-ok", F_OK) ||
+ if ((!export_all_trees && access("git-daemon-export-ok", F_OK)) ||
access("objects/00", X_OK) ||
access("HEAD", R_OK)) {
- logerror("Not a valid gitd-enabled repository: '%s'", dir);
+ logerror("Not a valid git-daemon-enabled repository: '%s'", dir);
return -1;
}
@@ -441,7 +493,6 @@ int main(int argc, char **argv)
continue;
}
}
-
if (!strcmp(arg, "--inetd")) {
inetd_mode = 1;
continue;
@@ -455,6 +506,17 @@ int main(int argc, char **argv)
openlog("git-daemon", 0, LOG_DAEMON);
continue;
}
+ if (!strcmp(arg, "--export-all")) {
+ export_all_trees = 1;
+ continue;
+ }
+ if (!strcmp(arg, "--")) {
+ ok_paths = &argv[i+1];
+ break;
+ } else if (arg[0] != '-') {
+ ok_paths = &argv[i];
+ break;
+ }
usage(daemon_usage);
}
^ permalink raw reply
* [PATCH] Implement --recover for git-*-fetch
From: Daniel Barkalow @ 2005-09-27 1:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
With the --recover option, we verify that we have absolutely
everything reachable from the target, not assuming that things
reachable from refs will be complete.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
---
fetch.c | 5 ++++-
fetch.h | 3 +++
http-fetch.c | 2 ++
local-fetch.c | 2 ++
ssh-fetch.c | 2 ++
5 files changed, 13 insertions(+), 1 deletions(-)
96e5339ec5759c716282465cb86e3e559270c51c
diff --git a/fetch.c b/fetch.c
--- a/fetch.c
+++ b/fetch.c
@@ -15,6 +15,7 @@ int get_tree = 0;
int get_history = 0;
int get_all = 0;
int get_verbosely = 0;
+int get_recover = 0;
static unsigned char current_commit_sha1[20];
void pull_say(const char *fmt, const char *hex)
@@ -214,7 +215,9 @@ int pull(char *target)
return -1;
}
- for_each_ref(mark_complete);
+ if (!get_recover) {
+ for_each_ref(mark_complete);
+ }
if (interpret_target(target, sha1))
return error("Could not interpret %s as something to pull",
diff --git a/fetch.h b/fetch.h
--- a/fetch.h
+++ b/fetch.h
@@ -40,6 +40,9 @@ extern int get_all;
/* Set to be verbose */
extern int get_verbosely;
+/* Set to check on all reachable objects. */
+extern int get_recover;
+
/* Report what we got under get_verbosely */
extern void pull_say(const char *, const char *);
diff --git a/http-fetch.c b/http-fetch.c
--- a/http-fetch.c
+++ b/http-fetch.c
@@ -491,6 +491,8 @@ int main(int argc, char **argv)
} else if (argv[arg][1] == 'w') {
write_ref = argv[arg + 1];
arg++;
+ } else if (!strcmp(argv[arg], "--recover")) {
+ get_recover = 1;
}
arg++;
}
diff --git a/local-fetch.c b/local-fetch.c
--- a/local-fetch.c
+++ b/local-fetch.c
@@ -231,6 +231,8 @@ int main(int argc, char **argv)
get_verbosely = 1;
else if (argv[arg][1] == 'w')
write_ref = argv[++arg];
+ else if (!strcmp(argv[arg], "--recover"))
+ get_recover = 1;
else
usage(local_pull_usage);
arg++;
diff --git a/ssh-fetch.c b/ssh-fetch.c
--- a/ssh-fetch.c
+++ b/ssh-fetch.c
@@ -119,6 +119,8 @@ int main(int argc, char **argv)
} else if (argv[arg][1] == 'w') {
write_ref = argv[arg + 1];
arg++;
+ } else if (!strcmp(argv[arg], "--recover")) {
+ get_recover = 1;
}
arg++;
}
^ permalink raw reply
* [PATCH]: cogito testsuite fix - expect "m foo", not "M foo"
From: Pavel Roskin @ 2005-09-27 1:06 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
Signed-off-by: Pavel Roskin <proski@gnu.org>
testsuite fix - expect "m foo", not "M foo"
commit bb42b67ac543416f974d502e269f134ed80bdd4b introduced status 'm'
for modified files that won't be committed. This change also broke test
19 in t9202-merge-on-dirty.sh, which expects status 'M'. I believe the
'm' status is correct in this test, so it's the testsuite that need to
be adjusted.
diff --git a/t/t9202-merge-on-dirty.sh b/t/t9202-merge-on-dirty.sh
--- a/t/t9202-merge-on-dirty.sh
+++ b/t/t9202-merge-on-dirty.sh
@@ -89,7 +89,7 @@ cp branch1/foo branch1/foo-
test_expect_failure 'merging branch2 to branch1 (clean)' \
"(cd branch1 && cg-merge </dev/null)"
test_expect_success 'checking if we still have our local change' \
- '(cd branch1 && cg-status -w | grep -q "^M foo" && cmp foo foo-)'
+ '(cd branch1 && cg-status -w | grep -q "^m foo" && cmp foo foo-)'
# This test is useful if the previous one failed - did it get lost or
# accidentally committed?
test_expect_success 'checking that we didn'\''t commit the local change' \
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: More Porcelains?
From: Ameer Armaly @ 2005-09-27 0:57 UTC (permalink / raw)
To: Junio C Hamano, git; +Cc: Nick Hengeveld
In-Reply-To: <7v64sn8hml.fsf_-_@assigned-by-dhcp.cox.net>
----- Original Message -----
From: "Junio C Hamano" <junkio@cox.net>
To: <git@vger.kernel.org>
Cc: "Nick Hengeveld" <nickh@reactrix.com>
Sent: Monday, September 26, 2005 8:43 PM
Subject: More Porcelains?
> Nick Hengeveld <nickh@reactrix.com> writes:
>
>> Good point - use of environment variables is more consistent. Use of
>> command-line arguments is a bit more convenient in my case since I'm
>> driving the transfer from a perl script, but I suppose consistency is
>> more important...
>
> Now you made me curious.
>
> How many of you are working on your own Porcelains, announced or
> unannounced? I know about Cogito and StGIT ;-). In a distant
> past I have heard of something called JIT but I think it is now
> defunct. Matthias Urlichs said he is doing something with
> Python. Anybody else?
>
I am seriously looking at putting one together in the D language
(http://www.digitalmars.com/d) <plug>, though it doesn't actually do
anything as of yet, since I have to balance classes along with it.
>
> -
> 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
^ permalink raw reply
* More Porcelains?
From: Junio C Hamano @ 2005-09-27 0:43 UTC (permalink / raw)
To: git; +Cc: Nick Hengeveld
In-Reply-To: <20050927001542.GC15615@reactrix.com>
Nick Hengeveld <nickh@reactrix.com> writes:
> Good point - use of environment variables is more consistent. Use of
> command-line arguments is a bit more convenient in my case since I'm
> driving the transfer from a perl script, but I suppose consistency is
> more important...
Now you made me curious.
How many of you are working on your own Porcelains, announced or
unannounced? I know about Cogito and StGIT ;-). In a distant
past I have heard of something called JIT but I think it is now
defunct. Matthias Urlichs said he is doing something with
Python. Anybody else?
^ permalink raw reply
* Re: [PATCH 1/3] Support for SSL client cert
From: Nick Hengeveld @ 2005-09-27 0:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
In-Reply-To: <7v3bnrh85g.fsf@assigned-by-dhcp.cox.net>
On Mon, Sep 26, 2005 at 01:43:39PM -0700, Junio C Hamano wrote:
> That is a valid concern.
>
> Anoter possibility is to read them from the environment, since
> we already do SSL_NO_VERIFY from there.
Good point - use of environment variables is more consistent. Use of
command-line arguments is a bit more convenient in my case since I'm
driving the transfer from a perl script, but I suppose consistency is
more important...
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* Re: [PATCH 3/3] Return CURL error message when object transfer fails
From: Nick Hengeveld @ 2005-09-27 0:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4q87ed73.fsf@assigned-by-dhcp.cox.net>
On Mon, Sep 26, 2005 at 02:22:56PM -0700, Junio C Hamano wrote:
> Sounds like a good idea. Also if you happen to know if this
> option is not available in older versions of the library, it
> might not hurt to guard it with "#if LIBCURL_VERSION_NUM" like
> we do with other options.
I don't see any indication that CURLOPT_ERRORBUFFER is a new feature.
The curl_easy_strerror() function is new as of 7.12.0 which is why
I elected to use the CURLOPT_ERRORBUFFER option instead.
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* Re: [PATCH 2/3] Support for partial HTTP transfers
From: Nick Hengeveld @ 2005-09-27 0:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd5mvedcs.fsf@assigned-by-dhcp.cox.net>
On Mon, Sep 26, 2005 at 02:19:31PM -0700, Junio C Hamano wrote:
> If rename() succeeds then tmpfile is no more. If rename() fails
> because there were no tmpfile to begin with, it is not an error
> (i.e. you are not recovering) and that case there would not be
> tmpfile either. Otherwise, if tmpfile still remains to unlink()
> because rename() failed for any other reason, wouldn't you
> rather report it as an error and abort?
I didn't see that as a fatal condition since the transfer would still
take place, albeit a full transfer rather than a partial one. It does
seem worth at least reporting it as a warning though. If a previous
tmpfile exists and both the rename and unlink fail, the subsequent
tmpfile open will also fail - unlikely but probably also worth
detecting and reporting.
> I wonder what happens if by mistake or intentionally we run two
> http-fetch instances simultaneously. IIRC, the current code is
> safe -- the resulting object database will have the object file
> fetched by one of the instance, and the updating of ref is done
> via write_ref_sha1(), so it also is safe. But your change may
> introduce an interesting case where one creates a tmpfile, the
> other one moves it to prevfile and starts using its partial
> contents, and possibly gets confused -- it will probabaly fail
> at the end detecting inconsistent object so it is probably not a
> big loss.
How about using mkstemp on the prev file to keep multiple instances
from stepping on each other? Since O_CREAT | O_EXCL is used to
open the tmpfile, only one instance will be able to succeed and
continue.
> > + /* Reset inflate/SHA1 if there was an error reading the previous temp
> > + file; also rewind to the beginning of the local file. */
>
> Maybe not just rewind but truncate as well? It probably does
> not matter in practice much, but previous representation your
> fetch was interrupted in the middle could have been much larger
> than the representation you are slurping right now.
Good point, I'll update the patch.
> There was a discussion about an object file of the same SHA1 and
> the same contents can have different compressed representations
> (we hash then compress so the resulting filesize depends on the
> compression level without affecting the contents of the object).
> In a "doctor, it hurts when I do this -- don't do it, then" kind
> of corner case, a DNS rotated pair of webservers could be
> serving the same object in different representations and you may
> get interrupted while fetching from one, and restart the
> transfer from the other. The SHA1 check at the end hopefully
> would catch this kind of situation, and that round of http-fetch
> would fail -- the user needs to re-run the fetch so it is not a
> big loss, but it is something to keep in mind.
That's an annoying case, all right... Would it be worth including a
full retry if a partial failed the SHA1 check?
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* Re: Cogito: cg-tag creates a tag object only if -s is specified
From: Petr Baudis @ 2005-09-26 23:54 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Git Mailing List
In-Reply-To: <433885E1.8010800@zytor.com>
Dear diary, on Tue, Sep 27, 2005 at 01:36:01AM CEST, I got a letter
where "H. Peter Anvin" <hpa@zytor.com> told me that...
> cg-tag only creates a tag object if -s (sign) is specified. This not
> only doesn't work properly with a fair number of tools (e.g. gitk), but
> it also means that any description the user has entered via the -d
> option is silently discarded!
>
> Please create a tag object for all tags, even if it is not signed.
Yes, makes sense. In the past it seemed like a nice idea to only create
it when we have to, but it has way too many downsides and if you still
have a plausible reason not to want the tag objects, you're special
enough to fallback to the lowlevel tools.
cg-tag now always creates tag objects.
Thanks for the feedback,
--
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
* Cogito: cg-tag creates a tag object only if -s is specified
From: H. Peter Anvin @ 2005-09-26 23:36 UTC (permalink / raw)
To: Git Mailing List, Petr Baudis
cg-tag only creates a tag object if -s (sign) is specified. This not
only doesn't work properly with a fair number of tools (e.g. gitk), but
it also means that any description the user has entered via the -d
option is silently discarded!
Please create a tag object for all tags, even if it is not signed.
-hpa
^ permalink raw reply
* Re: rsync deprecated but promoted?
From: Junio C Hamano @ 2005-09-26 22:38 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Linus Torvalds, walt, git
In-Reply-To: <Pine.LNX.4.63.0509261808530.23242@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> I should actually implement that now that it's easy; you just skip the
> "for_each_ref(mark_complete);" on line 217 of fetch.c, and it'll make sure
> that it has everything.
>
> (I'll make a patch tonight if nobody beats me to it.)
Thanks.
^ permalink raw reply
* Re: Cogito: cg-clone doesn't like packed tag objects
From: Junio C Hamano @ 2005-09-26 22:37 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <7virwna2oi.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Petr Baudis <pasky@suse.cz> writes:
>
>> Opinions?
>
> I do not understand this part of your logic:
>
>> .... But fetching the tags will cause all the commits
>> connected to the tags getting slurped too, and we didn't want that.
>
> What is the objective here? If you fetch a tag without the
> object being tagged (or commit without its tree), you will end
> up with smaller object database but you would get yelled at by
> git-fsck-objects.
Having said that, I am sympathetic to what you are trying to do
here; if what I understand what you are trying to do matches
what you are actually trying to do, that is.
I think there should be a way to say "I do not care if this
repository does not have all the history back to root -- as long
as I can operate on reasonably recent commits, do not complain
about missing objects" to fsck-objects and various fetch
engines. We can cauterize commit history chain using the grafts
file so that 'git log', 'git whatchanged', and 'gitk' would stop
somewhere. Commit walkers can help you, albeit somewhat
differently, if you do not give -a flag to them.
^ permalink raw reply
* Re: The latest commit to add new keybindings
From: Junio C Hamano @ 2005-09-26 22:30 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Paul Mackerras, git
In-Reply-To: <43387087.60708@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
> It would be good if the dependency then said tk >= 8.4.
Agreed. Will do tonight.
^ permalink raw reply
* Re: Cogito: cg-clone doesn't like packed tag objects
From: Petr Baudis @ 2005-09-26 22:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7virwna2oi.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Tue, Sep 27, 2005 at 12:23:41AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> Petr Baudis <pasky@suse.cz> writes:
> > .... But fetching the tags will cause all the commits
> > connected to the tags getting slurped too, and we didn't want that.
>
> What is the objective here? If you fetch a tag without the
> object being tagged (or commit without its tree), you will end
> up with smaller object database but you would get yelled at by
> git-fsck-objects.
Yes - so you can't save the tag objects either, but then you'll re-slurp
them again and again, which is kind of silly. Alternatively, you could
actually make git-fsck-object silent about the case when an unreachable
(not referenced in refs/) tag object references a non-existing object -
perhaps unless --strict is passed to it. If you think the rest of my
logic is ok, I think this change to facilitate this "tags caching" is
not unreasonable.
The alternative solution would be to have the tags cache with the tag
objects separate of the main object database, but that'd be very dirty.
--
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: [PATCH 0/3] http-fetch enhancements
From: Daniel Barkalow @ 2005-09-26 22:29 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: git
In-Reply-To: <20050926175148.GA9410@reactrix.com>
On Mon, 26 Sep 2005, Nick Hengeveld wrote:
> The following series contains some http-fetch enhancements, based on
> our requirements for use of SSL client certificates and partial HTTP
> transfers.
If you happen to know how to have curl do multiple simultaneous downloads,
that would be a big performance win, and I should be able to explain how
to get this to work. I haven't gotten around to learning libcurl well
enough to do the flow control.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Cogito: cg-clone doesn't like packed tag objects
From: Junio C Hamano @ 2005-09-26 22:23 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050926212536.GF26340@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Opinions?
I do not understand this part of your logic:
> .... But fetching the tags will cause all the commits
> connected to the tags getting slurped too, and we didn't want that.
What is the objective here? If you fetch a tag without the
object being tagged (or commit without its tree), you will end
up with smaller object database but you would get yelled at by
git-fsck-objects.
^ permalink raw reply
* Re: [PATCH 2/3] Support for partial HTTP transfers
From: Daniel Barkalow @ 2005-09-26 22:23 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: git
In-Reply-To: <20050926175204.GC9410@reactrix.com>
On Mon, 26 Sep 2005, Nick Hengeveld wrote:
> Support for partial HTTP transfers - if a previous temp file is detected,
> read it in and start the HTTP transfer from where the previous left off.
You probably want the corresponding code for where it's downloading pack
and index files, which tend to be a lot bigger than individual objects.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: git 0.99.7b doesn't build on Cygwin
From: H. Peter Anvin @ 2005-09-26 22:15 UTC (permalink / raw)
To: Davide Libenzi; +Cc: Giuseppe Bilotta, git
In-Reply-To: <Pine.LNX.4.63.0509261502080.1716@localhost.localdomain>
Davide Libenzi wrote:
>>
>> Except that Cygwin uses them transparently, so if you do open() and
>> read() under Cygwin they work as expected.
>
> With Cygwin you don't even need .lnk files, since it already supports
> all the Unix symlinks APIs/cmds. The discussion born thinking about a
> native Win32 interface, w/out the Cygwin crud in it.
>
Cygwin symbolic links are implemented as .lnk files on the underlying
filesystem was my point.
-hpaa
^ permalink raw reply
* Re: rsync deprecated but promoted?
From: Daniel Barkalow @ 2005-09-26 22:13 UTC (permalink / raw)
To: Linus Torvalds; +Cc: walt, git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.58.0509261038460.3308@g5.osdl.org>
On Mon, 26 Sep 2005, Linus Torvalds wrote:
> A "git-http-fetch --recover HEAD <url>" _should_ fix it, but I don't think
> that works right now. It's documented, but it doesn't do anything. Junio?
I should actually implement that now that it's easy; you just skip the
"for_each_ref(mark_complete);" on line 217 of fetch.c, and it'll make sure
that it has everything.
(I'll make a patch tonight if nobody beats me to it.)
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: The latest commit to add new keybindings
From: H. Peter Anvin @ 2005-09-26 22:04 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Junio C Hamano, git
In-Reply-To: <17207.16457.551775.470665@cargo.ozlabs.ibm.com>
Paul Mackerras wrote:
> Junio C Hamano writes:
>
>
>>Do you actually require 8.4, or any reasonably recent wish would
>>do?
>
>
> Checking in the change from "wish" to "wish8.4" was a mistake - that
> was a change I made for some tests, and I forgot to change it back.
> However, gitk does need tk 8.4 or later, since it uses the panedwindow
> widget, which tk 8.3 doesn't have. I have tk8.5a2 installed here,
> which is nice because it does antialiased fonts, although it is a bit
> slower (clock format is much slower because they changed it from being
> implemented in C to Tcl).
>
It would be good if the dependency then said tk >= 8.4.
-hpa
^ permalink raw reply
* Re: GIT 0.99.7d, and end of week status.
From: Junio C Hamano @ 2005-09-26 22:03 UTC (permalink / raw)
To: Jon Loeliger; +Cc: git
In-Reply-To: <1127765852.5735.36.camel@cashmere.sps.mot.com>
Jon Loeliger <jdl@freescale.com> writes:
There is a small problem in that proposal. "Merging" in git
does not work that way. Specifically,
> # When merging, merge origin, maint and pu into master
> Merge: master origin maint pu
> # Merge into master the just the origin bits
> Merge: master origin
the problem with these is that you may be in your "test" branch
and say "git pull". 'git pull' does not let you say 'pull into
this branch which is not my current branch', and "into master"
part would not work -- merge in git always merges things into
the current branch, so writing
> # When merging, merge origin, maint and pu into the current
> Merge: origin maint pu
> # Merge just the origin bits into the current
> Merge: origin
may make sense.
Having said that I doubt Octopus is what people do regularly, so
being able to write "Merge: origin maint pu" (or "Merge: ncq
chs-support") as a short-hand makes much sense.
There is not much inherent reason to require that the merge
happens only to the current branch, if we stop using the files
in the working tree for resolving conflicts (either manually or
automatically). We could rewrite 'git pull' like this:
- have it take 'merge into this branch' parameter, defaulting
to the current branch, or your "Merge: <into> <remote>..."
proposal.
- if the merge is not to happen in the current branch, then
use a temporary index file and a temporary working directory
to do the merge -- when manual conflict resolution is needed,
ask the user to go to that temporary working directory and
resolve conflicts there and make commits there. The
temporary working directory is actually cheap because we do
not have to checkout all the paths -- only the paths involved
in the merge.
I remember the merge Linus originally envisioned would have
worked along the above lines, until he changed his mind around
2a68a8659f7dc55fd285d235ae2d19e7a8116c30 commit, beginning of
June, for 1.0 (ewww, we were already aiming for 1.0 back then).
http://marc.theaimsgroup.com/?l=git&m=111806925225305&w=2
declared the merge in separate directory is post 1.0 item, and I
tend to agree with that. Most of the time you will be merging
into the current branch, and otherwise you could make it so by
switching to that branch before pulling.
^ permalink raw reply
* Re: git 0.99.7b doesn't build on Cygwin
From: Davide Libenzi @ 2005-09-26 22:03 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Giuseppe Bilotta, git
In-Reply-To: <43386E0A.6010607@zytor.com>
On Mon, 26 Sep 2005, H. Peter Anvin wrote:
> Davide Libenzi wrote:
>> On Sun, 25 Sep 2005, Giuseppe Bilotta wrote:
>>
>>> However, it might be possible to use .lnk files, which would work on
>>> both NTFS and FAT32, and even under Win9x.
>>
>>
>> The .lnk files are a shell thing, not an OS one. Try to open()+read() a
>> .lnk file and look at what you get ...
>>
>
> Except that Cygwin uses them transparently, so if you do open() and read()
> under Cygwin they work as expected.
With Cygwin you don't even need .lnk files, since it already supports all
the Unix symlinks APIs/cmds. The discussion born thinking about a native
Win32 interface, w/out the Cygwin crud in it.
- Davide
^ permalink raw reply
* Re: Cogito: cg-clone doesn't like packed tag objects
From: Petr Baudis @ 2005-09-26 21:56 UTC (permalink / raw)
To: Brian Gerst; +Cc: H. Peter Anvin, Git Mailing List
In-Reply-To: <43386E56.8000208@didntduck.org>
Dear diary, on Mon, Sep 26, 2005 at 11:55:34PM CEST, I got a letter
where Brian Gerst <bgerst@didntduck.org> told me that...
> Petr Baudis wrote:
> >If it's NOT a commit, well, that's a question. On the assumption that
> >it won't be a great deal of data and it's likely to be assumed that we
> >have it, I would be inclined to fetching it, but I don't feel strongly
> >about it.
>
> It could point to a tree (ie. the kernel's v2.6.11 tag), which may end
> up being a large pull. I think it's best to not care what type of
> object the tag references.
Yes, but the object may not be reachable in any other way.
Simple question - if you have a tagged blob containing a GPG public key
(let's call it.. hmm.. e.g. junio-gpg-pub ;), would you expect Cogito to
ignore it or pick it up?
--
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
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