* [PATCH 3/3] Return CURL error message when object transfer fails
From: Nick Hengeveld @ 2005-09-26 17:52 UTC (permalink / raw)
To: git
Return CURL error message when object transfer fails
Signed-off-by: Nick Hengeveld <nickh@reactrix.com>
---
It might be better to extend this to all places that curl_easy_perform
is called, rather than just in fetch_object.
http-fetch.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
330da7634e6a707779dcc8648841f501d2a47568
diff --git a/http-fetch.c b/http-fetch.c
--- a/http-fetch.c
+++ b/http-fetch.c
@@ -19,6 +19,7 @@
static CURL *curl;
static struct curl_slist *no_pragma_header;
static struct curl_slist *no_range_header;
+static char curl_errorstr[CURL_ERROR_SIZE];
static char *initial_base;
@@ -389,6 +390,7 @@ int fetch_object(struct alt_base *repo,
curl_easy_setopt(curl, CURLOPT_FILE, NULL);
curl_easy_setopt(curl, CURLOPT_WRITEFUNCTION, fwrite_sha1_file);
curl_easy_setopt(curl, CURLOPT_HTTPHEADER, no_pragma_header);
+ curl_easy_setopt(curl, CURLOPT_ERRORBUFFER, curl_errorstr);
url = xmalloc(strlen(repo->base) + 50);
strcpy(url, repo->base);
@@ -448,7 +450,7 @@ int fetch_object(struct alt_base *repo,
curl_result = curl_easy_perform(curl);
curl_easy_setopt(curl, CURLOPT_HTTPHEADER, no_range_header);
if (curl_result != 0) {
- return -1;
+ return error(curl_errorstr);
}
fchmod(local, 0444);
^ permalink raw reply
* [PATCH 2/3] Support for partial HTTP transfers
From: Nick Hengeveld @ 2005-09-26 17:52 UTC (permalink / raw)
To: git
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.
Signed-off-by: Nick Hengeveld <nickh@reactrix.com>
---
http-fetch.c | 72 ++++++++++++++++++++++++++++++++++++++++++++++++++++++----
1 files changed, 67 insertions(+), 5 deletions(-)
34a692953368188cbaefbd6c60e400053f8528b4
diff --git a/http-fetch.c b/http-fetch.c
--- a/http-fetch.c
+++ b/http-fetch.c
@@ -13,8 +13,12 @@
#define curl_global_init(a) do { /* nothing */ } while(0)
#endif
+#define PREV_BUF_SIZE 4096
+#define RANGE_HEADER_SIZE 30
+
static CURL *curl;
static struct curl_slist *no_pragma_header;
+static struct curl_slist *no_range_header;
static char *initial_base;
@@ -351,14 +355,26 @@ int fetch_object(struct alt_base *repo,
char *filename = sha1_file_name(sha1);
unsigned char real_sha1[20];
char tmpfile[PATH_MAX];
+ char prevfile[PATH_MAX];
int ret;
char *url;
char *posn;
+ int prevlocal;
+ unsigned char prev_buf[PREV_BUF_SIZE];
+ ssize_t prev_read = 0;
+ long prev_posn = 0;
+ char range[RANGE_HEADER_SIZE];
+ struct curl_slist *range_header = NULL;
+ CURLcode curl_result;
+
+ snprintf(tmpfile, sizeof(tmpfile), "%s.temp", filename);
+ snprintf(prevfile, sizeof(prevfile), "%s.prev", filename);
+ unlink(prevfile);
+ rename(tmpfile, prevfile);
+ unlink(tmpfile);
- snprintf(tmpfile, sizeof(tmpfile), "%s/obj_XXXXXX",
- get_object_directory());
+ local = open(tmpfile, O_WRONLY | O_CREAT | O_EXCL, 0666);
- local = mkstemp(tmpfile);
if (local < 0)
return error("Couldn't create temporary file %s for %s: %s\n",
tmpfile, filename, strerror(errno));
@@ -386,8 +402,52 @@ int fetch_object(struct alt_base *repo,
curl_easy_setopt(curl, CURLOPT_URL, url);
- if (curl_easy_perform(curl)) {
- unlink(filename);
+ /* If a previous temp file is present, process what was already
+ fetched. */
+ prevlocal = open(prevfile, O_RDONLY);
+ if (prevlocal != -1) {
+ do {
+ prev_read = read(prevlocal, prev_buf, PREV_BUF_SIZE);
+ if (prev_read>0) {
+ if (fwrite_sha1_file(prev_buf,
+ 1,
+ prev_read,
+ NULL) == prev_read) {
+ prev_posn += prev_read;
+ } else {
+ prev_read = -1;
+ }
+ }
+ } while (prev_read > 0);
+ close(prevlocal);
+ }
+ unlink(prevfile);
+
+ /* Reset inflate/SHA1 if there was an error reading the previous temp
+ file; also rewind to the beginning of the local file. */
+ if (prev_read == -1) {
+ memset(&stream, 0, sizeof(stream));
+ inflateInit(&stream);
+ SHA1_Init(&c);
+ if (prev_posn>0) {
+ prev_posn = 0;
+ lseek(local, SEEK_SET, 0);
+ }
+ }
+
+ /* If we have successfully processed data from a previous fetch
+ attempt, only fetch the data we don't already have. */
+ if (prev_posn>0) {
+ sprintf(range, "Range: bytes=%ld-", prev_posn);
+ range_header = curl_slist_append(range_header, range);
+ curl_easy_setopt(curl, CURLOPT_HTTPHEADER, range_header);
+ }
+
+ /* Clear out the Range: header after performing the request, so
+ other curl requests don't inherit inappropriate header data */
+ curl_result = curl_easy_perform(curl);
+ curl_easy_setopt(curl, CURLOPT_HTTPHEADER, no_range_header);
+ if (curl_result != 0) {
return -1;
}
@@ -517,6 +577,7 @@ int main(int argc, char **argv)
curl = curl_easy_init();
no_pragma_header = curl_slist_append(no_pragma_header, "Pragma:");
+ no_range_header = curl_slist_append(no_range_header, "Range:");
/* Set SSL parameters if they were provided */
if (ssl_cert != NULL) {
@@ -549,6 +610,7 @@ int main(int argc, char **argv)
return 1;
curl_slist_free_all(no_pragma_header);
+ curl_slist_free_all(no_range_header);
curl_global_cleanup();
return 0;
}
^ permalink raw reply
* [PATCH 1/3] Support for SSL client cert
From: Nick Hengeveld @ 2005-09-26 17:51 UTC (permalink / raw)
To: git
Added SSL client args and CURL settings
Signed-off-by: Nick Hengeveld <nickh@reactrix.com>
---
http-fetch.c | 28 +++++++++++++++++++++++++++-
1 files changed, 27 insertions(+), 1 deletions(-)
2d293c34fdfde8a394b5f8a5c5343d9caf363bcc
diff --git a/http-fetch.c b/http-fetch.c
--- a/http-fetch.c
+++ b/http-fetch.c
@@ -476,6 +476,10 @@ int main(int argc, char **argv)
char *commit_id;
char *url;
int arg = 1;
+ char *ssl_cert = NULL;
+ char *ssl_key = NULL;
+ char *ssl_capath = NULL;
+ char *ssl_cacert = NULL;
while (arg < argc && argv[arg][0] == '-') {
if (argv[arg][1] == 't') {
@@ -491,11 +495,19 @@ int main(int argc, char **argv)
} else if (argv[arg][1] == 'w') {
write_ref = argv[arg + 1];
arg++;
+ } else if (arg+1 < argc && !strcmp(argv[arg], "--cert")) {
+ ssl_cert = argv[++arg];
+ } else if (arg+1 < argc && !strcmp(argv[arg], "--key")) {
+ ssl_key = argv[++arg];
+ } else if (arg+1 < argc && !strcmp(argv[arg], "--capath")) {
+ ssl_capath = argv[++arg];
+ } else if (arg+1 < argc && !strcmp(argv[arg], "--cacert")) {
+ ssl_cacert = argv[++arg];
}
arg++;
}
if (argc < arg + 2) {
- usage("git-http-fetch [-c] [-t] [-a] [-d] [-v] [--recover] [-w ref] commit-id url");
+ usage("git-http-fetch [-c] [-t] [-a] [-d] [-v] [--recover] [-w ref] [--cert ssl-cert-file] [--key ssl-key-file] [--capath CA-dir] [--cacert CA-cert-file] commit-id url");
return 1;
}
commit_id = argv[arg];
@@ -506,6 +518,20 @@ int main(int argc, char **argv)
curl = curl_easy_init();
no_pragma_header = curl_slist_append(no_pragma_header, "Pragma:");
+ /* Set SSL parameters if they were provided */
+ if (ssl_cert != NULL) {
+ curl_easy_setopt(curl, CURLOPT_SSLCERT, ssl_cert);
+ }
+ if (ssl_key != NULL) {
+ curl_easy_setopt(curl, CURLOPT_SSLKEY, ssl_key);
+ }
+ if (ssl_capath != NULL) {
+ curl_easy_setopt(curl, CURLOPT_CAPATH, ssl_capath);
+ }
+ if (ssl_cacert != NULL) {
+ curl_easy_setopt(curl, CURLOPT_CAINFO, ssl_cacert);
+ }
+
curl_ssl_verify = getenv("GIT_SSL_NO_VERIFY") ? 0 : 1;
curl_easy_setopt(curl, CURLOPT_SSL_VERIFYPEER, curl_ssl_verify);
#if LIBCURL_VERSION_NUM >= 0x070907
^ permalink raw reply
* [PATCH 0/3] http-fetch enhancements
From: Nick Hengeveld @ 2005-09-26 17:51 UTC (permalink / raw)
To: git
The following series contains some http-fetch enhancements, based on
our requirements for use of SSL client certificates and partial HTTP
transfers.
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* Re: rsync deprecated but promoted?
From: walt @ 2005-09-26 16:44 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.58.0509260801430.3308@g5.osdl.org>
Linus Torvalds wrote:
[...]
> You basically have to run fsck on your repository after an rsync. And if
> it returns errors, you're screwed unless you remember what your old heads
> were.
Just because you mentioned it, I did a git-fsck-objects on my local
copies of your kernel tree and Junio's git tree.
From git I got this:
$git-fsck-objects
missing commit 00d8bbd3c4bba72a6dfd48c2c0c9cbaa000f13c2
broken link from tag 02b2acff8bafb6d73c6513469cdda0c6c18c4138
to commit d5bc7eecbbb0b9f6122708bf5cd62f78ebdaafd8
<similar lines snipped>
From your tree I got only this single line:
dangling commit 02459eaab98a6a57717bc0cacede148fc76af881
Yet both trees compile and run perfectly. Are these messages
worrisome? (BTW, git was cloned and updated using http.)
^ permalink raw reply
* Re: rsync deprecated but promoted?
From: Brian Gerst @ 2005-09-26 16:47 UTC (permalink / raw)
To: Petr Baudis; +Cc: Martin Coxall, Zack Brown, git
In-Reply-To: <20050926163604.GC21019@pasky.or.cz>
Petr Baudis wrote:
> Dear diary, on Mon, Sep 26, 2005 at 04:41:54PM CEST, I got a letter
> where Brian Gerst <bgerst@didntduck.org> told me that...
>
>>The other problem with HTTP vs. rsync is that the HTTP fetch will walk
>>the entire tree down to the root to verify it has every object. While
>>this isn't a bad thing it's usually unnecessary when it's all in one big
>>pack file.
>
>
> Is that really the case? I believe it will walk only to the original ref
> and assume everything before is complete. (Actually, it doesn't even
> seem to honor the --recover patch anymore, which isn't so nice
> especially in case some objects disappeared from your database and you
> would like to get them back. Happenned to me.)
I was talking about the initial pull. It does stop at the previous head
for updates.
--
Brian Gerst
^ permalink raw reply
* Re: rsync deprecated but promoted?
From: Linus Torvalds @ 2005-09-26 16:43 UTC (permalink / raw)
To: Petr Baudis; +Cc: Martin Coxall, Zack Brown, git
In-Reply-To: <20050926163846.GD21019@pasky.or.cz>
On Mon, 26 Sep 2005, Petr Baudis wrote:
>
> Actually, it would be nice to be able to tell git-fsck-objects to only
> verify objects which are referenced between given two commits (perhaps
> just make it support the ^object notation). Then I wouldn't mind running
> that after each rsync fetch in Cogito.
You can kind of do it.
Do
git-rev-list --objects $oldheads --not $newheads >& /dev/null
echo "$?"
and it _should_ largely work. Untested, of course, but I _hope_ that if
any object is missing, git-rev-list should die with an error. And if it
doesn't, I should fix it ;)
Linus
^ permalink raw reply
* Re: rsync deprecated but promoted?
From: Petr Baudis @ 2005-09-26 16:38 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Martin Coxall, Zack Brown, git
In-Reply-To: <Pine.LNX.4.58.0509260801430.3308@g5.osdl.org>
Dear diary, on Mon, Sep 26, 2005 at 05:04:25PM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> told me that...
> You basically have to run fsck on your repository after an rsync. And if
> it returns errors, you're screwed unless you remember what your old heads
> were.
Actually, it would be nice to be able to tell git-fsck-objects to only
verify objects which are referenced between given two commits (perhaps
just make it support the ^object notation). Then I wouldn't mind running
that after each rsync fetch in Cogito.
--
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: rsync deprecated but promoted?
From: Petr Baudis @ 2005-09-26 16:36 UTC (permalink / raw)
To: Brian Gerst; +Cc: Martin Coxall, Zack Brown, git
In-Reply-To: <433808B2.3070508@didntduck.org>
Dear diary, on Mon, Sep 26, 2005 at 04:41:54PM CEST, I got a letter
where Brian Gerst <bgerst@didntduck.org> told me that...
> The current HTTP fetch doesn't do asynchronous requests (using
> curl_multi_*). This means that no transfers occur while processing
> received objects.
That should be fixed then, so that we fully utilize the network.
> The other problem with HTTP vs. rsync is that the HTTP fetch will walk
> the entire tree down to the root to verify it has every object. While
> this isn't a bad thing it's usually unnecessary when it's all in one big
> pack file.
Is that really the case? I believe it will walk only to the original ref
and assume everything before is complete. (Actually, it doesn't even
seem to honor the --recover patch anymore, which isn't so nice
especially in case some objects disappeared from your database and you
would like to get them back. Happenned to me.)
But there were changes in that not so long ago, so maybe I'm still
confused.
--
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: rsync deprecated but promoted?
From: Linus Torvalds @ 2005-09-26 15:04 UTC (permalink / raw)
To: Petr Baudis; +Cc: Martin Coxall, Zack Brown, git
In-Reply-To: <20050926133204.GB21019@pasky.or.cz>
On Mon, 26 Sep 2005, Petr Baudis wrote:
>
> Nope. rsync always did packs, I actually un-deprecated it for the time
> period when HTTP didn't. The thing is, rsync is bad - it will happily
> put duplicate, redundant, and especially unwanted data to your
> repository, especially when the shared GIT repositories happen.
Worse than that, rsync will happily sync up to a remote repository without
even getting _all_ the object files, and never tell you anything is wrong.
This happened to several people when the kernel.org mirroring was
broken/delayed.
So yes, rsync is fast. But it's fast exactly _because_ it is broken. Very
very fundamentally broken.
You basically have to run fsck on your repository after an rsync. And if
it returns errors, you're screwed unless you remember what your old heads
were.
Linus
^ permalink raw reply
* Re: rsync deprecated but promoted?
From: Brian Gerst @ 2005-09-26 14:41 UTC (permalink / raw)
To: Petr Baudis; +Cc: Martin Coxall, Zack Brown, git
In-Reply-To: <20050926133204.GB21019@pasky.or.cz>
Petr Baudis wrote:
> Dear diary, on Sun, Sep 25, 2005 at 09:06:37PM CEST, I got a letter
> where Martin Coxall <quasi@cream.org> told me that...
>
>>On 25 Sep 2005, at 17:32, Zack Brown wrote:
>>
>>>Hi folks,
>>>
>>>When I use cogito, it gives a warning saying the rsync method is
>>>deprecated and
>>>will be removed in the future. But when I visit kernel.org/git, the
>>>page says to
>>>use an rsync URL with cg-clone.
>>>
>>>Maybe kernel.org should be updated?
>>>
>>
>>It does seem to be sending out a confusing message to us users too,
>>since an initial clone of Linus's tree with rsync is on my machine 10x
>>faster than an http clone, so it seems to be sending out something of a
>>confused/confusing message re: rsync.
>>
>>Am I right in thinking it's because rsync didn't originally have pack
>>support, but now it does, Petr has simply forgotten to deprecate the
>>deprecation message?
>
>
> Nope. rsync always did packs, I actually un-deprecated it for the time
> period when HTTP didn't. The thing is, rsync is bad - it will happily
> put duplicate, redundant, and especially unwanted data to your
> repository, especially when the shared GIT repositories happen. HTTP and
> git-daemon are much better access methods in this regard - actually, I
> still like HTTP the most:
>
> + Works everywhere - no special setup, no dedicated service, firewalls
> and proxies won't stop it
> + Works properly, i.e. only getting stuff you want, unlike rsync
> + Replicates packs setup - would be even better if it would kill objects
> and packs which the new pack makes redundant
>
> It would be best to have some smarter git-prune-packed, which
> would process just a single pack. The other alternative would be
> that it would prune packs being subsets of other packs as well,
> but that scaled bad. I will write another mail about that.
>
> - It is slow. Actually, I think it should be much faster for incremental
> fetches, and the initial fetch should take about the same time if you
> use packs. But the question is, did we already hit the limit? Are we
> using HTTP keepalive connections, do we parallelize the requests?
>
The current HTTP fetch doesn't do asynchronous requests (using
curl_multi_*). This means that no transfers occur while processing
received objects.
The other problem with HTTP vs. rsync is that the HTTP fetch will walk
the entire tree down to the root to verify it has every object. While
this isn't a bad thing it's usually unnecessary when it's all in one big
pack file.
--
Brian Gerst
^ permalink raw reply
* Re: rsync deprecated but promoted?
From: Petr Baudis @ 2005-09-26 13:32 UTC (permalink / raw)
To: Martin Coxall; +Cc: Zack Brown, git
In-Reply-To: <4d4586301dca616f42880612fae01492@cream.org>
Dear diary, on Sun, Sep 25, 2005 at 09:06:37PM CEST, I got a letter
where Martin Coxall <quasi@cream.org> told me that...
> On 25 Sep 2005, at 17:32, Zack Brown wrote:
> >Hi folks,
> >
> >When I use cogito, it gives a warning saying the rsync method is
> >deprecated and
> >will be removed in the future. But when I visit kernel.org/git, the
> >page says to
> >use an rsync URL with cg-clone.
> >
> >Maybe kernel.org should be updated?
> >
>
> It does seem to be sending out a confusing message to us users too,
> since an initial clone of Linus's tree with rsync is on my machine 10x
> faster than an http clone, so it seems to be sending out something of a
> confused/confusing message re: rsync.
>
> Am I right in thinking it's because rsync didn't originally have pack
> support, but now it does, Petr has simply forgotten to deprecate the
> deprecation message?
Nope. rsync always did packs, I actually un-deprecated it for the time
period when HTTP didn't. The thing is, rsync is bad - it will happily
put duplicate, redundant, and especially unwanted data to your
repository, especially when the shared GIT repositories happen. HTTP and
git-daemon are much better access methods in this regard - actually, I
still like HTTP the most:
+ Works everywhere - no special setup, no dedicated service, firewalls
and proxies won't stop it
+ Works properly, i.e. only getting stuff you want, unlike rsync
+ Replicates packs setup - would be even better if it would kill objects
and packs which the new pack makes redundant
It would be best to have some smarter git-prune-packed, which
would process just a single pack. The other alternative would be
that it would prune packs being subsets of other packs as well,
but that scaled bad. I will write another mail about that.
- It is slow. Actually, I think it should be much faster for incremental
fetches, and the initial fetch should take about the same time if you
use packs. But the question is, did we already hit the limit? Are we
using HTTP keepalive connections, do we parallelize the requests?
--
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: git 0.99.7b doesn't build on Cygwin
From: Giuseppe Bilotta @ 2005-09-26 11:00 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0509252203510.817@localhost.localdomain>
On Sun, 25 Sep 2005 22:05:29 -0700 (PDT), 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 ...
Well, sure. I wasn't thinking about just substituting .lnk files for
symlinks, but that's the closest thing you can get on Windows,
currently, so maybe supporting this kind of thing would be the best
approach.
--
Giuseppe "Oblomov" Bilotta
[W]hat country can preserve its liberties, if its rulers are not
warned from time to time that [the] people preserve the spirit of
resistance? Let them take arms...The tree of liberty must be
refreshed from time to time, with the blood of patriots and
tyrants.
-- Thomas Jefferson, letter to Col. William S. Smith, 1787
^ permalink raw reply
* Re: GIT 0.99.7d, and end of week status.
From: Alan Chandler @ 2005-09-26 6:09 UTC (permalink / raw)
To: git
In-Reply-To: <7v1x3cn1cj.fsf@assigned-by-dhcp.cox.net>
On Monday 26 Sep 2005 01:01, Junio C Hamano wrote:
> Alan Chandler <alan@chandlerfamily.org.uk> writes:
> > Does that mean I have missed some step along the way to get the maint
> > branch position moved to the new tag?
>
> To recap, you did:
>
> (before 0.99.7d propagated to the mirrors)
> $ git clone http://kernel.org/pub/scm/git/git.git git-src
> $ cd git-src
>
> (after 0.99.7d propagated to the mirrors)
> $ git fetch origin tag v0.99.7d
> $ git checkout -f maint
Actually, I got as far as doing the fetch, but I didn't checkout anything. I
just ran gitk --all
I would have been on the branch that the git clone would have left me on
(presumably master)
>
> The 'fetch origin tag v0.99.7d' step should have left
> the new file .git/refs/tags/v0.99.7d _after_ downloading all the
> objects necessary to reconstruct the history to get there.
>
Yes - I gitk showed had all the objects - but v0.99.7d was a a tag at the tip
of an unamed branch
> Ah, you are right. My instruction did not update other branches
> for you. My bad.
>
> Assuming people stay on their "master" branch, and have the
> recommended .git/remotes/origin contents in my previous message,
> then the steps "after 0.99.7d propagated to the mirrors" would
> just be:
>
> $ git fetch
Its not the "other" branches that I was concerned about, it was the "maint"
branch reference which seemed to still be still at the same commit as the
v0.99.7c tag, at least that was what gitk --all showed me, after the fetch.
>
> which would fetch all the branches mentioned in the remotes
> file, and then:
>
> $ git checkout -f maint
This is where I get puzzled. Fetch on its own didn't move where "maint"
pointed to so doing this checkout would have left me at the v0.99.7c tag (I
didn't actually do it - as I was then puzzling over the documentation trying
to see what I did wrong)
I realise I could have just manually moved it - but none of the steps in your
instructions seemed to move it for me.
In the end - I blew my git away and repeated the clone exercise after the
mirrors had updated - in this version the "maint" branch was co-incident with
the v0.99.7d tag
>
> which would switch your working tree to maint branch.
>
> NOTE NOTE NOTE. The above assumes you are on your "master"
> branch when you run 'git fetch' --- if you are on any of the
> branches that is being updated (you can check which branch you
> are on with 'git branch' without argument, or just with 'ls -l
> .git/HEAD') 'git fetch' will complain because doing so without
> updating them to match the updated branch head would make your
> index file and working tree inconsistent with your .git/HEAD,
> but 'git fetch' is supposed to be only fetching without touching
> the working tree.
--
Alan Chandler
http://www.chandlerfamily.org.uk
^ permalink raw reply
* Re: git 0.99.7b doesn't build on Cygwin
From: Davide Libenzi @ 2005-09-26 5:05 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git
In-Reply-To: <1o29so2d1zd0i$.1d0cf386vluxi.dlg@40tude.net>
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 ...
- Davide
^ permalink raw reply
* Re: git 0.99.7b doesn't build on Cygwin
From: Junio C Hamano @ 2005-09-26 4:57 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git
In-Reply-To: <1o29so2d1zd0i$.1d0cf386vluxi.dlg@40tude.net>
Giuseppe Bilotta <bilotta78@hotpop.com> writes:
>> Hah, didn't know this one. Requiring LongHorn is pretty strict though ;)
>
> However, it might be possible to use .lnk files, which would work on
> both NTFS and FAT32, and even under Win9x.
Possibly, but it is a moot point now.
When textual "symbolic refs" support becomes mature, we will use
it on boxes without symbolic links to express .git/HEAD.
^ permalink raw reply
* Re: git 0.99.7b doesn't build on Cygwin
From: Giuseppe Bilotta @ 2005-09-25 19:59 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0509241540170.16554@localhost.localdomain>
On Sat, 24 Sep 2005 15:41:27 -0700 (PDT), Davide Libenzi wrote:
> On Sat, 24 Sep 2005, Linus Torvalds wrote:
>
>>
>>
>> On Sat, 24 Sep 2005, Davide Libenzi wrote:
>>>
>>> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/createhardlink.asp
>>
>> Don't you mean
>>
>> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/createsymboliclink.asp
>>
>> rather?
>>
>> It mentions longhorn.
>
> Hah, didn't know this one. Requiring LongHorn is pretty strict though ;)
However, it might be possible to use .lnk files, which would work on
both NTFS and FAT32, and even under Win9x.
--
Giuseppe "Oblomov" Bilotta
"I weep for our generation" -- Charlie Brown
^ permalink raw reply
* Re: Add "git-update-ref" to update the HEAD (or other) ref
From: Junio C Hamano @ 2005-09-26 4:25 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List, Davide Libenzi
In-Reply-To: <Pine.LNX.4.58.0509251747290.3308@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> I was actually thinking of maybe entirely replacing "read_ref()" with the
> more powerful "resolve_ref()" - moving resolve_ref() into refs.c.
>
> That way there's only one place that knows about the "ref:" thing.
That would make sense. But I am feeling a bit too weak tonight
and am going to crash now.
^ permalink raw reply
* Re: Add "git-update-ref" to update the HEAD (or other) ref
From: Linus Torvalds @ 2005-09-26 1:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Davide Libenzi
In-Reply-To: <7vhdc8n2xb.fsf@assigned-by-dhcp.cox.net>
On Sun, 25 Sep 2005, Junio C Hamano wrote:
>
> Is something like the one at the end acceptable?
Looking at the patch closer, no, that's incorrect.
"oldsha" doesn't necessarily exist, since there has to be some way to
force the new one. So if "oldval" is NULL, we shouldn't re-verify
anything.
Also, independently of that your patch is buggy because calling
"resolve_ref()" again will overwrite the lockpath, since it's re-used by
the static buffer in git_path(). That's why the "strdup()" is there.
Yeah, yeah, static buffers are evil, but they are also simple and
efficient.
But something like this (on top of my original one) might work.
Linus
----
diff --git a/update-ref.c b/update-ref.c
--- a/update-ref.c
+++ b/update-ref.c
@@ -63,6 +63,19 @@ const char *resolve_ref(const char *path
return path;
}
+static int re_verify(const char *path, unsigned char *oldsha1, unsigned char *currsha1)
+{
+ char buf[40];
+ int fd = open(path, O_RDONLY), nr;
+ if (fd < 0)
+ return -1;
+ nr = read(fd, buf, 40);
+ close(fd);
+ if (nr != 40 || get_sha1_hex(buf, currsha1) < 0)
+ return -1;
+ return memcmp(oldsha1, currsha1, 20) ? -1 : 0;
+}
+
int main(int argc, char **argv)
{
char *hex;
@@ -108,14 +121,18 @@ int main(int argc, char **argv)
unlink(lockpath);
die("Unable to write to %s", lockpath);
}
-
+
/*
- * FIXME!
- *
- * We should re-read the old ref here, and re-verify that it
- * matches "oldsha1". Otherwise there's a small race.
+ * Re-read the ref after getting the lock to verify
*/
+ if (oldval && re_verify(path, oldsha1, currsha1) < 0) {
+ unlink(lockpath);
+ die("Ref lock failed");
+ }
+ /*
+ * Finally, replace the old ref with the new one
+ */
if (rename(lockpath, path) < 0) {
unlink(lockpath);
die("Unable to create %s", path);
^ permalink raw reply
* Re: Add "git-update-ref" to update the HEAD (or other) ref
From: Linus Torvalds @ 2005-09-26 0:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Davide Libenzi
In-Reply-To: <7vhdc8n2xb.fsf@assigned-by-dhcp.cox.net>
On Sun, 25 Sep 2005, Junio C Hamano wrote:
>
> I'd like to take these patches in two stages (I am not asking
> you for a resend):
>
> - Drop the emulated symlink part from the update-ref.c; have it
> graduate to "master" branch and use it in existing scripts.
Sure.
> - Take the read_ref() change, along with a patch to re-add the
> emulated symlink part to update-ref.c (after making its
> interpretation to match that of read_ref() -- which requires
> the prefix to be exactly "ref: " five bytes); keep it in "pu"
> branch a bit longer.
I was actually thinking of maybe entirely replacing "read_ref()" with the
more powerful "resolve_ref()" - moving resolve_ref() into refs.c.
That way there's only one place that knows about the "ref:" thing.
But yes, forcing the format to be "ref: " instead of "ref:<whitespace>*"
sounds fine.
Linus
^ permalink raw reply
* Re: The latest commit to add new keybindings
From: Paul Mackerras @ 2005-09-26 0:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4q8b8d5j.fsf@assigned-by-dhcp.cox.net>
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).
> With "${1+$@}", you are passing an empty parameter after '--'
> when gitk itself receives no parameter. Maybe it is intended,
> maybe not...
No, it isn't intended, thanks for pointing that out.
Regards,
Paul.
^ permalink raw reply
* Re: GIT 0.99.7d, and end of week status.
From: Junio C Hamano @ 2005-09-26 0:01 UTC (permalink / raw)
To: Alan Chandler; +Cc: git
In-Reply-To: <200509252143.23905.alan@chandlerfamily.org.uk>
Alan Chandler <alan@chandlerfamily.org.uk> writes:
> Does that mean I have missed some step along the way to get the maint branch
> position moved to the new tag?
To recap, you did:
(before 0.99.7d propagated to the mirrors)
$ git clone http://kernel.org/pub/scm/git/git.git git-src
$ cd git-src
(after 0.99.7d propagated to the mirrors)
$ git fetch origin tag v0.99.7d
$ git checkout -f maint
The 'fetch origin tag v0.99.7d' step should have left
the new file .git/refs/tags/v0.99.7d _after_ downloading all the
objects necessary to reconstruct the history to get there.
Ah, you are right. My instruction did not update other branches
for you. My bad.
Assuming people stay on their "master" branch, and have the
recommended .git/remotes/origin contents in my previous message,
then the steps "after 0.99.7d propagated to the mirrors" would
just be:
$ git fetch
which would fetch all the branches mentioned in the remotes
file, and then:
$ git checkout -f maint
which would switch your working tree to maint branch.
NOTE NOTE NOTE. The above assumes you are on your "master"
branch when you run 'git fetch' --- if you are on any of the
branches that is being updated (you can check which branch you
are on with 'git branch' without argument, or just with 'ls -l
.git/HEAD') 'git fetch' will complain because doing so without
updating them to match the updated branch head would make your
index file and working tree inconsistent with your .git/HEAD,
but 'git fetch' is supposed to be only fetching without touching
the working tree.
^ permalink raw reply
* Re: GIT 0.99.7d, and end of week status.
From: Junio C Hamano @ 2005-09-25 23:46 UTC (permalink / raw)
To: Tom Prince; +Cc: git
In-Reply-To: <87psqwzs3x.fsf@ualberta.net>
Tom Prince <tom.prince@ualberta.net> writes:
>> When you already have a repository to track git.git, I would
>> recommend to have something like this in .git/remote/origin:
>>
>> URL: http://kernel.org/pub/scm/git/git.git
>> Pull: master:origin maint:maint +pu:pu
>>
>
> A warning when you do this. If you say
>
> git pull origin
>
> then your master will be updated with an octopus merge of the three heads.
Ahhhhhhhh. That is true. I always do "git fetch" and never do
"git pull" against anything but a local repository, heads
explicitly specified. You are right. The defaulting behaviour
is incredibly broken.
Do people agree it is a good idea to change the "git pull
origin" to mean "fetch all the default refs specified on Pull:
lines, and merge only the first one into the current branch"?
"git pull" without remote nor refspecs is a synonym to "git pull
origin" as before, and 99.99% of the time "git pull" from a
remote repo without explicit refspec is doing just one head
merge, so I think this is a sane default, much saner than the
current mess, while still allowing you to keep track of what's
happening in the other branches by doing fetches of all the
heads at once.
Opinions?
^ permalink raw reply
* Re: Add "git-update-ref" to update the HEAD (or other) ref
From: Junio C Hamano @ 2005-09-25 23:27 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List, Davide Libenzi
In-Reply-To: <Pine.LNX.4.58.0509251134480.3308@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> + * FIXME!
Is something like the one at the end acceptable?
I'd like to take these patches in two stages (I am not asking
you for a resend):
- Drop the emulated symlink part from the update-ref.c; have it
graduate to "master" branch and use it in existing scripts.
- Take the read_ref() change, along with a patch to re-add the
emulated symlink part to update-ref.c (after making its
interpretation to match that of read_ref() -- which requires
the prefix to be exactly "ref: " five bytes); keep it in "pu"
branch a bit longer.
---
diff --git a/update-ref.c b/update-ref.c
--- a/update-ref.c
+++ b/update-ref.c
@@ -97,11 +97,13 @@ int main(int argc, char **argv)
}
/*
- * FIXME!
- *
- * We should re-read the old ref here, and re-verify that it
+ * We re-read the old ref here, and re-verify that it
* matches "oldsha1". Otherwise there's a small race.
*/
+ if (!resolve_ref(git_path("%s", refname), oldsha1))
+ die("Cannot verify ref: %s", refname);
+ if (memcmp(oldsha1, currsha1, 20))
+ die("Ref %s changed to %s", refname, sha1_to_hex(oldsha1));
if (rename(lockpath, path) < 0) {
unlink(lockpath);
^ permalink raw reply
* Re: GIT 0.99.7d, and end of week status.
From: Tom Prince @ 2005-09-25 22:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vaci1nfwa.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
>
> When you already have a repository to track git.git, I would
> recommend to have something like this in .git/remote/origin:
>
> URL: http://kernel.org/pub/scm/git/git.git
> Pull: master:origin maint:maint +pu:pu
>
A warning when you do this. If you say
git pull origin
then your master will be updated with an octopus merge of the three heads.
Tom
^ 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