* 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: 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: 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: 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: 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-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: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: 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: 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: 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: 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: 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: [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: 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
* 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: 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
* 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: [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
* 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: 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: 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: Nick Hengeveld @ 2006-03-22 17:22 UTC (permalink / raw)
To: linux; +Cc: git
In-Reply-To: <20060322025921.1722.qmail@science.horizon.com>
On Tue, Mar 21, 2006 at 09:59:21PM -0500, linux@horizon.com wrote:
> If someone feels ambitious, you can detect this condition automatically
> by searching for a file that you know won't be there and seeing if you
> get a 404 response to that.
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.
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* Re: What's in git.git
From: Linus Torvalds @ 2006-03-22 16:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Randal L. Schwartz, git
In-Reply-To: <7v64m7av6o.fsf@assigned-by-dhcp.cox.net>
On Tue, 21 Mar 2006, Junio C Hamano wrote:
> merlyn@stonehenge.com (Randal L. Schwartz) writes:
>
> >>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
> >
> >>> But this wastes a commit. Is there any way to get an index that simply
> >>> includes the file from that other branch?
> >
> > Junio> $ git checkout master
> > Junio> $ git checkout next git-cvsimport.perl
> >
> > Yow. How simple is *that*? Thanks.
>
> There is one thing you would want to be careful about.
> This updates the index.
Yes. Btw, I've been bitten by that. I think it might be better to _not_
update the index when we check out a file from another branch than the one
we're on (or rather, we should perhaps update the index with the value
from the current branch every time, even though the _working_tree_ is
updated from another branch)
Linus
^ permalink raw reply
* Re: Cloning from sites with 404 overridden
From: Andreas Ericsson @ 2006-03-22 13:36 UTC (permalink / raw)
To: linux; +Cc: git
In-Reply-To: <20060322025921.1722.qmail@science.horizon.com>
linux@horizon.com wrote:
> If someone feels ambitious, you can detect this condition automatically
> by searching for a file that you know won't be there and seeing if you
> get a 404 response to that.
>
> To avoid punishing good servers, it would be nice to defer the test
> until reciving the first corrupted object.
>
> I'm not sure what the best "object that's not supposed to be there" is.
.git/objects/00/hoping-for-a-404-or-webadmin-should-fix
It has the right number of chars so it should fit in wherever a real
object name does but is obviously bogus anyways.
> It could just be a random hash, or would a malformed object file name
> be better?
A malformed object name is infinitely better. Otherwise we'd end up with
a wild guess that hits home some day, to much surprise and a bug-report
I wouldn't want to track. Not to mention the embarrassment when
explaining why that object-name was chosen.
>
> (As an aside, I suspect this is all caused by Microsoft's "friendly HTML
> error messages" invention.)
The body of the 404-page has absolutely nothing to do with it.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Errors GITtifying GCC and Binutils
From: Jan-Benedict Glaw @ 2006-03-22 13:33 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 5811 bytes --]
Hi!
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:
This is with GIT as of yesterday evening:
Binutils
~~~~~~~~
$ /home/jbglaw/bin/git cvsimport -v -d :pserver:anoncvs@sourceware.org:/cvs/src -C src src
[...]
Update gdb/testsuite/ChangeLog: 230971 bytes
Fetching gdb/testsuite/gdb.base/annota1.exp v 1.1.1.2
Update gdb/testsuite/gdb.base/annota1.exp: 14656 bytes
Fetching gdb/testsuite/gdb.base/annota2.cc v 1.1.1.3
Update gdb/testsuite/gdb.base/annota2.cc: 238 bytes
Fetching gdb/testsuite/gdb.base/annota2.exp v 1.1.1.2
Update gdb/testsuite/gdb.base/annota2.exp: 8639 bytes
Fetching sim/mcore/ChangeLog v 1.1.1.5
Update sim/mcore/ChangeLog: 1325 bytes
Fetching sim/mcore/interp.c v 1.1.1.5
Update sim/mcore/interp.c: 47368 bytes
Tree ID 640f8ff80e14257bc73fa0c3344504c4db960655
Parent ID ac9471abd876476724dc0205272b0565c18b1a7c
Committed patch 102 (SNAPSHOT 1999-05-25 18:00:33)
Commit ID 5847cc095ce0445eb6bf9df1203ccdad35f501fe
Created tag 'gdb-1999-05-25' on 'SNAPSHOT'
Switching from SNAPSHOT to origin
Fetching bfd/ChangeLog v 1.19
Update bfd/ChangeLog: 118751 bytes
Fetching bfd/elf32-arm.h v 1.4
Update bfd/elf32-arm.h: 90491 bytes
Tree ID 5100b5c49ef78e1027b476f4dbdebeca0b01f113
Parent ID 8d35c43246f8d9693203ef6a87aabf378593bceb
Committed patch 103 (origin 1999-05-26 08:27:37)
Commit ID bb18137d43506ccc7f78da63b18d9f6b6749264d
Fetching include/opcode/ChangeLog v 1.4
Update include/opcode/ChangeLog: 63395 bytes
Fetching include/opcode/hppa.h v 1.2
Update include/opcode/hppa.h: 23271 bytes
Tree ID 7b211af5cb99cbe307d02d72c1e144f3c1aac7e9
Parent ID bb18137d43506ccc7f78da63b18d9f6b6749264d
Committed patch 104 (origin 1999-05-26 16:04:10)
Commit ID 4da3ef4d311fc62a1a0bba8b680595ad824a7e2c
Fetching ld/ChangeLog v 1.11
Update ld/ChangeLog: 328968 bytes
Fetching ld/emulparams/armelf_oabi.sh v 1.2
Update ld/emulparams/armelf_oabi.sh: 585 bytes
Tree ID fcc05a0f9c66693e5b26a5fb4821f6bbeadf4c31
Parent ID 4da3ef4d311fc62a1a0bba8b680595ad824a7e2c
Committed patch 105 (origin 1999-05-26 17:23:31)
Commit ID ddaaceeede7f9bb938188c4f72ddce420d08efad
Switching from origin to gdb-4_18-branch
usage: git-read-tree (<sha> | -m [--aggressive] [-u | -i] <sha1> [<sha2> [<sha3>]])
read-tree failed: 33024
$ /home/jbglaw/bin/git cvsimport -v -d :pserver:anoncvs@sourceware.org:/cvs/src -C src src
usage: git-read-tree (<sha> | -m [--aggressive] [-u | -i] <sha1> [<sha2> [<sha3>]])
read-tree failed: 33024
GCC
~~~
$ /home/jbglaw/bin/git svnimport -C gcc -v svn://gcc.gnu.org/svn/gcc
[...]
... 3930 trunk/gcc/combine.c ...
Tree ID 2af6a2f6e28835fec0aaf60d278e356d12d9ae5f
Merge parent branch: 587bbd00ea5b0f8c18d8ca58bbfcaa4b6b62ff92
Committed change 3930:/ 1993-03-30 20:37:29)
Commit ID 3ed4cebd349a2c98c7a06d6333b014bd4fe23d6d
Writing to refs/heads/origin
DONE: 3930 origin 3ed4cebd349a2c98c7a06d6333b014bd4fe23d6d
... 3931 trunk/gcc/config/mips/mips.h ...
Tree ID f173f836adf4d8efb42c180d7cd5a786a3acf361
Merge parent branch: 3ed4cebd349a2c98c7a06d6333b014bd4fe23d6d
Committed change 3931:/ 1993-03-30 21:50:50)
Commit ID 7c132f1464d27bd8198c51913b17a0534376e3e6
Writing to refs/heads/origin
DONE: 3931 origin 7c132f1464d27bd8198c51913b17a0534376e3e6
... 3932 trunk/gcc/config/pa/pa.md ...
Tree ID a88f5523f982dbac1334b78c47fd56a685640a46
Merge parent branch: 7c132f1464d27bd8198c51913b17a0534376e3e6
Committed change 3932:/ 1993-03-30 22:02:05)
Commit ID 9a8ddfa77f6735c8ba87ab98bc3ac7b056a09d96
Writing to refs/heads/origin
DONE: 3932 origin 9a8ddfa77f6735c8ba87ab98bc3ac7b056a09d96
... 3933 trunk/gcc/real.c ...
Tree ID 7d25a64013b301e0e575587a5adfd8b540b4c5a7
Merge parent branch: 9a8ddfa77f6735c8ba87ab98bc3ac7b056a09d96
Committed change 3933:/ 1993-03-31 05:30:24)
Commit ID 70cc7d27f3a4e5117df4e4d2f6e5a2aa4c4a89a6
Writing to refs/heads/origin
DONE: 3933 origin 70cc7d27f3a4e5117df4e4d2f6e5a2aa4c4a89a6
... 3934 trunk/gcc/real.h ...
Tree ID fce52e724f0f1543abd5bd430a11822c3977e803
Merge parent branch: 70cc7d27f3a4e5117df4e4d2f6e5a2aa4c4a89a6
Committed change 3934:/ 1993-03-31 05:39:37)
Commit ID f8dad6fb5af69122823800ca974e16d4f09906c2
Writing to refs/heads/origin
DONE: 3934 origin f8dad6fb5af69122823800ca974e16d4f09906c2
... 3935 trunk/gcc/Makefile.in ...
Tree ID 7c2cd41d922407ab1df47954fb82964ad7511328
Merge parent branch: f8dad6fb5af69122823800ca974e16d4f09906c2
Committed change 3935:/ 1993-03-31 05:41:37)
Commit ID eb99aa0ad37564c2071fe4b2f539fe072a72ad4c
Writing to refs/heads/origin
DONE: 3935 origin eb99aa0ad37564c2071fe4b2f539fe072a72ad4c
... 3936 trunk/gcc/c-lex.c ...
Tree ID 90547e4ef900e45f4354aa036f216a3bff93c8dd
Merge parent branch: eb99aa0ad37564c2071fe4b2f539fe072a72ad4c
Committed change 3936:/ 1993-03-31 05:44:03)
Commit ID ceff85145f8671fb2a9d826a761cedc2a507bd1e
Writing to refs/heads/origin
DONE: 3936 origin ceff85145f8671fb2a9d826a761cedc2a507bd1e
... 3937 trunk/gcc/final.c ...
Can't fork at /home/jbglaw/bin/git-svnimport line 379.
$ /home/jbglaw/bin/git svnimport -C gcc -v svn://gcc.gnu.org/svn/gcc
Use of uninitialized value in system at /home/jbglaw/bin/git-svnimport line 295.
usage: git-read-tree (<sha> | -m [--aggressive] [-u | -i] <sha1> [<sha2> [<sha3>]])
read-tree failed: 33024
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ 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