* [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
* Re: rsync deprecated but promoted?
From: Linus Torvalds @ 2005-09-26 17:55 UTC (permalink / raw)
To: walt; +Cc: git
In-Reply-To: <dh98gk$6rp$1@sea.gmane.org>
On Mon, 26 Sep 2005, walt wrote:
>
> 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
That commit shouldn't be dangling, but I suspect it is harmless and is
most likely because you have pack-files. Use "git-fsck-cache --full" if
you are downloading with http/rsync (since that gets packs without
unpacking them, and you haven't re-packed everything).
The git thing may be similar, although it sounds unlikely. A more likely
reason is that earlier http pulling got incomplete trees if you ever
interrupted it with ^C.
> Yet both trees compile and run perfectly. Are these messages
> worrisome? (BTW, git was cloned and updated using http.)
Yes, they can be worrisome. Some of it may be normal (I really suspect
that the kernel tree is that kind - a "dangling commit" is almost always
either because you've lost a tag or because of a pack-file that wasn't
examined).
Your git tree is quote possibly corrupted.
The good news is that if "git checkout" works, then the corruption is all
old - you may not have all of the history, but the corruption is
"harmless".
There's nothing fundamentally wrong with not having all of history: it
will cause fsck to complain (unless you "plug" the history by using a
graft file). And obviously it means that you may not be able to go back in
time - but you may never even care.
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?
Linus
^ permalink raw reply
* Re: How to make Cogito use git-fetch-pack?
From: H. Peter Anvin @ 2005-09-26 18:10 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Petr Baudis, Git Mailing List
In-Reply-To: <4334B428.7020608@zytor.com>
H. Peter Anvin wrote:
> Petr Baudis wrote:
>
>> Dear diary, on Sat, Sep 24, 2005 at 12:20:08AM CEST, I got a letter
>> where "H. Peter Anvin" <hpa@zytor.com> told me that...
>>
>>> Is there any way to make Cogito use git-fetch-pack instead of
>>> git-ssh-fetch? git+ssh:// seems to invoke the latter.
>>
>>
>> I just added git+packed+ssh:// to be used for this purpose.
>>
>
> Since git tends to use "pack" (e.g. git-fetch-pack) I'd suggest use
> git+pack+ssh:// instead. It's shorter, too.
>
I thought some more about this, and realized that it really doesn't make
sense for there to be another name for this. Simply put, git+ssh://
requires ssh access and git to be present on the other side, and within
those parameters it should use whatever access method is most effective.
Thus, having a separate URL type only makes sense if something is
fundamentally and user-visibly different between the two.
-hpa
^ permalink raw reply
* Re: [PATCH 1/3] Support for SSL client cert
From: Petr Baudis @ 2005-09-26 18:23 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: git
In-Reply-To: <20050926175156.GB9410@reactrix.com>
Dear diary, on Mon, Sep 26, 2005 at 07:51:57PM CEST, I got a letter
where Nick Hengeveld <nickh@reactrix.com> told me that...
> @@ -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];
Could we please have at least --sslkey, if not having 'ssl' prepended to
all of them? You never know when you'll want to call something else like
that in the future... ;-)
--
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 1/3] Support for SSL client cert
From: Nick Hengeveld @ 2005-09-26 18:36 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050926182341.GA26340@pasky.or.cz>
On Mon, Sep 26, 2005 at 08:23:41PM +0200, Petr Baudis wrote:
> Could we please have at least --sslkey, if not having 'ssl' prepended to
> all of them? You never know when you'll want to call something else like
> that in the future... ;-)
Makes sense - I wasn't comfortable deciding what those parameters should be
so I used the curl command-line options. Who gets to make the official
call on that?
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* Re: How to make Cogito use git-fetch-pack?
From: Petr Baudis @ 2005-09-26 18:46 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Git Mailing List
In-Reply-To: <43383999.8090508@zytor.com>
Dear diary, on Mon, Sep 26, 2005 at 08:10:33PM CEST, I got a letter
where "H. Peter Anvin" <hpa@zytor.com> told me that...
> H. Peter Anvin wrote:
> >Petr Baudis wrote:
> >
> >>Dear diary, on Sat, Sep 24, 2005 at 12:20:08AM CEST, I got a letter
> >>where "H. Peter Anvin" <hpa@zytor.com> told me that...
> >>
> >>>Is there any way to make Cogito use git-fetch-pack instead of
> >>>git-ssh-fetch? git+ssh:// seems to invoke the latter.
> >>
> >>
> >>I just added git+packed+ssh:// to be used for this purpose.
> >>
> >
> >Since git tends to use "pack" (e.g. git-fetch-pack) I'd suggest use
> >git+pack+ssh:// instead. It's shorter, too.
> >
>
> I thought some more about this, and realized that it really doesn't make
> sense for there to be another name for this. Simply put, git+ssh://
> requires ssh access and git to be present on the other side, and within
> those parameters it should use whatever access method is most effective.
> Thus, having a separate URL type only makes sense if something is
> fundamentally and user-visibly different between the two.
Tags fetching. I agree that the difference isn't that big other than
this (contrary to the other fetchers, ssh-fetch won't reproduce the pack
setup; this may sound as a bad thing, but it prevents transfer of
redundant data which is pretty much inevitable (or for free) for the
other fetchers). And since we will probably move to the pack fetchers
for tags as well, I agree that there indeed is little point in this.
I will switch all the git+ssh fetching to it after I implement the new
tags fetching.
By the way, how much more CPU-intensive are the pack-based methods in
practice, especially on the server (packing) side? Could it be
noticeable?
--
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.7d, and end of week status.
From: Petr Baudis @ 2005-09-26 19:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Tom Prince, git
In-Reply-To: <7v7jd4n22i.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Mon, Sep 26, 2005 at 01:46:13AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> 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"?
I don't like that, the notion that you are fetching different stuff that
you are merging then seems quite confusing to me. But fetching just the
first revision will be confusing too. Either way, git-pull won't be
equivalent to git-fetch && git-merge (or git-resolve or whatever is the
core porcelain command) anymore. Well, the remotes stuff never got close
to my heart.
One alternative I can think of is, in case there are multiple heads,
require the user to explicitly specify the head he wants (origin#maint).
This comes from the idea that multi-head remotes are there really
primarily for fetching, not for pulling. There is also no potential for
confusion. In addition, there might another line "Default" in the remote
file, which could specify the default choice. It's just that choosing
the first one implicitly makes me a bit nervous and has potential for
bad mistakes. At least for Cogito, I would be reluctant to use it.
git-pull --merge-all or something to still do the octopus merge might be
useful in some cases (or as well might not - perhaps the best strategy
is to let whoever cares make a patch ;).
--
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: walt @ 2005-09-26 19:23 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.58.0509261038460.3308@g5.osdl.org>
Linus Torvalds wrote:
>
> On Mon, 26 Sep 2005, walt wrote:
>> 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
>
> That commit shouldn't be dangling, but I suspect it is harmless and is
> most likely because you have pack-files. Use "git-fsck-cache --full"
Using the --full flag made the error disappear for your kernel tree,
but had no effect on the git tree.
I neglected to mention that I use cg-clone and cg-update rather than
the git equivalents. (cogito 0.15.1 from kernel.org)
> Your git tree is quote possibly corrupted.
I recloned from http://kernel.org and I still get exactly the same fsck
errors for git, with or without the --full flag.
(I mention this only FYI. I'm not having any problems compiling or
using either git or the kernel.)
^ permalink raw reply
* Re: git 0.99.7b doesn't build on Cygwin
From: Jon Loeliger @ 2005-09-26 19:33 UTC (permalink / raw)
To: Git List
In-Reply-To: <Pine.LNX.4.58.0509241526180.3308@g5.osdl.org>
On Sat, 2005-09-24 at 17:27, Linus Torvalds wrote:
> On Sat, 24 Sep 2005, Linus Torvalds wrote:
> >
> > It mentions longhorn.
>
> Anyway, regardless, we could certainly make HEAD be a regular file
> containing the name of the head instead.
I cleverly removed a branch this morning (intentionally),
but what I failed to realize was that it was also the
current HEAD. The next series of command were oddly
cryptic, only telling me the git-read-tree usage message.
Not a clue in the world why, of course. After poking
around, reading some scripts and all, I discovered that
I had a dangling .git/HEAD symlink still point to my
removed branch.
Would it be worthwhile for me to re-discover this
Wonky Failure (Hi Linus! :-) and try to write it up
somewhere or dream up a better error message patch?
Thanks,
jdl
^ permalink raw reply
* Re: rsync deprecated but promoted?
From: Johannes Schindelin @ 2005-09-26 20:12 UTC (permalink / raw)
To: walt; +Cc: git
In-Reply-To: <dh9hqs$6nl$1@sea.gmane.org>
Hi,
On Mon, 26 Sep 2005, walt wrote:
> Using the --full flag made the error disappear for your kernel tree,
> but had no effect on the git tree.
I think it is because of the "pu" branch, which gets fetched using rsync,
but no ref is pointing to it. Since the "pu" branch is rebased quite
often, it would also happen if you fetched the "pu" branch, though.
Ciao,
Dscho
^ permalink raw reply
* Re: GIT 0.99.7d, and end of week status.
From: Jon Loeliger @ 2005-09-26 20:17 UTC (permalink / raw)
To: Git List
In-Reply-To: <7v7jd4n22i.fsf@assigned-by-dhcp.cox.net>
On Sun, 2005-09-25 at 18:46, Junio C Hamano wrote:
> 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?
Hmmm... Would it make sense to introduce something
like this instead:
# When fetching, get bits from here:
URL: http://...../git.git
# When fetching, grab and map like this:
Fetch: master:origin maint:maint +pu:pu
# When merging, merge origin, maint and pu into master
Merge: master origin maint pu
With the intent that the "Fetch:" line effectively
limits the fetching operation to git-fetch, and doesn't
specify how to merge. Then, the "Merge:" line specifies
how to do the git-merge bits. If you didn't want to
merge in the maint and pu bits, this would have been
the line instead:
# Merge into master the just the origin bits
Merge: master origin
If you want the dual-step fetch+merge, the leave the "Pull:"
line as originally written:
# Fetch and merge
Pull: master:origin maint:maint +pu:pu
Syntax can be argued, of course. My point being to
introduce another line to the remote file that
distinguishes the default behavior for each step
along the way.
Thanks,
jdl
^ permalink raw reply
* Re: rsync deprecated but promoted?
From: Junio C Hamano @ 2005-09-26 20:19 UTC (permalink / raw)
To: walt; +Cc: git
In-Reply-To: <dh9hqs$6nl$1@sea.gmane.org>
walt <wa1ter@myrealbox.com> writes:
>>> From git I got this:
>>> $git-fsck-objects
>>> missing commit 00d8bbd3c4bba72a6dfd48c2c0c9cbaa000f13c2
>>> broken link from tag 02b2acff8bafb6d73c6513469cdda0c6c18c4138
>>> to commit d5bc7eecbbb0b9f6122708bf5cd62f78ebdaafd8
>>> <similar lines snipped>
>> Your git tree is quote possibly corrupted.
>
> I recloned from http://kernel.org and I still get exactly the same fsck
> errors for git, with or without the --full flag.
That 00d8bbd3c4bba72a6dfd48c2c0c9cbaa000f13c2 is v0.99.7c commit.
While I do not doubt your git repository is missing that object,
it probably is a buggy clone method. Let me see if I can
reproduce.
$ git clone http://kernel.org/pub/scm/git/git.git/ git-clone
(says a lot of "got" and "walk" here)
$ cd git-clone
$ git-cat-file -t 00d8bbd3c4bba72a6dfd48c2c0c9cbaa000f13c2
commit
$ git-fsck-objects
$ git-fsck-objects --full
$ exit
Nope. Things look OK from here.
^ permalink raw reply
* Re: git 0.99.7b doesn't build on Cygwin
From: Junio C Hamano @ 2005-09-26 20:23 UTC (permalink / raw)
To: Jon Loeliger; +Cc: git
In-Reply-To: <1127763214.5735.25.camel@cashmere.sps.mot.com>
Jon Loeliger <jdl@freescale.com> writes:
> Would it be worthwhile for me to re-discover this
> Wonky Failure (Hi Linus! :-) and try to write it up
> somewhere or dream up a better error message patch?
Thanks.
^ permalink raw reply
* Re: GIT 0.99.7d, and end of week status.
From: Junio C Hamano @ 2005-09-26 20:23 UTC (permalink / raw)
To: git
In-Reply-To: <200509260709.12937.alan@chandlerfamily.org.uk>
Alan Chandler <alan@chandlerfamily.org.uk> writes:
> 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)
Because "git fetch origin tag v0.99.7d" fetched only that tag --
git-fetch command is not told to fetch anything else. Most
importantly, it did not tell it to update "maint" branch head
from the remote. That was why I said that instrucition was
busted.
^ permalink raw reply
* Re: GIT 0.99.7d, and end of week status.
From: Junio C Hamano @ 2005-09-26 20:25 UTC (permalink / raw)
To: Petr Baudis; +Cc: Tom Prince, git
In-Reply-To: <20050926191037.GD26340@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> ... Either way, git-pull won't be equivalent to git-fetch &&
> git-merge (or git-resolve or whatever is the core porcelain
> command) anymore.
"pull = fetch + merge" is a reasonable approximation to use when
you explain what they are to somebody, but taking it literally
would harm usefulness.
It is what you have already lived with for a while. "git pull
.../linux/2.6.git v2.6.11-tree v2.6.12" would fetch both heads
but merges v2.6.12 head only (because v2.6.11-tree is not
something you can merge with).
The typical use cases are:
- The remote does not have more than one head (majority of the
kernel.org repositories are single head repositories). You
could say "Pull: master:somebody" in .git/remotes/somebody
and say "git pull somebody" and pull is fetch + merge. The
proposed fix does not affect this case.
- The remote has more than one heads, and they are usually both
interesting. Some kernel.org repositories have release and
test heads and people who are interested in what is happening
in that subsystem are likely to want to inspect both, so
fetching both makes a lot of sense (especially given
multi-head fetch over git-native protocol is more efficieint
than fetching them separately), but obviously merging both
into an Octopus does not make any sense most of the time.
You could say "Pull: release:a/release test:a/test" in
.git/remotes/subsys and "git fetch subsys" would fetch both
and store them locally. "git pull subsys" would fetch both
but merges only subs/release, which is far more useful than
attempting to make an Octopus with both heads. You could
still say "git pull subsys test" to only fetch and merge
test, if you needed to do something different from what the
"merge only the first one by default" rule gives.
- The remote has 47 different heads, and they are more or less
independent developments in the same area ("topic branches").
Jeff's libata-dev repository may be a good example. "Pull:
ALL:libata-dev/ALL ncq:libata-dev/ncq
chs-support:libata-dev/chs-support ..." would be what one
would place in .git/remotes/libata-dev. This list can be a
subset of the heads that exist at remote but only the heads
one is interested in. "git fetch libata-dev" would get all
the heads in that repository one is interested in, "git pull
libata-dev" would merge in ALL (which is premerged at the
remote side) thanks to the "merge only first one by default"
rule. If you want to make Octopus with selected heads (not
the one Jeff made in ALL), you still can say "git pull
libata-dev ncq chs-support" to do so.
^ permalink raw reply
* Re: rsync deprecated but promoted?
From: Petr Baudis @ 2005-09-26 20:43 UTC (permalink / raw)
To: walt; +Cc: git
In-Reply-To: <dh98gk$6rp$1@sea.gmane.org>
Dear diary, on Mon, Sep 26, 2005 at 06:44:04PM CEST, I got a letter
where walt <wa1ter@myrealbox.com> told me that...
> 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>
This isn't too harmful. It just means that you have a tag ref and the
corresponding tag object, but not the commit tagged by that object.
This is nothing harmful as long as you don't try to reference the tag,
and if you don't have the commit object already, it's actually not quite
likely that you would, since you don't have the branch the bug belongs
to anyway. I'll hopefully fix this bug during the weekend.
--
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 1/3] Support for SSL client cert
From: Junio C Hamano @ 2005-09-26 20:43 UTC (permalink / raw)
To: Petr Baudis, Nick Hengeveld; +Cc: git
In-Reply-To: <20050926182341.GA26340@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Could we please have at least --sslkey, if not having 'ssl' prepended to
> all of them? You never know when you'll want to call something else like
> that in the future... ;-)
That is a valid concern.
Anoter possibility is to read them from the environment, since
we already do SSL_NO_VERIFY from there.
If we go that route, it might make sense to have something like
the following in .git/remotes/that-site file:
URL: https://some.company.site.xz
ENV: GIT_SSL_KEY='/home/user/.ssl/'My ssl key'
ENV: GIT_SSL_CERT='/home/user/.ssl/certs/My Certificate'
ENV: GIT_SSL_CAPATH='/home/user/.ssl/My CA'
...
then at the beginning of git-fetch, we could eval these ENV
lines.
^ permalink raw reply
* Re: cogito push problem
From: Nico -telmich- Schottelius @ 2005-09-26 20:51 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050925220222.GA21013@pasky.or.cz>
[-- Attachment #1: Type: text/plain, Size: 656 bytes --]
Petr Baudis [Mon, Sep 26, 2005 at 12:02:23AM +0200]:
> > Thanks for your help, cg-update && cg-commit worked fine, because
> > cg-update overwrote the changes made by me (I checked cg-diff before,
> > so that was my intention, not cg-update's fault).
>
> But it definitively shouldn't do that anyway. Was that 0.15.1?
No:
[18:51] hydrogenium:cinit% cg --version
cogito-0.14.2 (e9f8fea9ab0a71dfc6586d18a362bcae6843f074)
You have new mail.
I was too lazy to update, but will do that now.
Nico
--
Latest project: cconfig (http://nico.schotteli.us/papers/linux/cconfig/)
Open Source nutures open minds and free, creative developers.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 827 bytes --]
^ permalink raw reply
* [PATCH] wrap scp in cogito
From: Dan Aloni @ 2005-09-26 21:15 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
Hello,
Since git allows to wrap ssh by the means of the GIT_SSH environment
variable I think it would be appropriate to complete the picture and wrap
the usage of scp in cogito by using the same measures. The patch follows.
diff --git a/cg-Xlib b/cg-Xlib
--- a/cg-Xlib
+++ b/cg-Xlib
@@ -471,6 +471,12 @@ if [ "$_git_requires_root" ] && [ "$_git
exit 1
fi
+if [ "$GIT_SCP" != "" ] ; then
+ _cogito_scp=$GIT_SCP
+else
+ _cogito_scp=scp
+fi
+
# Backward compatibility hacks:
# Fortunately none as of now.
diff --git a/cg-fetch b/cg-fetch
--- a/cg-fetch
+++ b/cg-fetch
@@ -206,7 +206,7 @@ get_ssh()
echo "Warning: Cannot protect against overwriting $dest when fetching over ssh" 2>/dev/null
[ "$directory" ] && dest=$(dirname "$dest")
- scp $scp_flags "$src" "$dest"
+ ${_cogito_scp} $scp_flags "$src" "$dest"
}
fetch_ssh()
--
Dan Aloni
da-x@monatomic.org, da-x@colinux.org, da-x@gmx.net
^ permalink raw reply
* Re: [PATCH 2/3] Support for partial HTTP transfers
From: Junio C Hamano @ 2005-09-26 21:19 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: git
In-Reply-To: <20050926175204.GC9410@reactrix.com>
Nick Hengeveld <nickh@reactrix.com> writes:
> + unlink(prevfile);
> + rename(tmpfile, prevfile);
> + unlink(tmpfile);
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 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.
Personally, I do not think people would mind much if we
introduce the BKL at the beginning of git-fetch.sh to prevent
multiple fetches stomping on each other, if somebody cared
enough (hint, hint).
> - snprintf(tmpfile, sizeof(tmpfile), "%s/obj_XXXXXX",
> - get_object_directory());
> + local = open(tmpfile, O_WRONLY | O_CREAT | O_EXCL, 0666);
> - local = mkstemp(tmpfile);
I introduced this mkstemp() part recently to mimic the local
object creation where newly created object files are built in
the same directory, hoping that they would be allocated close to
each other when more than one are created in sequence. I do not
know it matters much in practice -- has anybody measured, and
does anybody care?
> + /* 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.
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.
^ permalink raw reply
* Re: [PATCH 3/3] Return CURL error message when object transfer fails
From: Junio C Hamano @ 2005-09-26 21:22 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: git
In-Reply-To: <20050926175211.GD9410@reactrix.com>
Nick Hengeveld <nickh@reactrix.com> writes:
> It might be better to extend this to all places that curl_easy_perform
> is called, rather than just in fetch_object.
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.
^ permalink raw reply
* Re: Cogito: cg-clone doesn't like packed tag objects
From: Petr Baudis @ 2005-09-26 21:25 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Git Mailing List
In-Reply-To: <20050924011833.GJ10255@pasky.or.cz>
Dear diary, on Sat, Sep 24, 2005 at 03:18:33AM CEST, I got a letter
where Petr Baudis <pasky@suse.cz> told me that...
> Dear diary, on Sat, Sep 24, 2005 at 12:24:06AM CEST, I got a letter
> where "H. Peter Anvin" <hpa@zytor.com> told me that...
> > Packed tag objects breaks Cogito when using git+ssh:// transport.
> >
> > Example:
> >
> > cg-clone -s git+ssh://master.kernel.org/pub/scm/libs/klibc/klibc.git
>
> I changed the code to use the git-*-fetch tools to fetch the objects
> referenced by tags, so this works properly now. Thanks for the report.
And now thanks to "walt" I realized that this is a completely wrong way
to go. The problem is that the tags don't have to tag anything on your
branch, and if you are fetching a given branch, you want only commits
from that branch. But fetching the tags will cause all the commits
connected to the tags getting slurped too, and we didn't want that.
So the strategy I'm thinking of now is to manually (I think no GIT tool
can do that for me) dereference the possible tag chain until I end up at
some non-tag object. Now, if it is a commit and I don't have it yet, it
means that it is not interesting to me because it does not belong to a
branch I'm following, so I will just ignore the tag (won't download
anything else and won't record it in the refs/tags directory).
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.
The ideal and the least expensive solution for this, obviously, would be
having this logic in git-fetch-pack. :-)
Opinions?
--
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: Cogito: cg-clone doesn't like packed tag objects
From: Brian Gerst @ 2005-09-26 21:55 UTC (permalink / raw)
To: Petr Baudis; +Cc: H. Peter Anvin, Git Mailing List
In-Reply-To: <20050926212536.GF26340@pasky.or.cz>
Petr Baudis wrote:
> Dear diary, on Sat, Sep 24, 2005 at 03:18:33AM CEST, I got a letter
> where Petr Baudis <pasky@suse.cz> told me that...
>
>>Dear diary, on Sat, Sep 24, 2005 at 12:24:06AM CEST, I got a letter
>>where "H. Peter Anvin" <hpa@zytor.com> told me that...
>>
>>>Packed tag objects breaks Cogito when using git+ssh:// transport.
>>>
>>>Example:
>>>
>>>cg-clone -s git+ssh://master.kernel.org/pub/scm/libs/klibc/klibc.git
>>
>>I changed the code to use the git-*-fetch tools to fetch the objects
>>referenced by tags, so this works properly now. Thanks for the report.
>
>
> And now thanks to "walt" I realized that this is a completely wrong way
> to go. The problem is that the tags don't have to tag anything on your
> branch, and if you are fetching a given branch, you want only commits
> from that branch. But fetching the tags will cause all the commits
> connected to the tags getting slurped too, and we didn't want that.
>
> So the strategy I'm thinking of now is to manually (I think no GIT tool
> can do that for me) dereference the possible tag chain until I end up at
> some non-tag object. Now, if it is a commit and I don't have it yet, it
> means that it is not interesting to me because it does not belong to a
> branch I'm following, so I will just ignore the tag (won't download
> anything else and won't record it in the refs/tags directory).
I think this is the right idea.
> 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.
--
Brian Gerst
^ permalink raw reply
* Re: git 0.99.7b doesn't build on Cygwin
From: H. Peter Anvin @ 2005-09-26 21:54 UTC (permalink / raw)
To: Davide Libenzi; +Cc: Giuseppe Bilotta, git
In-Reply-To: <Pine.LNX.4.63.0509252203510.817@localhost.localdomain>
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.
-hpa
^ 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