* Re: parsecvs tool now creates git repositories
From: Junio C Hamano @ 2006-04-04 6:09 UTC (permalink / raw)
To: Keith Packard; +Cc: git
In-Reply-To: <1144122709.2303.153.camel@neko.keithp.com>
Keith Packard <keithp@keithp.com> writes:
> I've just changed parsecvs to generate blobs for every revision in
> each ,v file right after they're read in; putting the necessary code
> right into parsecvs should be reasonably straightforward; we don't need
> the multi-patch logic as we do want to compute each intermediate version
> of the file.
If you want to go really fast without extra fork, are writing it
in C, and have the data for blob in core, you could link with
libgit.a and call write_sha1_file() yourself:
unsigned char sha1[20];
void *buf;
unsigned long len;
write_sha1_file(buf, len, "blob", sha1);
instead of forking "hash-object -w". You feed your blob data
in buf, with its length in len, and you will get the blob object
name back in sha1[]. buf is owned by you and after
write_sha1_file() returns it is safe for you to scribble over it
or free() it. sha1[] stores binary object name (20 bytes, not
40-byte hexadecimal), and you can use the helper function
sha1_to_hex() if you need a hex representation:
char *sha1_to_hex(sha1)
which returns a pointer to a static buffer that is valid until
next call to sha1_to_hex(), so you need to strdup it if you want
to retain it.
^ permalink raw reply
* Re: HTTP repo referencing stale heads (can't clone)
From: Junio C Hamano @ 2006-04-04 7:03 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: git
In-Reply-To: <20060403180929.GA14967@reactrix.com>
Nick Hengeveld <nickh@reactrix.com> writes:
> Is there any interest in making the HTTP transport slighly less dumb by
> using DAV?
I personally feel PROPFIND is the right way to do "wget -r", and
very much welcome a patch to replace objects/info/packs with it
when able.
> I have a working patch to http-fetch that tries to use PROPFIND to get a
> remote pack list and falls back to using objects/info/packs. It's
> feasible to do something similar to get a remote ref list when cloning,
> although that's a bit more work as all refs would have to be fetched
> into a local repo and parsed to determine the object type.
Faking info/refs with PROPFIND, if we do not have to peel the
onion ^{}, should be relatively cheap operation, and could be
done as an enhancement to git-ls-remote.sh. If your faked
info/refs file lacks ^{} entries, git-fetch cannot auto-follow
tags, but git-clone should work as before.
A clever sysadmins could mod_rewrite requests to info/refs and
objects/info/packs with a custom CGI, but then probably they
would be running git-daemon ;-).
^ permalink raw reply
* Re: [PATCH] Add git-clean command
From: Martin Waitz @ 2006-04-04 8:20 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <20060403221841.25097.18242.stgit@dv.roinet.com>
[-- Attachment #1: Type: text/plain, Size: 597 bytes --]
hoi :)
> +-x::
> + Don't use the ignore rules. This allows removing all untracked
> + files, including build products. This can be used (possibly in
> + conjunction with gitlink:git-reset[1]) to create a pristine
> + working directory to test a clean build.
as ignored files are generally generated files, doesn't it make sense
to clean up the "ignored" files, and leave other untracked files
alone? That way you don't loose files which you forgot to add to git.
What is the use case of cleaning up all untracked files without also
cleaning ignored files?
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [RFH] Solaris cloning woes...
From: Junio C Hamano @ 2006-04-04 8:47 UTC (permalink / raw)
To: git; +Cc: Peter Eriksen
In-Reply-To: <7vy7yol0nk.fsf@assigned-by-dhcp.cox.net>
The sigaction() patch cooked by Linus and Jason are in "next",
to fix pack-objects breakage started between 1.2.2 and 1.2.3.
Once this is confirmed to fix the problem on Solaris boxes, I'd
like to include and do an 1.2.5, just in case OpenSolaris folks
would want to play with it, and also put them in the "master"
branch.
I have an access to a not-so-well-maintained Solaris box at
work, and built the relevant parts with somewhat stripped down
configuration to run the test. The "master" version without the
sigaction() patches exhibits the symptom Oejet and I observed
the other night, and "next" seems to fix it. I am reasonably
happy.
^ permalink raw reply
* Re: [PATCH] Add git-clean command
From: Junio C Hamano @ 2006-04-04 9:08 UTC (permalink / raw)
To: Martin Waitz; +Cc: git
In-Reply-To: <20060404082002.GJ4663@admingilde.org>
Martin Waitz <tali@admingilde.org> writes:
>> +-x::
>> + Don't use the ignore rules. This allows removing all untracked
>> + files, including build products. This can be used (possibly in
>> + conjunction with gitlink:git-reset[1]) to create a pristine
>> + working directory to test a clean build.
>
> as ignored files are generally generated files, doesn't it make sense
> to clean up the "ignored" files, and leave other untracked files
> alone? That way you don't loose files which you forgot to add to git.
Sounds like a sane suggestion, but my previous comment about
"make clean" broken for people who want this "git clean" feature
applies here as well.
One justification I can think of for "git clean" without -x flag
is to make a clean tree that has only the source and build
products, removing editor backup files, throwaway test output
files and friends, but as you pointed out, this risks losing
newly created source files that you forgot to add, so I would
need a bit of convincing before I use such a command myself.
Compared to that, removing only ignored files sounds like a much
safer operation -- they are explicitly listed as expendable, so
it is a lot less likely to lose anything important. But again,
that is what "make clean" is there for...
^ permalink raw reply
* Re: [PATCH] Add git-clean command
From: Alex Riesen @ 2006-04-04 9:17 UTC (permalink / raw)
To: Martin Waitz; +Cc: Pavel Roskin, git
In-Reply-To: <20060404082002.GJ4663@admingilde.org>
On 4/4/06, Martin Waitz <tali@admingilde.org> wrote:
> What is the use case of cleaning up all untracked files without also
> cleaning ignored files?
Thinks of git's .gitignore: it has config.mak in it. Are you sure you want
"clean" your build customizations?
^ permalink raw reply
* Re: n-heads and patch dependency chains
From: Andreas Ericsson @ 2006-04-04 9:28 UTC (permalink / raw)
To: Sam Vilain; +Cc: Junio C Hamano, git
In-Reply-To: <4431B60E.3030008@vilain.net>
Sam Vilain wrote:
> Junio C Hamano wrote:
>
>>For example, the point jdl raised during the discussion is far
>>easier to understand. When working on multiple topics, he often
>>needs to test them as a whole, so he pulls them into a test
>>branch (can be a throwaway branch). When he needs to do fixups,
>>it is most efficient to do compile/run test while still in the
>>test branch, but after things test out, in order to keep
>>logically different things separate, he needs to go back to
>>relevant topic branches and make a commit. This is painful --
>>are there ways to make this easier [*2*]?
>>
>>Would patch commutation calculus help with his problem?
>>
>>
>
>
> I'd provisionally say "yes, that's the fit". It's just like having
> multiple topic branches all checked out at once, with commits going to
> the appropriate branch as necessary.
>
Wouldn't "git commit -M -b topic", for committing to a different branch
than what is checked out (-b) and also to the checked out branch (-M)
have the same beneficial effects, but without the complexity of hydras
and patch dependency theory? It would only remove the cherry-pick stage
though, but perhaps it's good enough. Although when I think about it, -b
<branch> for committing to another branch and -B <branch> for doing the
above probably makes more sense.
Those flags don't exist currently btw, in case someone's reading this on
the archives.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: n-heads and patch dependency chains
From: Junio C Hamano @ 2006-04-04 9:51 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <44323C52.2030803@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> Sam Vilain wrote:
>> Junio C Hamano wrote:
>>> [ made change on a test branch that bundles topic branches
>>> -- now want to commit back to the component topic branch ]
>>>Would patch commutation calculus help with his problem?
>>>
>> I'd provisionally say "yes, that's the fit". It's just like having
>> multiple topic branches all checked out at once, with commits going to
>> the appropriate branch as necessary.
>
> Wouldn't "git commit -M -b topic", for committing to a different
> branch than what is checked out (-b) and also to the checked out
> branch (-M) have the same beneficial effects, but without the
> complexity of hydras and patch dependency theory? It would only remove
> the cherry-pick stage though, but perhaps it's good enough. Although
> when I think about it, -b
> <branch> for committing to another branch and -B <branch> for doing
> the above probably makes more sense.
It feels to me that the above set of flags encourage a workflow
that:
(1) modify the source and run tests in "test" branch;
(2) have tool automatically adjust the change to match the other
branch (i.e. the topic to be checked in) automatically;
(3) make a commit, without a chance to do the final sanity
check in the context of the branch being committed.
An individual topic branch itself might not be even testable
standalone, but at least I'd prefer to have a chance to double
check if the "patch commuting" (or "cherry-pick stage") did a
sensible thing [*1*].
As I said on the list in the past, I am from a school that
believes in not committing anything that has not been
tested/reviewed as a whole, especially when it comes to
individual developers, so I am not sure it is a good idea
in general to make it easy to do so to begin with.
But that is just my personal preference, and it does not
necessarily have to stop people wishing to have that feature to
have it, especially when there are enough of them.
> Those flags don't exist currently btw, in case someone's reading this
> on the archives.
I take it that you are volunteering to come up with an initial
round of implementation of these flags?
[Footnote]
*1* ... that's where "git checkout -m that-topic", perhaps
followed by "git diff HEAD", comes in.
^ permalink raw reply
* Re: HTTP repo referencing stale heads (can't clone)
From: Petr Baudis @ 2006-04-04 10:00 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: Junio C Hamano, Daniel Drake, git
In-Reply-To: <20060403180929.GA14967@reactrix.com>
Dear diary, on Mon, Apr 03, 2006 at 08:09:30PM CEST, I got a letter
where Nick Hengeveld <nickh@reactrix.com> said that...
> Long term, this could give a repo admin the choice of either making sure
> git-update-server-info has been run after every ref/pack change or
> enabling DAV once. Assuming they need to use HTTP.
Well, what is the actual advantage of DAV compared to
git-update-server-info? Why would I prefer enabling DAV?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ permalink raw reply
* Re: n-heads and patch dependency chains
From: Andreas Ericsson @ 2006-04-04 10:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wwd8y9j.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Andreas Ericsson <ae@op5.se> writes:
>
>
>>Sam Vilain wrote:
>>
>>>Junio C Hamano wrote:
>>>
>>>>[ made change on a test branch that bundles topic branches
>>>> -- now want to commit back to the component topic branch ]
>>>>Would patch commutation calculus help with his problem?
>>>>
>>>
>>>I'd provisionally say "yes, that's the fit". It's just like having
>>>multiple topic branches all checked out at once, with commits going to
>>>the appropriate branch as necessary.
>>
>>Wouldn't "git commit -M -b topic", for committing to a different
>>branch than what is checked out (-b) and also to the checked out
>>branch (-M) have the same beneficial effects, but without the
>>complexity of hydras and patch dependency theory? It would only remove
>>the cherry-pick stage though, but perhaps it's good enough. Although
>>when I think about it, -b
>><branch> for committing to another branch and -B <branch> for doing
>>the above probably makes more sense.
>
>
> It feels to me that the above set of flags encourage a workflow
> that:
>
> (1) modify the source and run tests in "test" branch;
> (2) have tool automatically adjust the change to match the other
> branch (i.e. the topic to be checked in) automatically;
> (3) make a commit, without a chance to do the final sanity
> check in the context of the branch being committed.
>
I don't fully understand 3 here. The workflow makes it easier to test
how different topics work together, and make fixes to those that don't
play well with others. Granted, it's not possible to test each topic by
itself without checking it out, making the changes and re-compiling and
so on, but since commits are so easy to undo I think it'd be nice to
have the changes tracked. Another good thing is that fixes that apply on
top of the "work-together" fixes, but that only make the topic branch
build/work properly are completely rebase'able, and should result in a
fast-forward merge since they share the same commit.
> An individual topic branch itself might not be even testable
> standalone, but at least I'd prefer to have a chance to double
> check if the "patch commuting" (or "cherry-pick stage") did a
> sensible thing [*1*].
>
Understandable, and this workflow would still be available, but see below.
> As I said on the list in the past, I am from a school that
> believes in not committing anything that has not been
> tested/reviewed as a whole, especially when it comes to
> individual developers, so I am not sure it is a good idea
> in general to make it easy to do so to begin with.
>
In short, you're from the school of centralized repositories. I used to
be very careful about committing things too, but since I switched to git
I happily commit smaller and more often, and regularly toss up a
throw-away branch to make small commits that may or may not work and
later apply the (tested) combined diff as a single commit or series of
commits at points where I've tested one feature/fix to actually work as
intended. This is nifty because people that help with testing can pull
from my throw-away branch and get to work without me having to send them
a tar-tree and a patch.
I believe in not *pushing* anything that hasn't been thoroughly tested,
but the ability to track and commit possibly broken changes without it
affecting the project as a whole is what makes git so great for me. In
the CVS days distributed testing was a nuissance. With git it's smooth
sailing.
>
>>Those flags don't exist currently btw, in case someone's reading this
>>on the archives.
>
>
> I take it that you are volunteering to come up with an initial
> round of implementation of these flags?
>
Unless someone can convince me I'm on the wrong track before I get off
work, yes.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] Add git-clean command
From: Sam Ravnborg @ 2006-04-04 10:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pavel Roskin, git
In-Reply-To: <7vzmj2b3w3.fsf@assigned-by-dhcp.cox.net>
On Mon, Apr 03, 2006 at 05:06:36PM -0700, Junio C Hamano wrote:
>
> I am not opposed to the command in the sense that I do not want
> to forbid people from doing what they want to do, but on the
> other hand I do not see why people (apparently many people) want
> to have something like this. Are their "make clean" broken?
No reason to waste time on make clean.
git ls-files -o | xargs rm
Does the same job nicely.
Other typical usecases for me:
Remove temporaries that I created while trying out stuff.
Often I have a bunch of files named 'x', 'xx', 'fisk' etc.
around for no use. An easy way to remove these without breaking
my 'allmodconfig' build is nice. It anyway > 1 hour to build and
I like to get rid of the untracked stuff in an easy way.
So use cases goes like this:
- Remove everything not tracked by git (including .gitignore files)
- Remove everything except tracked by git or ignored
- Remove ignored files (replacement of make clean) (seldom)
Above should work both from top-level dir and in subdirectories.
That is my minimal expectations to git clean.
What Pavel came up with cover everything except the make clean
replacement part.
Sam
^ permalink raw reply
* Re: n-heads and patch dependency chains
From: Jakub Narebski @ 2006-04-04 11:03 UTC (permalink / raw)
To: git
In-Reply-To: <44323C52.2030803@op5.se>
Andreas Ericsson wrote:
> Wouldn't "git commit -M -b topic", for committing to a different branch
> than what is checked out (-b) and also to the checked out branch (-M)
> have the same beneficial effects, but without the complexity of hydras
> and patch dependency theory? It would only remove the cherry-pick stage
> though, but perhaps it's good enough. Although when I think about it, -b
> <branch> for committing to another branch and -B <branch> for doing the
> above probably makes more sense.
Do you mean that you commit current state to the checked out (working)
branch, and commit *changes* (i.e. apply patch) to a different branch?
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: n-heads and patch dependency chains
From: Catalin Marinas @ 2006-04-04 11:05 UTC (permalink / raw)
To: Sam Vilain; +Cc: Git Mailing List
In-Reply-To: <4430D352.4010707@vilain.net>
Sam Vilain <sam@vilain.net> wrote:
> "Patch dependency chains", the best plain-English term we could find for
> the scary sounding darcs term "patch calculus", are said by some to be a
> very good reason to use a system like darcs, even to some its
> fundamental advantage over systems such as git.
As Linus pointed out, while darcs theory is interesting, it doesn't
work properly in practice. Dependency tracking can create problems
with merging. Darcs' patch commuting theory has (a big, IMHO) problem
since every time you pull a patch (or more) it needs to commute all
the patches back to the common ancestor. Over time, the merging
becomes slower and slower (i.e. even much slower than what darcs shows
in simple tests with the Linux kernel).
Inexact patch commuting can be achieved using diff3 (or merge) with 3
snapshots of the tree (the bottom of the patch, the top of the patch
and the current head on top of which the patch is being applied) which
GIT handles very well and fast since there is no need to commute
thousands of patches back to the common ancestor. The slight
disadvantage is that diff3 merging is not as exact as Darcs' patch
commuting but OK for 99% of the real cases.
StGIT is based on this inexact patch commuting "theory" and, with the
addition of upstream merging detection (based on reverse-applying), it
is seems to behave properly in almost all the cases (though you can
deliberately create some patches to break the algorithm).
I've been thinking about adding patch dependency tracking to StGIT but
only as a recommendation and not enforcement. The algorithm would be
similar to the upstream merging detection.
--
Catalin
^ permalink raw reply
* Re: n-heads and patch dependency chains
From: Andreas Ericsson @ 2006-04-04 11:47 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e0tjpk$ktu$1@sea.gmane.org>
Jakub Narebski wrote:
> Andreas Ericsson wrote:
>
>
>>Wouldn't "git commit -M -b topic", for committing to a different branch
>>than what is checked out (-b) and also to the checked out branch (-M)
>>have the same beneficial effects, but without the complexity of hydras
>>and patch dependency theory? It would only remove the cherry-pick stage
>>though, but perhaps it's good enough. Although when I think about it, -b
>><branch> for committing to another branch and -B <branch> for doing the
>>above probably makes more sense.
>
>
> Do you mean that you commit current state to the checked out (working)
> branch, and commit *changes* (i.e. apply patch) to a different branch?
>
No, I mean that this would commit both to the testing branch (being the
result of several merged topic-branches) and to the topic-branch merged
in. Commit as in regular commit, with a commit-message and a patch. The
resulting repository would be the exact same as if the change was
committed only to the topic-branch and then cherry-picked on to the
testing-branch.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: HTTP repo referencing stale heads (can't clone)
From: Nick Hengeveld @ 2006-04-04 12:10 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060404100035.GM27689@pasky.or.cz>
On Tue, Apr 04, 2006 at 12:00:35PM +0200, Petr Baudis wrote:
> Well, what is the actual advantage of DAV compared to
> git-update-server-info? Why would I prefer enabling DAV?
In theory, things should work the same either way. It seems that in
practice though, the server info files continue to surface as a source
of fetch problems.
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* [PATCH] http-fetch: add optional DAV-based pack list
From: Nick Hengeveld @ 2006-04-04 12:33 UTC (permalink / raw)
To: git
If git is not built with NO_EXPAT, this patch changes git-http-fetch to
attempt using DAV to get a list of remote packs and fall back to using
objects/info/packs if the DAV request fails.
Signed-off-by: Nick Hengeveld <nickh@reactrix.com>
---
Makefile | 7 +
http-fetch.c | 278 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 284 insertions(+), 1 deletions(-)
9aef9577cabbd96de20562902d2958108616a7e4
diff --git a/Makefile b/Makefile
index c79d646..19ce42c 100644
--- a/Makefile
+++ b/Makefile
@@ -510,6 +510,11 @@ git$X git.spec \
exec_cmd.o: exec_cmd.c
$(CC) -o $*.o -c $(ALL_CFLAGS) '-DGIT_EXEC_PATH="$(gitexecdir_SQ)"' $<
+ifdef NO_EXPAT
+http-fetch.o: http-fetch.c
+ $(CC) -o $*.o -c $(ALL_CFLAGS) -DNO_EXPAT $<
+endif
+
git-%$X: %.o $(GITLIBS)
$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(LIBS)
@@ -532,7 +537,7 @@ git-imap-send$X: imap-send.o $(LIB_FILE)
git-http-fetch$X: fetch.o http.o http-fetch.o $(LIB_FILE)
$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
- $(LIBS) $(CURL_LIBCURL)
+ $(LIBS) $(CURL_LIBCURL) $(EXPAT_LIBEXPAT)
git-http-push$X: revision.o http.o http-push.o $(LIB_FILE)
$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
diff --git a/http-fetch.c b/http-fetch.c
index dc67218..71a7daf 100644
--- a/http-fetch.c
+++ b/http-fetch.c
@@ -4,6 +4,35 @@ #include "pack.h"
#include "fetch.h"
#include "http.h"
+#ifndef NO_EXPAT
+#include <expat.h>
+
+/* Definitions for DAV requests */
+#define DAV_PROPFIND "PROPFIND"
+#define DAV_PROPFIND_RESP ".multistatus.response"
+#define DAV_PROPFIND_NAME ".multistatus.response.href"
+#define DAV_PROPFIND_COLLECTION ".multistatus.response.propstat.prop.resourcetype.collection"
+#define PROPFIND_ALL_REQUEST "<?xml version=\"1.0\" encoding=\"utf-8\" ?>\n<D:propfind xmlns:D=\"DAV:\">\n<D:allprop/>\n</D:propfind>"
+
+/* Definitions for processing XML DAV responses */
+#ifndef XML_STATUS_OK
+enum XML_Status {
+ XML_STATUS_OK = 1,
+ XML_STATUS_ERROR = 0
+};
+#define XML_STATUS_OK 1
+#define XML_STATUS_ERROR 0
+#endif
+
+/* Flags that control remote_ls processing */
+#define PROCESS_FILES (1u << 0)
+#define PROCESS_DIRS (1u << 1)
+#define RECURSIVE (1u << 2)
+
+/* Flags that remote_ls passes to callback functions */
+#define IS_DIR (1u << 0)
+#endif
+
#define PREV_BUF_SIZE 4096
#define RANGE_HEADER_SIZE 30
@@ -15,6 +44,7 @@ static struct curl_slist *no_pragma_head
struct alt_base
{
char *base;
+ int path_len;
int got_indices;
struct packed_git *packs;
struct alt_base *next;
@@ -56,8 +86,32 @@ struct alternates_request {
struct buffer *buffer;
struct active_request_slot *slot;
int http_specific;
+};
+
+#ifndef NO_EXPAT
+struct xml_ctx
+{
+ char *name;
+ int len;
+ char *cdata;
+ void (*userFunc)(struct xml_ctx *ctx, int tag_closed);
+ void *userData;
};
+struct remote_ls_ctx
+{
+ struct alt_base *repo;
+ char *path;
+ void (*userFunc)(struct remote_ls_ctx *ls);
+ void *userData;
+ int flags;
+ char *dentry_name;
+ int dentry_flags;
+ int rc;
+ struct remote_ls_ctx *parent;
+};
+#endif
+
static struct object_request *object_queue_head = NULL;
static size_t fwrite_sha1_file(void *ptr, size_t eltsize, size_t nmemb,
@@ -500,6 +554,7 @@ static void process_alternates_response(
int serverlen = 0;
struct alt_base *newalt;
char *target = NULL;
+ char *path;
if (data[i] == '/') {
serverlen = strchr(base + 8, '/') - base;
okay = 1;
@@ -540,6 +595,13 @@ static void process_alternates_response(
newalt->base = target;
newalt->got_indices = 0;
newalt->packs = NULL;
+ path = strstr(target, "//");
+ if (path) {
+ path = index(path+2, '/');
+ if (path)
+ newalt->path_len = strlen(path);
+ }
+
while (tail->next != NULL)
tail = tail->next;
tail->next = newalt;
@@ -608,9 +670,212 @@ #endif
got_alternates = -1;
free(data);
+ free(url);
+}
+
+#ifndef NO_EXPAT
+static void
+xml_start_tag(void *userData, const char *name, const char **atts)
+{
+ struct xml_ctx *ctx = (struct xml_ctx *)userData;
+ const char *c = index(name, ':');
+ int new_len;
+
+ if (c == NULL)
+ c = name;
+ else
+ c++;
+
+ new_len = strlen(ctx->name) + strlen(c) + 2;
+
+ if (new_len > ctx->len) {
+ ctx->name = xrealloc(ctx->name, new_len);
+ ctx->len = new_len;
+ }
+ strcat(ctx->name, ".");
+ strcat(ctx->name, c);
+
+ if (ctx->cdata) {
+ free(ctx->cdata);
+ ctx->cdata = NULL;
+ }
+
+ ctx->userFunc(ctx, 0);
+}
+
+static void
+xml_end_tag(void *userData, const char *name)
+{
+ struct xml_ctx *ctx = (struct xml_ctx *)userData;
+ const char *c = index(name, ':');
+ char *ep;
+
+ ctx->userFunc(ctx, 1);
+
+ if (c == NULL)
+ c = name;
+ else
+ c++;
+
+ ep = ctx->name + strlen(ctx->name) - strlen(c) - 1;
+ *ep = 0;
+}
+
+static void
+xml_cdata(void *userData, const XML_Char *s, int len)
+{
+ struct xml_ctx *ctx = (struct xml_ctx *)userData;
+ if (ctx->cdata)
+ free(ctx->cdata);
+ ctx->cdata = xcalloc(len+1, 1);
+ strncpy(ctx->cdata, s, len);
+}
+
+static int remote_ls(struct alt_base *repo, const char *path, int flags,
+ void (*userFunc)(struct remote_ls_ctx *ls),
+ void *userData);
+
+static void handle_remote_ls_ctx(struct xml_ctx *ctx, int tag_closed)
+{
+ struct remote_ls_ctx *ls = (struct remote_ls_ctx *)ctx->userData;
+
+ if (tag_closed) {
+ if (!strcmp(ctx->name, DAV_PROPFIND_RESP) && ls->dentry_name) {
+ if (ls->dentry_flags & IS_DIR) {
+ if (ls->flags & PROCESS_DIRS) {
+ ls->userFunc(ls);
+ }
+ if (strcmp(ls->dentry_name, ls->path) &&
+ ls->flags & RECURSIVE) {
+ ls->rc = remote_ls(ls->repo,
+ ls->dentry_name,
+ ls->flags,
+ ls->userFunc,
+ ls->userData);
+ }
+ } else if (ls->flags & PROCESS_FILES) {
+ ls->userFunc(ls);
+ }
+ } else if (!strcmp(ctx->name, DAV_PROPFIND_NAME) && ctx->cdata) {
+ ls->dentry_name = xmalloc(strlen(ctx->cdata) -
+ ls->repo->path_len + 1);
+ strcpy(ls->dentry_name, ctx->cdata + ls->repo->path_len);
+ } else if (!strcmp(ctx->name, DAV_PROPFIND_COLLECTION)) {
+ ls->dentry_flags |= IS_DIR;
+ }
+ } else if (!strcmp(ctx->name, DAV_PROPFIND_RESP)) {
+ if (ls->dentry_name) {
+ free(ls->dentry_name);
+ }
+ ls->dentry_name = NULL;
+ ls->dentry_flags = 0;
+ }
+}
+
+static int remote_ls(struct alt_base *repo, const char *path, int flags,
+ void (*userFunc)(struct remote_ls_ctx *ls),
+ void *userData)
+{
+ char *url = xmalloc(strlen(repo->base) + strlen(path) + 1);
+ struct active_request_slot *slot;
+ struct slot_results results;
+ struct buffer in_buffer;
+ struct buffer out_buffer;
+ char *in_data;
+ char *out_data;
+ XML_Parser parser = XML_ParserCreate(NULL);
+ enum XML_Status result;
+ struct curl_slist *dav_headers = NULL;
+ struct xml_ctx ctx;
+ struct remote_ls_ctx ls;
+
+ ls.flags = flags;
+ ls.repo = repo;
+ ls.path = strdup(path);
+ ls.dentry_name = NULL;
+ ls.dentry_flags = 0;
+ ls.userData = userData;
+ ls.userFunc = userFunc;
+ ls.rc = 0;
+
+ sprintf(url, "%s%s", repo->base, path);
+
+ out_buffer.size = strlen(PROPFIND_ALL_REQUEST);
+ out_data = xmalloc(out_buffer.size + 1);
+ snprintf(out_data, out_buffer.size + 1, PROPFIND_ALL_REQUEST);
+ out_buffer.posn = 0;
+ out_buffer.buffer = out_data;
+
+ in_buffer.size = 4096;
+ in_data = xmalloc(in_buffer.size);
+ in_buffer.posn = 0;
+ in_buffer.buffer = in_data;
+
+ dav_headers = curl_slist_append(dav_headers, "Depth: 1");
+ dav_headers = curl_slist_append(dav_headers, "Content-Type: text/xml");
+
+ slot = get_active_slot();
+ slot->results = &results;
+ curl_easy_setopt(slot->curl, CURLOPT_INFILE, &out_buffer);
+ curl_easy_setopt(slot->curl, CURLOPT_INFILESIZE, out_buffer.size);
+ curl_easy_setopt(slot->curl, CURLOPT_READFUNCTION, fread_buffer);
+ curl_easy_setopt(slot->curl, CURLOPT_FILE, &in_buffer);
+ curl_easy_setopt(slot->curl, CURLOPT_WRITEFUNCTION, fwrite_buffer);
+ curl_easy_setopt(slot->curl, CURLOPT_URL, url);
+ curl_easy_setopt(slot->curl, CURLOPT_UPLOAD, 1);
+ curl_easy_setopt(slot->curl, CURLOPT_CUSTOMREQUEST, DAV_PROPFIND);
+ curl_easy_setopt(slot->curl, CURLOPT_HTTPHEADER, dav_headers);
+
+ if (start_active_slot(slot)) {
+ run_active_slot(slot);
+ if (results.curl_result == CURLE_OK) {
+ ctx.name = xcalloc(10, 1);
+ ctx.len = 0;
+ ctx.cdata = NULL;
+ ctx.userFunc = handle_remote_ls_ctx;
+ ctx.userData = &ls;
+ XML_SetUserData(parser, &ctx);
+ XML_SetElementHandler(parser, xml_start_tag,
+ xml_end_tag);
+ XML_SetCharacterDataHandler(parser, xml_cdata);
+ result = XML_Parse(parser, in_buffer.buffer,
+ in_buffer.posn, 1);
+ free(ctx.name);
+
+ if (result != XML_STATUS_OK) {
+ ls.rc = error("XML error: %s",
+ XML_ErrorString(
+ XML_GetErrorCode(parser)));
+ }
+ } else {
+ ls.rc = -1;
+ }
+ } else {
+ ls.rc = error("Unable to start PROPFIND request");
+ }
+
+ free(ls.path);
free(url);
+ free(out_data);
+ free(in_buffer.buffer);
+ curl_slist_free_all(dav_headers);
+
+ return ls.rc;
}
+static void process_ls_pack(struct remote_ls_ctx *ls)
+{
+ unsigned char sha1[20];
+
+ if (strlen(ls->dentry_name) == 63 &&
+ !strncmp(ls->dentry_name, "objects/pack/pack-", 18) &&
+ !strncmp(ls->dentry_name+58, ".pack", 5)) {
+ get_sha1_hex(ls->dentry_name + 18, sha1);
+ setup_index(ls->repo, sha1);
+ }
+}
+#endif
+
static int fetch_indices(struct alt_base *repo)
{
unsigned char sha1[20];
@@ -632,6 +897,12 @@ static int fetch_indices(struct alt_base
if (get_verbosely)
fprintf(stderr, "Getting pack list for %s\n", repo->base);
+
+#ifndef NO_EXPAT
+ if (remote_ls(repo, "objects/pack/", PROCESS_FILES,
+ process_ls_pack, NULL) == 0)
+ return 0;
+#endif
url = xmalloc(strlen(repo->base) + 21);
sprintf(url, "%s/objects/info/packs", repo->base);
@@ -947,6 +1218,7 @@ int main(int argc, char **argv)
{
char *commit_id;
char *url;
+ char *path;
int arg = 1;
int rc = 0;
@@ -987,6 +1259,12 @@ int main(int argc, char **argv)
alt->got_indices = 0;
alt->packs = NULL;
alt->next = NULL;
+ path = strstr(url, "//");
+ if (path) {
+ path = index(path+2, '/');
+ if (path)
+ alt->path_len = strlen(path);
+ }
if (pull(commit_id))
rc = 1;
--
1.3.0.rc1.gd4df-dirty
^ permalink raw reply related
* [PATCH] Solaris needs strings.h when using index().
From: Peter Eriksen @ 2006-04-04 12:36 UTC (permalink / raw)
To: git
From: Peter Eriksen <s022018@student.dtu.dk>
Date: Tue Apr 4 14:33:14 2006 +0200
Subject: [PATCH] Solaris needs strings.h when using index().
Signed-off-by: Peter Eriksen <s022018@student.dtu.dk>
---
blame.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
832067e6e16ae6c1ac3bd043ddeb56daa993e682
diff --git a/blame.c b/blame.c
index 396defc..1a08434 100644
--- a/blame.c
+++ b/blame.c
@@ -6,6 +6,7 @@ #include <assert.h>
#include <time.h>
#include <sys/time.h>
#include <math.h>
+#include <strings.h>
#include "cache.h"
#include "refs.h"
--
1.3.0.rc1.gfc99-dirty
^ permalink raw reply related
* Re: HTTP repo referencing stale heads (can't clone)
From: Petr Baudis @ 2006-04-04 15:27 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: git
In-Reply-To: <20060404121056.GB14967@reactrix.com>
Dear diary, on Tue, Apr 04, 2006 at 02:10:57PM CEST, I got a letter
where Nick Hengeveld <nickh@reactrix.com> said that...
> On Tue, Apr 04, 2006 at 12:00:35PM +0200, Petr Baudis wrote:
>
> > Well, what is the actual advantage of DAV compared to
> > git-update-server-info? Why would I prefer enabling DAV?
>
> In theory, things should work the same either way. It seems that in
> practice though, the server info files continue to surface as a source
> of fetch problems.
Because people do not know they have to set up their post-update hook.
When they are already going at lengths to find out how to set up DAV for
git fetch, they would discover the post-update hook way as well.
So, it really seems rather redundant to me.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ permalink raw reply
* Re: [PATCH] Add git-clean command
From: Pavel Roskin @ 2006-04-04 15:32 UTC (permalink / raw)
To: Alex Riesen; +Cc: Martin Waitz, git
In-Reply-To: <81b0412b0604040217s3b8863d3w1b79400c42ca2b90@mail.gmail.com>
On Tue, 2006-04-04 at 11:17 +0200, Alex Riesen wrote:
> On 4/4/06, Martin Waitz <tali@admingilde.org> wrote:
> > What is the use case of cleaning up all untracked files without also
> > cleaning ignored files?
>
> Thinks of git's .gitignore: it has config.mak in it. Are you sure you want
> "clean" your build customizations?
In may case, I normally want to remove copies of the sources. For
example, I take foo.c, make a clean copy of it, then I change and test
it. If if doesn't work and I want to try another approach, I copy it to
foo.c-bad or foo.c-approach1. I also make diffs between files to see
what exactly I changed. I may also create files for output, valgrind
logs and so on.
At some point, I'm satisfied with foo.c, so I commit it. Then I want to
remove copies, diffs and other stuff. Yet I don't want to rebuild
everything.
It's very rare that I add a new file, and I always remember to add it to
the version control. But I'll consider adding an option to only remove
ignored files.
--
Regards,
Pavel Roskin
^ permalink raw reply
* [PATCH] read-cache.c: Slight parameter name improvement.
From: Peter Eriksen @ 2006-04-04 15:42 UTC (permalink / raw)
To: git
From: Peter Eriksen <s022018@student.dtu.dk>
Date: Tue Apr 4 17:40:02 2006 +0200
Subject: [PATCH] read-cache.c: Slight parameter name improvement.
Signed-off-by: Peter Eriksen <s022018@student.dtu.dk>
---
read-cache.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
dde622db1412a556b216eceff4a9a677b41568c3
diff --git a/read-cache.c b/read-cache.c
index f97f92d..2e8fdc5 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -257,7 +257,7 @@ int cache_name_compare(const char *name1
return 0;
}
-int cache_name_pos(const char *name, int namelen)
+int cache_name_pos(const char *name, int flags)
{
int first, last;
@@ -266,7 +266,7 @@ int cache_name_pos(const char *name, int
while (last > first) {
int next = (last + first) >> 1;
struct cache_entry *ce = active_cache[next];
- int cmp = cache_name_compare(name, namelen, ce->name, ntohs(ce->ce_flags));
+ int cmp = cache_name_compare(name, flags, ce->name, ntohs(ce->ce_flags));
if (!cmp)
return next;
if (cmp < 0) {
--
1.3.0.rc1.gfc99-dirty
^ permalink raw reply related
* Re: [PATCH] Add git-clean command
From: Pavel Roskin @ 2006-04-04 15:52 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Junio C Hamano, git
In-Reply-To: <20060404105818.GA17326@mars.ravnborg.org>
On Tue, 2006-04-04 at 12:58 +0200, Sam Ravnborg wrote:
> On Mon, Apr 03, 2006 at 05:06:36PM -0700, Junio C Hamano wrote:
> >
> > I am not opposed to the command in the sense that I do not want
> > to forbid people from doing what they want to do, but on the
> > other hand I do not see why people (apparently many people) want
> > to have something like this. Are their "make clean" broken?
Normally it is not, but if it is, they want to know it. If git-clean
remove something after "make clean" then maybe the later is incomplete.
To put it another way, if I make changes and share them with others, I
want to make sure that my changes will work for them. If the mechanism
for sharing my changes is make-based, I rely on make to check them. In
projects using Automake it's called "make distcheck". If I'm sharing my
changes as a git patch, I want a git-based verification that the project
still builds from scratch.
Also, the files cleaned by "make clean" are normally build products.
Things that you _really_ don't want to be in the source tree at the
release time are other files, such as backup files with changes that you
decided to back out, sources that you may not share, firmware that cost
your company $50000 and so on. "make clean" won't remove them.
> No reason to waste time on make clean.
> git ls-files -o | xargs rm
> Does the same job nicely.
This would remove ignored files. It's not always what I want.
> Other typical usecases for me:
> Remove temporaries that I created while trying out stuff.
> Often I have a bunch of files named 'x', 'xx', 'fisk' etc.
> around for no use. An easy way to remove these without breaking
> my 'allmodconfig' build is nice. It anyway > 1 hour to build and
> I like to get rid of the untracked stuff in an easy way.
>
> So use cases goes like this:
> - Remove everything not tracked by git (including .gitignore files)
> - Remove everything except tracked by git or ignored
> - Remove ignored files (replacement of make clean) (seldom)
I'll think about the later.
> Above should work both from top-level dir and in subdirectories.
>
> That is my minimal expectations to git clean.
> What Pavel came up with cover everything except the make clean
> replacement part.
Exactly. The "make clean" replacement is actually the one I didn't
implement.
--
Regards,
Pavel Roskin
^ permalink raw reply
* [PATCH] Set HTTP user agent to git/GIT_VERSION
From: Nick Hengeveld @ 2006-04-04 17:11 UTC (permalink / raw)
To: git
Useful for diagnostics/troubleshooting to know which client versions are
hitting your server.
Signed-off-by: Nick Hengeveld <nickh@reactrix.com>
---
Makefile | 3 +++
http.c | 2 ++
2 files changed, 5 insertions(+), 0 deletions(-)
468d4d4ac3cbdb0757a7cc1c207ca379ce3a5d56
diff --git a/Makefile b/Makefile
index 19ce42c..c7d5ecf 100644
--- a/Makefile
+++ b/Makefile
@@ -510,6 +510,9 @@ git$X git.spec \
exec_cmd.o: exec_cmd.c
$(CC) -o $*.o -c $(ALL_CFLAGS) '-DGIT_EXEC_PATH="$(gitexecdir_SQ)"' $<
+http.o: http.c
+ $(CC) -o $*.o -c $(ALL_CFLAGS) -DGIT_USER_AGENT='"git/$(GIT_VERSION)"' $<
+
ifdef NO_EXPAT
http-fetch.o: http-fetch.c
$(CC) -o $*.o -c $(ALL_CFLAGS) -DNO_EXPAT $<
diff --git a/http.c b/http.c
index 9604e33..0cb42a8 100644
--- a/http.c
+++ b/http.c
@@ -195,6 +195,8 @@ #endif
if (getenv("GIT_CURL_VERBOSE"))
curl_easy_setopt(result, CURLOPT_VERBOSE, 1);
+ curl_easy_setopt(result, CURLOPT_USERAGENT, GIT_USER_AGENT);
+
return result;
}
--
1.3.0.rc1.g9aef-dirty
^ permalink raw reply related
* [BUG] git-http-fetch segfault
From: Radoslaw Szkodzinski @ 2006-04-04 17:11 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano
[-- Attachment #1: Type: text/plain, Size: 3379 bytes --]
I have some problems cloning stgit repository (maybe something's broken there).
The repository seems to be using symlink HEAD.
Possibly the problem is because of a non-existent tag commit.
Yes, it has that broken HTTP error message bug.
Git version:
astralstorm@zen /home/devel/git $ git log -n 1 | head -n 1
commit fc9957b0052df6a8248420395bc9febd66194252
Session log (slightly linewrapped):
astralstorm@zen /home/devel $ git clone
http://homepage.ntlworld.com/cmarinas/stgit.git stgit
got 52f3900c0c7dec8581fa907495a09c900a3d39d7
walk 52f3900c0c7dec8581fa907495a09c900a3d39d7
got c82395b46d238948882045e76e7770319a4f40e8
got aa78d4ed34d262b6f811e7e47415c8c4ac6d80a2
walk c82395b46d238948882045e76e7770319a4f40e8
got 098c1d3e9fe5c39b859ccff6c7d36d2c193d1b62
got 4ebca0e1cabe90ecdcd29aab6fa16521d4999fb5
got 8d2bebd9d1824f1b7af5cfe6fbd11f9cbfde6d74
got 184ded8e08cb92a14b79c79f9919469ba352ab70
got d60c31a97a544b53039088d14fe9114583c0efc3
got e5affe07bf8b39e2aa0309299dbc9532e05940b5
got c2514fd418472dc173a5fef09c82ccf666c9555f
got 3c900ce9dae0959a9e4479b55b8a71d1b92d170d
got 7888f29f97452f8db39f4a9e857b7f1d2c913765
got 4359033a665b7943f2a7579e8329a715fd2fdc57
got def843c5d5fd4dee9a54504512b4308cb3a84018
got 0c3ad3951bb8cf368c70b13240665495e19a98a9
got 32977d8fae38a542b15dd9c5e39d64076a35227b
got 8847a11b3bbf5406f37a360e5466f0e392c56383
got 07704b8331d6d78a132c731874f66749dfa0f85c
got 5b8d95f20b8989fde6b0731c55b3f985ed01630a
got 6a8557477abde3f1368304e6fb8d890e2982267e
got de7bd13bae9eec619ae4baf46e65475602d52979
got 5899c38225df2244c7b09015f5b754d9735415d5
got ebd09f908d165c7aa3a135ddc8bbd5a05787df93
walk 8847a11b3bbf5406f37a360e5466f0e392c56383
got 6480a2a7f279002c3daf5a56ece16636cd5df26f
got 568bc169d53ee40ef5dc7481e7cab8078141fa9e
Getting alternates list for http://homepage.ntlworld.com/cmarinas/stgit.git/
got 4b03e3a6440883cf8ef6092426b3d932b8b0c73a
got ee90cfb41de9e3a589fc688ba1350e9c8b846c20
got c394572a81d9b3322a7a7cdccec0c1846d445dcc
got 66e9f41044631264c2740f61ddafbc4bd01ec71a
got c603ff88fcd21f1e4b806413d195c90f29ea547f
got a0569457816c345e8c7fa92135fd664dd67ea97c
got 5749b3bd8476df9e2808a3723e23d7acd4e4c71d
got f4d749004ac695720ab883c338fdc3df5da394bb
got e7f3481a23600c969a3cdf9bf793e8239546c1d1
got 1317788c088c3f621f83ceae657e0d1f6f34af54
got 7881993b68ead8678545516fa8e04f8919569b8e
got 44cd19e162f9ff976df475bccecd63a42e04a244
Getting pack list for http://homepage.ntlworld.com/cmarinas/stgit.git/
got 694ea0c23cc88422d923104b04832df48865dae6
got 938ce9bb5812cac4d0902ae6f87a276d51a58cd9
got 9534f1c94a19e5521bbb7a5664d587400eb55905
got fc9c5a73a29673f06b683a85134531ad6d9520ea
got f80bef4918840e4290f03f291d8b4dbb98b12d80
error: Unable to find adad46f365219e9bcc1a212826ca65eaac09729c under
http://homepage.ntlworld.com/cmarinas/stgit.git/
Cannot obtain needed blob adad46f365219e9bcc1a212826ca65eaac09729c
while processing commit 8847a11b3bbf5406f37a360e5466f0e392c56383.
Waiting for
http://homepage.ntlworld.com/cmarinas/stgit.git/objects/d5/68cd60c5759cfd84d4148f3c3d5bf9f5b85d41
/usr/bin/git-clone: line 29: 13000 Naruszenie ochrony pamięci git-http-fetch
-v -a -w "$tname" "$name" "$1/"
(Naruszenie ochrony pamięci = Segmentation fault)
--
GPG Key id: 0xD1F10BA2
Fingerprint: 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2
AstralStorm
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]
^ permalink raw reply
* Re: HTTP repo referencing stale heads (can't clone)
From: Nick Hengeveld @ 2006-04-04 17:56 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060404152737.GN27689@pasky.or.cz>
On Tue, Apr 04, 2006 at 05:27:37PM +0200, Petr Baudis wrote:
> Because people do not know they have to set up their post-update hook.
> When they are already going at lengths to find out how to set up DAV for
> git fetch, they would discover the post-update hook way as well.
There are other reasons that a client can end up with a stale copy of
the server info files - in this case the problem was an intermediate
proxy out of the control of the repo admin.
While we should be able to fix that particular problem, it seems safer
to go straight to the source if possible.
> So, it really seems rather redundant to me.
If I've already enabled DAV for pushing to a repo, I'd find it nice to
be able to use it for fetches as well.
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* Re: HTTP repo referencing stale heads (can't clone)
From: Nick Hengeveld @ 2006-04-04 18:01 UTC (permalink / raw)
To: Daniel Drake; +Cc: Junio C Hamano, git
In-Reply-To: <4431694C.4000007@gentoo.org>
On Mon, Apr 03, 2006 at 07:28:28PM +0100, Daniel Drake wrote:
> Ah, should have known. I am behind a (lame) transparent proxy on port 80.
>
> I opened that file in my web browser and it showed the old heads. After
> a force-refresh (ctrl+F5, which sends some additionally http headers to
> refresh the page from the real server), the old heads disappeared, and
> git now clones successfully.
>
> git-http-fetch should probably send those extra headers too. I'll try to
> find some time to look at this next week.
git-http-fetch uses the "Pragma: no-cache" header when requesting
objects that shouldn't be cached. Is this the additional header you're
referring to?
This patch adds the header to git-ls-remote for the info/refs request.
git-ls-remote: send no-cache header when fetching info/refs
Proxies should not cache this file as it can cause a client to end up with
a stale version, as reported here:
http://marc.theaimsgroup.com/?l=git&m=114407944125389
Signed-off-by: Nick Hengeveld <nickh@reactrix.com>
---
git-ls-remote.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
da9b6fa01f1a8bd6ab5f6d4346584f3f032584aa
diff --git a/git-ls-remote.sh b/git-ls-remote.sh
index 2c9a588..b6882a9 100755
--- a/git-ls-remote.sh
+++ b/git-ls-remote.sh
@@ -53,7 +53,7 @@ http://* | https://* )
if [ -n "$GIT_SSL_NO_VERIFY" ]; then
curl_extra_args="-k"
fi
- curl -nsf $curl_extra_args "$peek_repo/info/refs" ||
+ curl -nsf $curl_extra_args --header "Pragma: no-cache" "$peek_repo/info/refs" ||
echo "failed slurping"
;;
--
1.3.0.rc1.g9aef-dirty
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox