* Re: Cloning from sites with 404 overridden
From: Nick Hengeveld @ 2006-03-22 18:36 UTC (permalink / raw)
To: git
In-Reply-To: <20060322172227.GO3997@reactrix.com>
On Wed, Mar 22, 2006 at 09:22:27AM -0800, Nick Hengeveld wrote:
> It might be feasible to detect this condition using the Content-Type:
> header in the server response. So far, all the GIT repositories I've
> tried return text/plain for loose objects and a special 404 page will
> likely be text/html.
Something like this:
http_fetch: report text/html responses for loose objects
Some HTTP server environments return a 200 status and text/html error
document or a redirect to one rather than a 404 status if a loose
object does not exist. This patch detects and reports this condition
to differentiate between a misconfigured server and an actual corrupt
object on the server.
Signed-off-by: Nick Hengeveld <nickh@reactrix.com>
---
http-fetch.c | 19 ++++++++++++++++++-
1 files changed, 18 insertions(+), 1 deletions(-)
61069cc348640fef2b8c503b8b8f00f689872cab
diff --git a/http-fetch.c b/http-fetch.c
index dc67218..ee5b585 100644
--- a/http-fetch.c
+++ b/http-fetch.c
@@ -41,6 +41,7 @@ struct object_request
CURLcode curl_result;
char errorstr[CURL_ERROR_SIZE];
long http_code;
+ char *content_type;
unsigned char real_sha1[20];
SHA_CTX c;
z_stream stream;
@@ -258,9 +259,15 @@ static void finish_object_request(struct
static void process_object_response(void *callback_data)
{
+ char *content_type;
struct object_request *obj_req =
(struct object_request *)callback_data;
+ curl_easy_getinfo(obj_req->slot->curl, CURLINFO_CONTENT_TYPE,
+ &content_type);
+ if (content_type)
+ obj_req->content_type = strdup(content_type);
+
obj_req->curl_result = obj_req->slot->curl_result;
obj_req->http_code = obj_req->slot->http_code;
obj_req->slot = NULL;
@@ -298,6 +305,8 @@ static void release_object_request(struc
entry->next = entry->next->next;
}
+ if (obj_req->content_type)
+ free(obj_req->content_type);
free(obj_req->url);
free(obj_req);
}
@@ -340,6 +349,7 @@ void prefetch(unsigned char *sha1)
memcpy(newreq->sha1, sha1, 20);
newreq->repo = alt;
newreq->url = NULL;
+ newreq->content_type = NULL;
newreq->local = -1;
newreq->state = WAITING;
snprintf(newreq->filename, sizeof(newreq->filename), "%s", filename);
@@ -836,7 +846,14 @@ static int fetch_object(struct alt_base
obj_req->http_code, hex);
} else if (obj_req->zret != Z_STREAM_END) {
corrupt_object_found++;
- ret = error("File %s (%s) corrupt", hex, obj_req->url);
+ if (obj_req->content_type &&
+ !strcmp(obj_req->content_type, "text/html")) {
+ ret = error("text/html response for file %s (%s)",
+ sha1_to_hex(obj_req->sha1), obj_req->url);
+ } else {
+ ret = error("File %s (%s) corrupt",
+ sha1_to_hex(obj_req->sha1), obj_req->url);
+ }
} else if (memcmp(obj_req->sha1, obj_req->real_sha1, 20)) {
ret = error("File %s has bad hash", hex);
} else if (obj_req->rename < 0) {
--
1.2.4.gb1bc1d-dirty
^ permalink raw reply related
* Re: Cloning from sites with 404 overridden
From: Junio C Hamano @ 2006-03-22 19:05 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: git
In-Reply-To: <20060322183621.GP3997@reactrix.com>
Nick Hengeveld <nickh@reactrix.com> writes:
> Some HTTP server environments return a 200 status and text/html error
> document or a redirect to one rather than a 404 status if a loose
> object does not exist. This patch detects and reports this condition
> to differentiate between a misconfigured server and an actual corrupt
> object on the server.
> 61069cc348640fef2b8c503b8b8f00f689872cab
> diff --git a/http-fetch.c b/http-fetch.c
> index dc67218..ee5b585 100644
> --- a/http-fetch.c
> +++ b/http-fetch.c
> @@ -41,6 +41,7 @@ struct object_request
> CURLcode curl_result;
>...
> + char *content_type;
> unsigned char real_sha1[20];
>...
You probably need only one bit here,...
> @@ -258,9 +259,15 @@ static void finish_object_request(struct
>
> static void process_object_response(void *callback_data)
>...
> + curl_easy_getinfo(obj_req->slot->curl, CURLINFO_CONTENT_TYPE,
> + &content_type);
> + if (content_type)
> + obj_req->content_type = strdup(content_type);
> +
... and note if that is an HTML document or not.
We do bend backwards to support ISP HTTP servers, but this might
be going a bit too far. Also I wonder if ISP runs a really
dumb-friendly configured server that defaults to text/html
unless the mimemap says otherwise. Loose object files do not
have suffixes and I am expecting these servers would give
whatever the server default is.
^ permalink raw reply
* Re: What's in git.git
From: Junio C Hamano @ 2006-03-22 19:15 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060322115218.GT18185@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
>> A new configuration option, 'core.warnambiguousrefs', can be
>> set to warn you if you use "frotz" to name a ref when you
>> have more than one "frotz" under $GIT_DIR/refs (e.g. you have
>> both branch "frotz" and tag "frotz", and/or you have
>> refs/remotes/frotz/HEAD).
>
> Is there any reason why this isn't enabled by default?
Not in particular, other than Inertia and trying one baby step
at a time.
^ permalink raw reply
* Re: [PATCH] Format tweaks for asciidoc.
From: Junio C Hamano @ 2006-03-22 19:16 UTC (permalink / raw)
To: Francis Daly; +Cc: git
In-Reply-To: <20060322095357.GA27793@craic.sysops.org>
Thanks.
One request, though. Next time please sign-off your patch.
^ permalink raw reply
* Proper Publishing of a Repository
From: Jon Loeliger @ 2006-03-22 19:17 UTC (permalink / raw)
To: Git List
Folks,
So, I feel like I missed a step in the grand
"How To Publish A Repository" scheme of things.
I made a repo visible over on jdl.com. No problem.
But cloning it took forever. So I ran "git-repack"
on it. Now cloning only takes hours, not forever.
All this on the linux kernel over HTTP.
Did I miss a step somewhere?
Thanks,
jdl
^ permalink raw reply
* Re: Cloning from sites with 404 overridden
From: Junio C Hamano @ 2006-03-22 19:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vslpa8fld.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> We do bend backwards to support ISP HTTP servers, but this might
> be going a bit too far. Also I wonder if ISP runs a really
> dumb-friendly configured server that defaults to text/html
> unless the mimemap says otherwise. Loose object files do not
> have suffixes and I am expecting these servers would give
> whatever the server default is.
Clarification. Even if a server configured as such existed and
sent an otherwise valid loose object with text/html, your code
does the right thing.
However the patch would not help when such a server also did a
"Sorry, did you mistype the URL?" HTML response, and I was
wondering how typical that would be.
^ permalink raw reply
* Best way to generate a git tree containing only a subset of commits from another tree?
From: Anton Altaparmakov @ 2006-03-22 19:28 UTC (permalink / raw)
To: git
As subject, what is at present the best way to generate a git tree
containing only a subset of commits from another tree.
So I have /usr/src/my-big-tree and /usr/src/linux-2.6 and now I want to
add some of the commits in my-big-tree to the tree linux-2.6 so I can push
out to Linus.
Preferable I would like to do it so that later when Linus has pulled from
my /usr/src/linux-2.6 tree, I do a "git pull" of Linus' tree from
/usr/src/my-big-tree and it all works correctly and I don't end up with
the same commits twice.
Is that possible at all?
If not what can I do to do it cleanly? Does git help in any way or do I
literally have to export all my commits from /usr/src/my-big-tree to diff
style patches and then throw away the tree, clone Linus tree after he has
pulled my /usr/src/linux-2.6 tree and commit all my generated diff patches
again? That would be rather horrible to have to do...
I am happy to be pointed to a FAQ or RTFM if you tell me where to look for
it...
Thanks a lot in advance!
PS. Please keep me CC:-ed as I am not on the git mailing list any more.
Best regards,
Anton
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/
^ permalink raw reply
* Re: Proper Publishing of a Repository
From: Timo Hirvonen @ 2006-03-22 20:16 UTC (permalink / raw)
To: git
In-Reply-To: <1143055072.4527.142.camel@cashmere.sps.mot.com>
On Wed, 22 Mar 2006 13:17:52 -0600
Jon Loeliger <jdl@freescale.com> wrote:
> Folks,
>
> So, I feel like I missed a step in the grand
> "How To Publish A Repository" scheme of things.
>
> I made a repo visible over on jdl.com. No problem.
> But cloning it took forever. So I ran "git-repack"
> on it. Now cloning only takes hours, not forever.
>
> All this on the linux kernel over HTTP.
Use git:// protocol (git-daemon) if possible. It is much faster.
--
http://onion.dynserv.net/~timo/
^ permalink raw reply
* Re: [PATCH] Fix multi-paragraph list items in OPTIONS section
From: Jonas Fonseca @ 2006-03-22 20:03 UTC (permalink / raw)
To: Francis Daly; +Cc: git
In-Reply-To: <20060320104118.GA32151@craic.sysops.org>
Francis Daly <francis@daoine.org> wrote Mon, Mar 20, 2006:
> On Mon, Mar 20, 2006 at 10:39:46, Jonas Fonseca wrote:
>
> > Asciidoc cannot handle multi-paragraph description list items without the
> > need for adding special control characters and reindenting all paragraphs
> > but the first.
>
> This issue affects the display of current git-cvsimport and
> git-svnimport doc pages. There was a general tidy-up done in
> df8baa42fe4eeb5a021ac262caf601f44d2a5746 last October, but additions
> since then didn't keep the layout.
I think we are only a few people who cares about this and the vast
number of git manpages makes it very time consuming to keep the layout
polished. Personally, I care mostly for the git core manpages. Maybe if
they lived in a separate directory from the git porcelain manpages it
would be easier to get them into a better shape.
> I don't think there is a full "fix" for this; either the html docs are
> ugly (see the -A section in the pages mentioned above as they are now),
> or the asciidoc source files look odd (although that's probably not a
> big problem) or the manpages look a bit funny.
I found the same thing. Getting both good HTML and manpages is not
trivial unless you use only limited and simple markup. Some things
supported by the HTML generator is not available or doesn't turn out as
good in the generated manpages. This was the main reason I decided to
add a special script to strip/convert markup when generating the cg-ref
manpages.
As for the odd looking asciidoc sources, you can always generate a clean
text version. BTW, for lists you can get rid of the '+' continuations
tags by embedding the list in a pair of '--'. It makes the resulting
source a little more readable.
--
- item 1, para 1
item 1, para 2
- item 2
--
--
Jonas Fonseca
^ permalink raw reply
* Re: Proper Publishing of a Repository
From: Jon Loeliger @ 2006-03-22 20:26 UTC (permalink / raw)
To: Timo Hirvonen; +Cc: Git List
In-Reply-To: <20060322221630.e65baca0.tihirvon@gmail.com>
On Wed, 2006-03-22 at 14:16, Timo Hirvonen wrote:
> On Wed, 22 Mar 2006 13:17:52 -0600
> Jon Loeliger <jdl@freescale.com> wrote:
>
> > Folks,
> >
> > So, I feel like I missed a step in the grand
> > "How To Publish A Repository" scheme of things.
> >
> > I made a repo visible over on jdl.com. No problem.
> > But cloning it took forever. So I ran "git-repack"
> > on it. Now cloning only takes hours, not forever.
> >
> > All this on the linux kernel over HTTP.
>
> Use git:// protocol (git-daemon) if possible. It is much faster.
Trust me, if it were an option, I would. It isn't.
So, I think git-prune-packed was the answer here...
jdl
^ permalink raw reply
* Re: Proper Publishing of a Repository
From: Junio C Hamano @ 2006-03-22 20:47 UTC (permalink / raw)
To: Jon Loeliger; +Cc: git
In-Reply-To: <1143059181.4527.162.camel@cashmere.sps.mot.com>
Jon Loeliger <jdl@freescale.com> writes:
> On Wed, 2006-03-22 at 14:16, Timo Hirvonen wrote:
>> Jon Loeliger <jdl@freescale.com> wrote:
>>
>> > All this on the linux kernel over HTTP.
>>
>> Use git:// protocol (git-daemon) if possible. It is much faster.
>
> Trust me, if it were an option, I would. It isn't.
>
> So, I think git-prune-packed was the answer here...
It really depends on who your audiences are. By packing
everything in a single pack, you are optimizing for the initial
cloners but punishing incremental updaters.
Since your tree is derived from Linus tree, anybody who is
interested in your tree is very likely nterested in Linus tree
and chances are that she has a recent copy of it locally. In
such a case, I would not be surprised if:
$ git clone -l -s -n /local-linux-2.6.git/ jdl-linux.git
$ cd jdl-linux.git
$ git fetch http://jdl.com/jdl-linux.git master:refs/heads/jdl
goes a lot faster if you have loose objects around in the
repository.
^ permalink raw reply
* Re: Question about possible git races
From: Radoslaw Szkodzinski @ 2006-03-22 20:46 UTC (permalink / raw)
To: git
In-Reply-To: <200603201724.12442.astralstorm@o2.pl>
[-- Attachment #1: Type: text/plain, Size: 538 bytes --]
On Monday 20 March 2006 17:24, Radoslaw Szkodzinski wrote yet:
> I'd like to write a multithreaded application using git, so I'd like to see
> if there are any races:
>
> - push vs fetch
> ...
> - push vs push
> ...
> - fetch vs fetch
> ...
>
> I'm meaning really bare git there, w/o bash+perl scripts.
Could anyone try to answer the question?
I'd really like to know, because it's crucial to my application.
--
GPG Key id: 0xD1F10BA2
Fingerprint: 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2
AstralStorm
[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: Cloning from sites with 404 overridden
From: Radoslaw Szkodzinski @ 2006-03-22 21:24 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Nick Hengeveld
In-Reply-To: <7vslpa8fld.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 909 bytes --]
On Wednesday 22 March 2006 20:05, Junio C Hamano wrote yet:
>
> .. and note if that is an HTML document or not.
>
Better yet, see first if the object is corrupt. If it is and its Content-Type
is text/html, error out.
> We do bend backwards to support ISP HTTP servers, but this might
> be going a bit too far. Also I wonder if ISP runs a really
> dumb-friendly configured server that defaults to text/html
> unless the mimemap says otherwise. Loose object files do not
> have suffixes and I am expecting these servers would give
> whatever the server default is.
That server would break a *lot* of file types. That admin should be hanged,
shot, then burned.
I think of only one reason for doing that: to restrict file types posted on
the server to, say, zip and html.
--
GPG Key id: 0xD1F10BA2
Fingerprint: 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2
AstralStorm
[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: Best way to generate a git tree containing only a subset of commits from another tree?
From: Radoslaw Szkodzinski @ 2006-03-22 21:28 UTC (permalink / raw)
To: git; +Cc: Anton Altaparmakov
In-Reply-To: <Pine.LNX.4.64.0603221920260.22475@hermes-2.csi.cam.ac.uk>
[-- Attachment #1: Type: text/plain, Size: 995 bytes --]
On Wednesday 22 March 2006 20:28, Anton Altaparmakov wrote yet:
> Preferable I would like to do it so that later when Linus has pulled from
> my /usr/src/linux-2.6 tree, I do a "git pull" of Linus' tree from
> /usr/src/my-big-tree and it all works correctly and I don't end up with
> the same commits twice.
>
> Is that possible at all?
Should work out of the box.
> If not what can I do to do it cleanly? Does git help in any way or do I
> literally have to export all my commits from /usr/src/my-big-tree to diff
> style patches and then throw away the tree, clone Linus tree after he has
> pulled my /usr/src/linux-2.6 tree and commit all my generated diff patches
> again? That would be rather horrible to have to do...
It will work flawlessly if Linus merges your patch without any changes.
Else git will merge and maybe conflict if the change was major.
--
GPG Key id: 0xD1F10BA2
Fingerprint: 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2
AstralStorm
[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: Question about possible git races
From: Andreas Ericsson @ 2006-03-22 23:28 UTC (permalink / raw)
To: Radoslaw Szkodzinski; +Cc: git
In-Reply-To: <200603201724.12442.astralstorm@o2.pl>
Radoslaw Szkodzinski wrote:
> I'd like to write a multithreaded application using git,
Why on earth? The git tools aren't written to be thread-safe in that
manner, so you'll run into all sorts of problems. Unless you're talking
about managing the code for a multithreaded application with git, in
which case you should just go read the tutorial. However, feeling
slightly tipsy and in a distinctly good mood, I shall try to answer your
questions anyway.
> so I'd like to see if
> there are any races:
>
> - push vs pull
> One thread pushes to the repository while another is pulling from it at the
> same time. I should get the older commit.
>
You will. Git atomizes (atomicizes? atomicifies?) pushes by updating the
branch head being pushed to after all the commit-, tree- and
blob-objects are written. Tags are handled separately but equally
atomically.
> - push vs push
> Both threads push at the same time. What happens?
> Any good way to merge those pushes?
> (I have full access to both repos)
>
> Possibly those two aren't fast-forward of each other.
> I think one of the pushes should abort in this case unless I force it.
>
Read the source to find out if it's locking the repo while updating or
not (I think it is, but I'm not sure). If it isn't the last one to
finish pushing wins out since the branch head update from that push will
overwrite the previous one.
> - fetch vs fetch
> I mean that two threads try to fetch from different repositories to a single
> one. Possibly those two aren't fast-forward of each other.
> Any good way to merge those fetches?
> (I have full access to both repos)
>
git help octopus
You can fetch those two remote branch heads to local branches
simultaneously and then do the octopus in the master-thread while no
other updates are happening. Doing several simultanous merges to a
single branch is quite frankly so insane I have to go get myself a drink
just from thinking about it.
> I'm meaning really bare git there, w/o bash+perl scripts.
>
I don't think you can do it without Python. The default merge strategy
is written in python, so.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Errors GITtifying GCC and Binutils
From: Linus Torvalds @ 2006-03-22 23:39 UTC (permalink / raw)
To: Jan-Benedict Glaw; +Cc: git
In-Reply-To: <20060322133337.GU20746@lug-owl.de>
On Wed, 22 Mar 2006, Jan-Benedict Glaw wrote:
>
> I'm currently working a lot with Binutils and GCC and wanted to import
> those two projects into GIT trees, but both of them failed. If anybody
> wants to have access to the half-finished GIT trees, please let me
> know:
Well, I can re-create your error..
> Switching from origin to gdb-4_18-branch
> usage: git-read-tree (<sha> | -m [--aggressive] [-u | -i] <sha1> [<sha2> [<sha3>]])
> read-tree failed: 33024
That's a horrible error message, and the reason for it is that no
"gdb-4_18-branch" exists.
There's a _tag_ called "gdb-4_18", and there's a branch called "GDB_4_18",
and they actually point to two _different_ commits (both "Initial creation
of sourceware repository"). The commits actually have identical trees, but
they're different, because they have different times - by 50 seconds.
Gaah.
Looking at cvsps output (from
cvsps --norc -u -A -v -d --cvsdirect
--root :pserver:anoncvs@sourceware.org:/cvs/src
src > cvsps.out 2> cvsps.err
it's "PatchSet 104" (well, for me it is, I have a hacked cvsps, so it
might not be that for you), which creates the "gdb-4_18-branch", but it
appears that cvsps hasn't actually figured out any "Ancestor branch" for
that commit.
What a crock.
Anyway, it's clearly a cvsps bug (mentioning a new branch without the
_source_ of that branch). Equally clearly, "git cvsimport" is being an ass
about then failing so totally on it.
I'll try to take a look at why cvsps does that.
Linus
^ permalink raw reply
* Re: Question about possible git races
From: Andreas Ericsson @ 2006-03-22 23:55 UTC (permalink / raw)
To: Radoslaw Szkodzinski; +Cc: git
In-Reply-To: <200603222146.25395.astralstorm@o2.pl>
Radoslaw Szkodzinski wrote:
> On Monday 20 March 2006 17:24, Radoslaw Szkodzinski wrote yet:
>
> Could anyone try to answer the question?
> I'd really like to know, because it's crucial to my application.
>
I believe the reasons no-one answered your first mail are, in the
following order:
1. Since I'm sure you're truly capable of writing such an application
and finishing it before the git API has changed completely you should
have gotten your answers from trial-and-error, reading the source, or by
just trying the app and seeing where it fails.
2. You didn't say *why* you want to write a multi-threaded layer on top
of git. Is it to implement a redundant file-server with revision
control? If so you don't need multi-threading. You need clever update
hooks, a master repo and plenty of bandwidth with fast disks on the
file-servers.
3. You didn't mention what you've tried to find the answers yourself,
which makes me think you want me and the rest of us gitizens (yay! I
coined a phrase) do your homework for you. I personally find it very
rude that you send another email again so shortly after the first one
claiming that "you need this info for your app", when the 500-odd people
you're asking clearly need their time for their families, hobbies,
daytime jobs, beer, etc. etc...
4. Noone felt like answering since they saw no use for a multi-threaded
layer on top of git, especially without knowing what it was for.
Friendliness only goes so far when met by such lack of respect for other
peoples time, but if someone had seen the uses for the app you're
writing they probably would have taken time to at least ask you for some
of the answers you left out in your original mail. If nothing else for
the sake of curiosity.
Some more pointers on how to get answers to questions posted in online
forums can be found on the links below.
http://catb.org/~esr/faqs/smart-questions.html
http://www.catb.org/~esr/faqs/hacker-howto.html
Btw. I'm assuming you're aware you'll have to GPL this app of yours,
since git is GPL and you'll be using the git produce in a way that makes
it vital to your app.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Errors GITtifying GCC and Binutils
From: Linus Torvalds @ 2006-03-23 0:12 UTC (permalink / raw)
To: Jan-Benedict Glaw; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0603221517210.26286@g5.osdl.org>
On Wed, 22 Mar 2006, Linus Torvalds wrote:
>
> Looking at cvsps output (from
>
> cvsps --norc -u -A -v -d --cvsdirect
> --root :pserver:anoncvs@sourceware.org:/cvs/src
> src > cvsps.out 2> cvsps.err
>
> it's "PatchSet 104" (well, for me it is, I have a hacked cvsps, so it
> might not be that for you), which creates the "gdb-4_18-branch", but it
> appears that cvsps hasn't actually figured out any "Ancestor branch" for
> that commit.
It _seems_ that the reason for that is that cvsps considers a revision
number of 1.1.1.1 to have a "dot depth" of 0, for some really strange
reason (it's a total special case).
And that will currently not compare as a "greater" dot depth than not
having any revision number at all for the ancestor, so such a revision
will never be considered an ancestor branch.
This one-liner to cvsps.c seems to make sure we have an ancestor branch
for that "gdb-4.18-branch" branch, at least according to the cvsps output.
I'm re-running "git cvsimport" with this cvsps to see if it gets us past
that one point, but I need to go pick up Patricia from school, so I won't
have time to actually check the result. If somebody wants to play with
this, go wild.
(The point of this patch is to make sure that if the head PatchSet doesn't
have an ancestor, we'll consider _any_ valid ancestor to be better than
that).
Linus
---
diff --git a/cvsps.c b/cvsps.c
--- a/cvsps.c
+++ b/cvsps.c
@@ -2599,7 +2599,7 @@ static void determine_branch_ancestor(Pa
* note: rev is the pre-commit revision, not the post-commit
*/
if (!head_ps->ancestor_branch)
- d1 = 0;
+ d1 = -1;
else if (strcmp(ps->branch, rev->branch) == 0)
continue;
else if (strcmp(head_ps->ancestor_branch, "HEAD") == 0)
^ permalink raw reply
* Re: Question about possible git races
From: Junio C Hamano @ 2006-03-23 0:24 UTC (permalink / raw)
To: Radoslaw Szkodzinski; +Cc: git
In-Reply-To: <200603201724.12442.astralstorm@o2.pl>
Radoslaw Szkodzinski <astralstorm@o2.pl> writes:
> - push vs pull
>
> - push vs push
>
> - fetch vs fetch
About push vs push, with "really bare git", I take it that you
mean two send-pack from remote sites running two receive-pack
simultaneously.
There is an explicit race avoidance between the receive-pack
processes. When a ref (either branch head or a tag) is updated,
it does:
- read the current value from the ref.
- do its work.
- lock to prevent others to create the temporary file for
updating the ref.
- create the temporary file for the ref and write the new value.
- check if the ref's value has not changed from what it
initially read;
- rename the temporary file to the ref to unlock.
Read receive-pack.c::update() for exact details if you are
interested.
> I'm meaning really bare git there, w/o bash+perl scripts.
The question does not make any sense for other cases, because
branch update by fetch and pull are all scripts based.
^ permalink raw reply
* Re: Best way to generate a git tree containing only a subset of commits from another tree?
From: Petr Baudis @ 2006-03-23 0:25 UTC (permalink / raw)
To: Anton Altaparmakov; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0603221920260.22475@hermes-2.csi.cam.ac.uk>
Dear diary, on Wed, Mar 22, 2006 at 08:28:52PM CET, I got a letter
where Anton Altaparmakov <aia21@cam.ac.uk> said that...
> Preferable I would like to do it so that later when Linus has pulled from
> my /usr/src/linux-2.6 tree, I do a "git pull" of Linus' tree from
> /usr/src/my-big-tree and it all works correctly and I don't end up with
> the same commits twice.
>
> Is that possible at all?
Not with Git - you will end up with the same commits twice, once when
you originally committed them and once coming cherry-picked from your
linux-2.6 tree through Linus' tree.
> If not what can I do to do it cleanly? Does git help in any way or do I
> literally have to export all my commits from /usr/src/my-big-tree to diff
> style patches and then throw away the tree, clone Linus tree after he has
> pulled my /usr/src/linux-2.6 tree and commit all my generated diff patches
> again? That would be rather horrible to have to do...
Yes, that's the way to go, but actually it's not horrible at all because
there's a tool to help you - check out StGIT, which will let you
maintain a stack of patches on top of a git tree and do all sorts of
cool stuff with them (including rebasing them to new tree revision, the
most important thing for you).
--
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: Best way to generate a git tree containing only a subset of commits from another tree?
From: Andreas Ericsson @ 2006-03-23 0:44 UTC (permalink / raw)
To: Anton Altaparmakov; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0603221920260.22475@hermes-2.csi.cam.ac.uk>
Anton Altaparmakov wrote:
> As subject, what is at present the best way to generate a git tree
> containing only a subset of commits from another tree.
>
git format-patch -k <start-commit>..<end-commit> --stdout | git am -k
Make sure you're on the right branch first, but see below.
> So I have /usr/src/my-big-tree and /usr/src/linux-2.6 and now I want to
> add some of the commits in my-big-tree to the tree linux-2.6 so I can push
> out to Linus.
>
I sense some nomenclature confusion here. By "tree", do you happen to
mean "branch", or possibly "repository"? I know bk does things with
trees that's vaguely git-ish, but a tree in git is, basically, just a
simplified directory listing (without depth, although it can contain
other trees ad infinitum iiuc).
If you mean "branch" (or repository, it doesn't matter since by then
you'll have something like a master branch anyway), as I think you do,
then let's assume the Vanilla Linux lives in the "linus" branch.
You would then do
$ git checkout -b for-linus linus
followed by either multiple
$ git cherry-pick <commit-ish>
or, if the commits are all in series, an iteration of the following
$ git format-patch --stdout <start-commit>..<end-commit> | git am -k
If you have several topic branches, one for each series of commits, you
should be able to do an octopus, like so:
$ git pull . <topic-branches-to-publish>
If you *don't* have several topic branches, or if some commits aren't in
topic-branches, you could try something like this (untested, although it
shouldn't break anything except the for-linus branch which you can
re-create fairly simply)
$ for b in <topic-branches-for-linus>; do
git checkout $b
git rebase for-linus || (git reset --hard; echo $b >> to-merge)
done
# now merge what couldn't be rebased
$ git checkout for-linus
$ git pull . $(cat to-merge)
In your "please-pull" mail to Linus, ask him to pull the 'for-linus'
branch. When he's done so, pull his 'master' branch to your 'linus',
branch and remove the 'for-linus' branch and re-create it from Linus'
master branch again. If your vanilla tree is up-to-date and he pulls
from you before pulling from someone else or adding other commits this
isn't necessary, although you'll have to do
$ git checkout linus; git pull . for-linus
to get the vanilla branch up to speed with Linus' HEAD.
That turned out a bit longer than I expected, and with me being slightly
off sobriety at the moment it would be good if someone less so could
double-check the thinking. Incidentally, this is one of the reasons why
topic-branches is such a Good Thing (tm).
> Preferable I would like to do it so that later when Linus has pulled from
> my /usr/src/linux-2.6 tree, I do a "git pull" of Linus' tree from
> /usr/src/my-big-tree and it all works correctly and I don't end up with
> the same commits twice.
>
> Is that possible at all?
>
I hope so, or I just spent a good 20 minutes not drinking beer for
nothing. ;)
> If not what can I do to do it cleanly? Does git help in any way or do I
> literally have to export all my commits from /usr/src/my-big-tree to diff
> style patches and then throw away the tree, clone Linus tree after he has
> pulled my /usr/src/linux-2.6 tree and commit all my generated diff patches
> again? That would be rather horrible to have to do...
>
It's worth re-iterating:
git format-patch --stdout -k <start-commit>..<end-commit> > patch-series
git am -k patch-series
It will save you a lot of work.
> I am happy to be pointed to a FAQ or RTFM if you tell me where to look for
> it...
>
Hopefully I just supplied one that can be re-used with some
text-mangling by someone capable of being legible and making sense at
the same time.
For more info, check out the man-pages of the commands above (notably
the cherry-pick man-page and the pull command's "merge with local" feature).
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Question about possible git races
From: Radoslaw Szkodzinski @ 2006-03-23 1:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vacbi6m91.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 1681 bytes --]
On Thursday 23 March 2006 01:24, Junio C Hamano wrote yet:
> Radoslaw Szkodzinski <astralstorm@o2.pl> writes:
> > - push vs pull
> >
> > - push vs push
> >
> > - fetch vs fetch
>
> About push vs push, with "really bare git", I take it that you
> mean two send-pack from remote sites running two receive-pack
> simultaneously.
>
> There is an explicit race avoidance between the receive-pack
> processes. When a ref (either branch head or a tag) is updated,
> it does:
>
> - read the current value from the ref.
> - do its work.
> - lock to prevent others to create the temporary file for
> updating the ref.
> - create the temporary file for the ref and write the new value.
> - check if the ref's value has not changed from what it
> initially read;
> - rename the temporary file to the ref to unlock.
>
> Read receive-pack.c::update() for exact details if you are
> interested.
So there is locking I've missed while reading through the source.
Guess all the coffee doesn't help.
There is a lock, so the other git-receive-pack for given ref will fail.
Does that also work for git-local-fetch with -l option?
Looks good though that I can fetch to another ref.
>
> > I'm meaning really bare git there, w/o bash+perl scripts.
>
> The question does not make any sense for other cases, because
> branch update by fetch and pull are all scripts based.
I should have known better than to use vague words.
For me fetch = git-*-fetch. Which in turn calls git-receive-pack.
Thank you for the precise answer.
--
GPG Key id: 0xD1F10BA2
Fingerprint: 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2
AstralStorm
[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: Question about possible git races
From: Radoslaw Szkodzinski @ 2006-03-23 1:24 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <4421DD9E.7030201@op5.se>
[-- Attachment #1: Type: text/plain, Size: 3120 bytes --]
On Thursday 23 March 2006 00:28, Andreas Ericsson wrote yet:
> However, feeling slightly tipsy and in a distinctly good mood, I shall try
to answer your questions anyway.
The golden liquid works for me, great. Thank you.
>
> > so I'd like to see if
> > there are any races:
> >
> > - push vs pull
> > One thread pushes to the repository while another is pulling from it at
> > the same time. I should get the older commit.
>
> You will. Git atomizes (atomicizes? atomicifies?) pushes by updating the
> branch head being pushed to after all the commit-, tree- and
> blob-objects are written.
Just as I expected. Good.
> Tags are handled separately but equally
> atomically.
Good too.
>
> > - fetch vs fetch
> > I mean that two threads try to fetch from different repositories to a
> > single one. Possibly those two aren't fast-forward of each other.
> > Any good way to merge those fetches?
> > (I have full access to both repos)
>
> git help octopus
>
> You can fetch those two remote branch heads to local branches
> simultaneously and then do the octopus in the master-thread while no
> other updates are happening.
I could slurp the unrelated commits with an octopus of course...
But the others pose a problem.
> Doing several simultanous merges to a
> single branch is quite frankly so insane I have to go get myself a drink
> just from thinking about it.
It's a rare situation in the app, but not impossible. (I want to avoid
locking) That's why I was asking about it.
>
> > I'm meaning really bare git there, w/o bash+perl scripts.
>
> I don't think you can do it without Python. The default merge strategy
> is written in python, so.
You've hit it, the app is written in Python (as of yet).
The default merge strategy is simply... calling merge and also detecting
naming/existence conflicts with a simple scalar merge.
The only bit more complicated thing is detecting the LCA for 3-way merge.
I'd like to build a decentralised collaborative web application, as scalable
as it gets. (I expect a lot of traffic)
I also need to only check out parts of the tree. (many SCMs can't do that)
Git, with its speed, seems well-suited to the task.
Merging will be uncommon in the workload, so can be slow, but shouldn't break
or present weird conflicts to the users.
Unless the accidental case starts to dominate - then I'll have a problem.
Sorry for spam and cutting out major questions, then answering at the end of
the post.
> Btw. I'm assuming you're aware you'll have to GPL this app of yours,
> since git is GPL and you'll be using the git produce in a way that makes
> it vital to your app.
It will be, but not because of git (it's execve()ing it), but rather because
of the principle.
Intermediate results will probably be:
- a good Python object interface to git
- another porcelain, portable, coded in Python
- maybe a new merge strategy
- later yet another porcelain, written in C
--
GPG Key id: 0xD1F10BA2
Fingerprint: 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2
AstralStorm
[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: Errors GITtifying GCC and Binutils
From: Linus Torvalds @ 2006-03-23 1:28 UTC (permalink / raw)
To: Jan-Benedict Glaw; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0603221607580.26286@g5.osdl.org>
On Wed, 22 Mar 2006, Linus Torvalds wrote:
>
> This one-liner to cvsps.c seems to make sure we have an ancestor branch
> for that "gdb-4.18-branch" branch, at least according to the cvsps output.
The "git cvsimport" is still running, but at least it seems to be happily
running further past the point it broke earlier.
Will send the patch over to David Mansfield.
Linus
^ permalink raw reply
* Fix branch ancestry calculation
From: Linus Torvalds @ 2006-03-23 1:29 UTC (permalink / raw)
To: David Mansfield; +Cc: Git Mailing List
Some branches don't get any ancestors at all, because their ancestor gets
a "dotcount" value of 0, and are thus not considered any better than not
having any ancestor. That's obviously wrong. Even a zero-dot-count
ancestor is better than having none at all.
This fixes the issue by making not having an ancestor branch have a
goodness value of -1, avoiding the problem (because even a zero dot-count
will be considered better).
Alternatively, the special-case for the "1.1.1.1" revision should be
removed (or made to imply a dot-count of 1).
Finally, I suspect that dot-counting in general should ignore any final
".1" counts, ie "1.2.1.1" should count the same as "1.2.1", which should
count the same as "1.2", which has a dot-count of 1.
That would automatically make any "1.1.1.1.1...." sequence always count as
having a dot-count of 0.
I'll send suggestion that as a separate patch, but in the meantime, this
is a separate issue, and obviously a bug-fix.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
----
diff --git a/cvsps.c b/cvsps.c
--- a/cvsps.c
+++ b/cvsps.c
@@ -2599,7 +2599,7 @@ static void determine_branch_ancestor(Pa
* note: rev is the pre-commit revision, not the post-commit
*/
if (!head_ps->ancestor_branch)
- d1 = 0;
+ d1 = -1;
else if (strcmp(ps->branch, rev->branch) == 0)
continue;
else if (strcmp(head_ps->ancestor_branch, "HEAD") == 0)
^ 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