* Re: [PATCH] rev-list: add "--full-objects" flag.
From: Eric W. Biederman @ 2005-07-12 0:44 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.58.0507110928070.17536@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Mon, 11 Jul 2005, Eric W. Biederman wrote:
>>
>> I guess I was expecting to pull from one tree into another unrelated
>> tree. Getting a tree with two heads and then be able to merge them
>> together.
>
> You can do it, but you have to do it by hand. It's a valid operation, but
> it's not an operation I want people to do by mistake, so it's not
> something the trivial helper scripts help with.
>
> The way to do it by hand is to just use something stupid that doesn't
> understand what it's doing anyway, and just copy the files over. "cp -a"
> or "rsync" works fine. Then just do "git resolve" by hand. It's not very
> hard at all, but it's definitely something that should be a special case.
Ok. Only the dumb methods are allowed.
>> A couple of questions.
>>
>> 1) Does git-clone-script when packed copy the entire repository
>> or just take a couple of slices of the tree where you have
>> references?
>
> It only gets the objects needed for the references, nothing more.
>
> So if you only get one branch, it will leave the objects that are specific
> to other branches alone.
Hmm. As I recall reading the code it grabs everything that is
in .git/refs/*. So I would actually expect it to grab all of the
branches. My real question was different. With a clone it
appears to just get the objects used to compose a tree object,
but none of the history available by looking at the commit
parents is obtained. Not at all what I would expect for
an operation named clone.
Eric
^ permalink raw reply
* [PATCH] remove Obsoletes from cogito.spec.in
From: Chris Wright @ 2005-07-12 0:33 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
This is leftover from early naming, and is no longer relevant.
Signed-off-by: Chris Wright <chrisw@osdl.org>
---
diff --git a/cogito.spec.in b/cogito.spec.in
--- a/cogito.spec.in
+++ b/cogito.spec.in
@@ -7,7 +7,6 @@ License: GPL
Group: Development/Tools
URL: http://kernel.org/pub/software/scm/cogito/
Source: http://kernel.org/pub/software/scm/cogito/%{name}-%{version}.tar.gz
-Obsoletes: git
BuildRequires: zlib-devel, openssl-devel, curl-devel
BuildRoot: %{_tmppath}/%{name}-%{version}-root
Prereq: sh-utils, diffutils, rsync, rcs, mktemp >= 1.5
^ permalink raw reply
* Re: Cogito-0.12: problem with local clone
From: Petr Baudis @ 2005-07-12 0:32 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: git
In-Reply-To: <20050707230055.25D3B353A8B@atlas.denx.de>
Dear diary, on Fri, Jul 08, 2005 at 01:00:55AM CEST, I got a letter
where Wolfgang Denk <wd@denx.de> told me that...
> Hello,
Hello,
> I have problems with Cogito-0.12 when trying to clone a "local" tree:
sorry for the late reply.
> When I try to create a local clone I get lots of error messages:
Yes, Cogito did not handle cross-filesystem local pulls correctly.
Should be fixed now.
Thanks,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
<Espy> be careful, some twit might quote you out of context..
^ permalink raw reply
* Re: cogito clone, invalid cross-dev links
From: Petr Baudis @ 2005-07-12 0:25 UTC (permalink / raw)
To: Marc Singer; +Cc: git
In-Reply-To: <20050711204445.GA16191@buici.com>
Dear diary, on Mon, Jul 11, 2005 at 10:44:45PM CEST, I got a letter
where Marc Singer <elf@buici.com> told me that...
> It complained when I cloned across devices.
>
> `/git/cogito/.git/refs/tags/cogito-0.8' -> `.git/refs/tags/cogito-0.8'
> cp: cannot create link `.git/refs/tags/cogito-0.8': Invalid cross-device link
> `/git/cogito/.git/refs/tags/cogito-0.9' -> `.git/refs/tags/cogito-0.9'
> cp: cannot create link `.git/refs/tags/cogito-0.9': Invalid cross-device link
>
> and so on. Is this a problem?
Small problem, yes - fixed now. Thanks.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
<Espy> be careful, some twit might quote you out of context..
^ permalink raw reply
* Re: arch 2.0 first source available (git related)
From: Thomas Lord @ 2005-07-12 0:05 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050711233150.GB5981@pasky.ji.cz>
On Tue, 2005-07-12 at 01:31 +0200, Petr Baudis wrote:
> But if the depth will be less than that, won't the user end up with some
> (plenty) of the objects duplicated?
Some, yes, many, no. It's pretty easy to tune how many, afaict.
-t
^ permalink raw reply
* Re: Trial git RPM's..
From: Horst von Brand @ 2005-07-11 20:11 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Eric W. Biederman, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0507110958400.17536@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> wrote:
> On Mon, 11 Jul 2005, Eric W. Biederman wrote:
> > A couple of pieces. The dist target has assumes git-tar-tree is in the
> > path. Making it so you have to have git installed to build the rpm.
> Yes. Maybe we could relax that requirement by using "./git-tar-tree" or
> something? That still requires that you have _built_ git to do the rpm,
> but at least you won't have had to install it.
I don't see a problem here. Sure, you need git to build git, so place it in
Build-requires: Need to install the binary to build the next from source,
that's all. Just like gcc ;-)
[...]
> > The man pages are not built. The build dependencies do not call out
> > the tools necessary to build the man pages.
> Most people don't have asciidoc, and I'm not sure we want to require it.
> Maybe we could have a separate "make man-rpm" target for that?
Would have to be a requirement for building anyway. There is a (not really
nice) SRPM at <http://www.pvv.ntnu.no/~terjeros/rpms/asciidoc/>. Will see
to clean it up.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply
* Re: [PATCH 3/6] git-gnu-progs-Makefile: git Makefile update
From: Linus Torvalds @ 2005-07-11 20:00 UTC (permalink / raw)
To: Bryan Larsen; +Cc: Junio C Hamano, bryan.larsen, pasky, git
In-Reply-To: <42D2CBA2.8060705@yahoo.com>
On Mon, 11 Jul 2005, Bryan Larsen wrote:
>
> >
> > Most everything includes git-sh-setup-script anyway by now.
> >
> > However, what are the features that break the default apple tools anyway?
> > Maybe we should avoid using them? OSX clearly comes with "cp" and "xargs"
> > regardless, what are the flags that don't work with their cruddy versions?
>
> xargs -r, cp -l, cp -u, cp -a. Git uses the first 2, cogito uses all 4.
I think we can replace "xargs -r" with just plain "xargs". It results in
an empty "rm -f", but hey, that's ok. If some broken "rm" complains about
that (GNU rm doesn't), you can always do
find .. | xargs rm -f dummy-file.o
which makes sure that we have a dummy argument even for an empty list..
> Last night, I couldn't think of alternatives to these, but I obviously
> didn't try very hard. xargs -r can probably happen via a temporary file
> and cp -u can probably be simulated using rsync.
I don't see a good alternative for "cp -l".
I also don't see why, if OS-X already _does_ include the GNU tools, they
couldn't be under /opt/fsf/bin or something like that, and then you could
just do
PATH=/opt/fsf/bin:$PATH
and be done with it.
Grumble.
Linus
^ permalink raw reply
* Re: [PATCH 0/2] Support for packs in HTTP
From: Daniel Barkalow @ 2005-07-11 20:03 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Petr Baudis, git
In-Reply-To: <Pine.LNX.4.58.0507111040251.17536@g5.osdl.org>
On Mon, 11 Jul 2005, Linus Torvalds wrote:
>
>
> On Mon, 11 Jul 2005, Daniel Barkalow wrote:
> > On Sun, 10 Jul 2005, Linus Torvalds wrote:
> >
> > >
> > > You really _mustn't_ try to create the pack directly to the
> > > $GIT_DIR/objects/pack subdirectory - that would make git itself start
> > > possibly using that pack before the index is all done, and that would be
> > > just wrong and nasty.
> > >
> > > So you really should _always_ generate the pack somewhere else, and then
> > > move it (pack file first, index file second).
> >
> > It's currently fine ignoring index files without corresponding
> > pack files (sha1_file.c, line 470).
>
> That doesn't help.
Well, it means that the order you move them doesn't matter, because it
will ignore the pair if either hasn't been moved.
> Redgardless of which order you write them (and you _will_ write the
> pack-file first), you'll find that at some point you have both files, but
> one or the other isn't fully written, ie they are unusable.
(Off topic: note that git-http-pull writes the _index_ first, because it
fetches it to determine if it should fetch the pack)
> And yes, you can handle that by always checking the SHA1 of the files when
> you open them, but the fact is, you shouldn't need to, just to use it.
> Checking the SHA1 of the pack-file in particular is very expensive (since
> it's potentially a huge file, and you don't even want to read all of it).
IIRC, we check the size of the pack file and there are hashes around the
ends of the two files which have to match; but this is a die() check, not
an ignore check, so we just crash with a clear error message rather than
doing crazy stuff (like reading from beyond the end of the mmap).
> So that's what I decided the rule is: never ever have a partial file, and
> thus you can by definition use them immediately when you see both files.
>
> But that requires that you write them under another name than the final
> one. And since you want that _anyway_ for other uses, you don't hide that
> inside "git-pack-objects", but you make it an exported interface.
We should never write anything under the final name, anyway, for just this
reason; we already use open/write/close/rename for objects, refs, and
cache (maybe not working directory files, though). I think we're actually
agreeing on this.
My position is that the temporary location should be something like
{final-name}.part, such that it doesn't match *.idx or *.pack beforehand
(so it doesn't look like a complete file that you might want to send to
someone) and it doesn't have to worry about EXDEV on the rename. Also, I
would ideally like to be able to resume an interrupted download, which
means that it would have to find the partial file in a predictable
location, given what it's supposed to contain.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH 3/6] git-gnu-progs-Makefile: git Makefile update
From: Junio C Hamano @ 2005-07-11 20:14 UTC (permalink / raw)
To: Bryan Larsen; +Cc: Linus Torvalds, bryan.larsen, pasky, git
In-Reply-To: <42D2CBA2.8060705@yahoo.com>
Bryan Larsen <bryanlarsen@yahoo.com> writes:
> Last night, I couldn't think of alternatives to these, but I obviously
> didn't try very hard. xargs -r can probably happen via a temporary
> file and cp -u can probably be simulated using rsync.
The only user of "xargs -r" in the Linus GIT is git-prune-script
which tries not to run "rm -f" with an empty argument list, like
this:
git-fsck-cache --cache --unreachable "$@" |
sed -ne '/unreachable /{
s/unreachable [^ ][^ ]* //
s|\(..\)|\1/|p
}' | {
cd "$GIT_OBJECT_DIRECTORY" || exit
xargs -r $dryrun rm -f
}
Not tested on a BSD, and it is probably as ugly as it can get,
but we could:
{
echo 'unreachable nosuch/file';
git-fsck-cache --cache --unreachable "$@"
} |
sed -ne '/unreachable /{
s/unreachable [^ ][^ ]* //
s|\(..\)|\1/|p
}' | {
cd "$GIT_OBJECT_DIRECTORY" || exit
xargs $dryrun rm -f
}
The only user of "cp -l" in the Linus GIT is git-clone-script
local optimization. I could revert it to the version that I
originally sent to the list, which uses cpio -pld, if your cpio
groks that flag.
I do not speak for Pasky, but to me "cp -u" sounds just like an
optimization, so maybe defining CP_U='cp -u' and detect missing
support at config time and falling back on the simple "cp" would
be an option?
GNU "cp -a" states that is the same as "-dpR" (never follow
symlinks, preserve link, mode, ownership, and timestamps), so
that can be rewritten as a shell function in cg-Xlib that is
called say cg_copy_tree, whose implementation runs two tar
processes piped together when "cp -a" is not available. Using a
tarpipe unconditionally is also fine.
^ permalink raw reply
* Re: [PATCH 3/6] git-gnu-progs-Makefile: git Makefile update
From: Bryan Larsen @ 2005-07-11 20:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Bryan Larsen, Linus Torvalds, pasky, git
In-Reply-To: <7virzhrtfy.fsf@assigned-by-dhcp.cox.net>
>
> The only user of "cp -l" in the Linus GIT is git-clone-script
> local optimization. I could revert it to the version that I
> originally sent to the list, which uses cpio -pld, if your cpio
> groks that flag.
Those options are in the man page, at least.
Bryan
^ permalink raw reply
* cogito clone, invalid cross-dev links
From: Marc Singer @ 2005-07-11 20:44 UTC (permalink / raw)
To: git
It complained when I cloned across devices.
`/git/cogito/.git/refs/tags/cogito-0.8' -> `.git/refs/tags/cogito-0.8'
cp: cannot create link `.git/refs/tags/cogito-0.8': Invalid cross-device link
`/git/cogito/.git/refs/tags/cogito-0.9' -> `.git/refs/tags/cogito-0.9'
cp: cannot create link `.git/refs/tags/cogito-0.9': Invalid cross-device link
and so on. Is this a problem?
^ permalink raw reply
* Re: Bootstrapping into git, commit gripes at me
From: Linus Torvalds @ 2005-07-11 23:45 UTC (permalink / raw)
To: Marc Singer; +Cc: git
In-Reply-To: <20050711222046.GA21376@buici.com>
On Mon, 11 Jul 2005, Marc Singer wrote:
>
> I picked 2.6.12
>
> # git checkout -f v2.6.12
>
> applied the patch and was greeted with an error about being unable to
> commit telling me that I LONG_HEX_NUMBER is not a valid commit object.
> Isn't 2.6.12 later than 2.6.12-rcX?
Yes.
However, that's not how "git checkout" ends up working, which is probably
(almost certainly) a misfeature of git checkout. In particular, when you
use a tag to checkout something, it will checkout the _state_ at that
point (ie v2.6.12), but it won't have reset your HEAD to point to it.
And your earlier adventures made your HEAD be something that isn't a
commit (although I quite frankly don't know quite how you succeeded at
that: "git checkout" should refuse to write a HEAD unless you check out a
specific branch, and all branch pointers are proper commit points).
Anyway, here's how you fix it right now, and I'll have to figure out how
to make a nice interface:
#
# Reset the "master" branch to v2.6.12
#
git-rev-list --max-count=1 v2.6.12 > .git/refs/heads/master
#
# Switch to the master branch
#
git checkout -f master
which should get you to be at a known point (which is v2.6.12).
Linus
^ permalink raw reply
* Re: [RFC] Design for http-pull on repo with packs
From: Junio C Hamano @ 2005-07-11 23:30 UTC (permalink / raw)
To: Dan Holmsand; +Cc: Daniel Barkalow, torvalds, git
In-Reply-To: <42D2960E.3050008@gmail.com>
Dan Holmsand <holmsand@gmail.com> writes:
> I did a little experiment. I cloned Linus' current tree, and git
> repacked everything (that's 63M + 3.3M worth of pack files). Then I
> got something like 25 or so of Jeff's branches. That's 6.9M of object
> files, and 1.4M packed. Total size: 70M for the entire
> .git/objects/pack directory.
>
> Repacking all of that to a single pack file gives, somewhat
> surprisingly, a pack size of 62M (+ 1.3M index). In other words, the
> cost of getting all those branches, and all of the new stuff from
> Linus, turns out to be *negative* (probably due to some strange
> deltification coincidence).
We do _not_ want to optimize for initial slurps into empty
repositories. Quite the opposite. We want to optimize for
allowing quick updates of reasonably up-to-date developer repos.
If initial slurps are _also_ efficient then that is an added
bonus; that is something the baseline big pack (60M Linus pack)
would give us already. So repacking everything into a single
pack nightly is _not_ what we want to do, even though that would
give the maximum compression ;-). I know you understand this,
but just stating the second of the above paragraphs would give
casual readers a wrong impression.
> I think that this shows that (at least in this case), having many
> branches isn't particularly wasteful (1.4M in this case with one
> incremental pack).
> And that fewer packs beats many packs quite handily.
You are correct. For somebody like Jeff, having the Linus
baseline pack with one pack of all of his head (incremental that
excludes what is already in the Linus baseline pack) would help
pullers.
> The big problem, however, comes when Jeff (or anyone else) decides to
> repack. Then, if you fetch both his repo and Linus', you might end up
> with several really big pack files, that mostly overlap. That could
> easily mean storing most objects many times, if you don't do some
> smart selective un/repacking when fetching.
Indeed. Overlapping packs is a possibility, but my gut feeling
is that it would not be too bad, if things are arranged so that
packs are expanded-and-then-repacked _very_ rarely if ever.
Instead, at least for your public repository, if you only repack
incrementally I think you would be OK.
^ permalink raw reply
* Re: arch 2.0 first source available (git related)
From: Petr Baudis @ 2005-07-11 23:31 UTC (permalink / raw)
To: Thomas Lord; +Cc: git
In-Reply-To: <1121117816.16511.5.camel@dev1.seyza.com>
Dear diary, on Mon, Jul 11, 2005 at 11:36:56PM CEST, I got a letter
where Thomas Lord <lord@emf.net> told me that...
> On Mon, 2005-07-11 at 21:39 +0200, Petr Baudis wrote:
> > Dear diary, on Sat, Jul 09, 2005 at 04:20:13PM CEST, I got a letter
> > where Thomas Lord <lord@emf.net> told me that...
> > > The prereq graph is, indeed, an improvement.
> > ..snip..
>
> > But object retrieval can be potentially as much as linear to the depth
> > of the prereq graph, right?
>
> Potentially but not, by far, in the common case.
>
> Moreover, that depth is an arbitrary parameter which user's can
> freely vary -- that's part of the point.
But if the depth will be less than that, won't the user end up with some
(plenty) of the objects duplicated?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
<Espy> be careful, some twit might quote you out of context..
^ permalink raw reply
* Re: Bootstrapping into git, commit gripes at me
From: Junio C Hamano @ 2005-07-11 23:15 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Marc Singer, git
In-Reply-To: <7vll4dndwu.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
>
> - git-commit-tree says check_valid("commit") and barfs.
>
> My current preference is to keep .git/refs/heads tag free. At
> least, I do not think we should ever write non commits to
> .git/*_HEAD.
>
> What do you think? An alternative would be to allow tags
> (recursively) pointing at a commit as a commit parent, but I do
> not think we would want to go that route.
Or, just dereferencing tags for commit parents in commit-tree
would be fine as well.
------------
Dereference tags given as commit-tree -p parameters.
Marc Singer noticed that when he has a tag instead of a commit
in his .git/HEAD (this happens after git checkout -f <tag>), git
commit barfs. This patch makes commit-tree dereference tags
like everybody else does.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
cd /opt/packrat/playpen/public/in-place/git/git.junio/
jit-diff
# - master: [PATCH] git-cvsimport-script: add "import only" option
# + (working tree)
diff --git a/commit-tree.c b/commit-tree.c
--- a/commit-tree.c
+++ b/commit-tree.c
@@ -8,6 +8,7 @@
#include <pwd.h>
#include <time.h>
#include <ctype.h>
+#include "commit.h"
#define BLOCKING (1ul << 14)
@@ -133,10 +134,14 @@ int main(int argc, char **argv)
check_valid(tree_sha1, "tree");
for (i = 2; i < argc; i += 2) {
char *a, *b;
+ struct commit *commit;
a = argv[i]; b = argv[i+1];
if (!b || strcmp(a, "-p") || get_sha1(b, parent_sha1[parents]))
usage(commit_tree_usage);
- check_valid(parent_sha1[parents], "commit");
+ commit = lookup_commit_reference(parent_sha1[parents]);
+ if (!commit)
+ usage(commit_tree_usage);
+ memcpy(parent_sha1[parents], commit->object.sha1, 20);
if (new_parent(parents))
parents++;
}
Compilation finished at Mon Jul 11 16:12:36
^ permalink raw reply
* Re: Bootstrapping into git, commit gripes at me
From: Junio C Hamano @ 2005-07-11 23:03 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Marc Singer, git
In-Reply-To: <20050711222046.GA21376@buici.com>
Marc Singer <elf@buici.com> writes:
> I picked 2.6.12
>
> # git checkout -f v2.6.12
>
> applied the patch and was greeted with an error about being unable to
> commit telling me that I LONG_HEX_NUMBER is not a valid commit object.
> Isn't 2.6.12 later than 2.6.12-rcX?
Aha. Marc is not doing anything wrong --- he is doing as he is
told.
Linus, there is a bad interaction between tag objects and
commits right now. For example:
- we allow git-checkout-script with a tag; I think we store the tag
object without dereferencing in .git/HEAD;
- git-commit-tree says check_valid("commit") and barfs.
I think other things are covered already and the above two are
the only remaining major ones. The merge-base command dereferences tags
and produces a commit as its result. The rev-list command also
derefs tags, so log and whatchanged would work sensibly.
My current preference is to keep .git/refs/heads tag free. At
least, I do not think we should ever write non commits to
.git/*_HEAD.
What do you think? An alternative would be to allow tags
(recursively) pointing at a commit as a commit parent, but I do
not think we would want to go that route.
^ permalink raw reply
* Re: git clone rsync:... ?
From: Marc Singer @ 2005-07-11 22:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwtnxnf5m.fsf@assigned-by-dhcp.cox.net>
On Mon, Jul 11, 2005 at 03:36:53PM -0700, Junio C Hamano wrote:
> Marc Singer <elf@buici.com> writes:
>
> > Looks like something's borked.
>
> Cogito I slurped about half hour ago has a quite different
> git-clone-script from your 4-line version. It is not surprising
> "git clone -l" would not work with it ;-).
>
> I just checked. Are you using Cogito 0.12 by any chance?
I pulled cogito from the repo.
> Unfortunately it is ancient in this area. Selected diffstat
> between 0.12 and Pasky head I think relevant is this:
>
> git-clone-script | 97 ++++
OK. Let's take another step backward. There are lots of changes
being made to all of these tools. Where should I be getting my git
programs so that I've got a good chance that they'll work. Jeff's
instructions, I believe, are already out-of-date.
^ permalink raw reply
* Re: Bootstrapping into git, commit gripes at me
From: Marc Singer @ 2005-07-11 22:20 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0507081842550.17536@g5.osdl.org>
On Fri, Jul 08, 2005 at 06:43:54PM -0700, Linus Torvalds wrote:
>
>
> On Fri, 8 Jul 2005, Marc Singer wrote:
> >
> > In working through a usage example on my way to producing bonafide
> > patches, I've found that commit is complaining. Here's what I've done.
> >
> > o Fetched and built cogito-0.12
> > o Fetched (rsync) Linus' tree
> > o Created a working directory, linux-2.6
> > o linked .git in the working directory to the .git directory fetched
> > from the net.
> > o # git checkout -f v2.6.11
>
> This won't work.
>
> v2.6.11 isn't a commit, it's a tree, and things will go downhill from
> there.
>
> Can you base it on 2.6.12-rc2 or later? That's the earliest with some real
> git history.
I picked 2.6.12
# git checkout -f v2.6.12
applied the patch and was greeted with an error about being unable to
commit telling me that I LONG_HEX_NUMBER is not a valid commit object.
Isn't 2.6.12 later than 2.6.12-rcX?
^ permalink raw reply
* Re: git clone rsync:... ?
From: Junio C Hamano @ 2005-07-11 22:36 UTC (permalink / raw)
To: Marc Singer; +Cc: git
In-Reply-To: <20050711222112.GA21248@buici.com>
Marc Singer <elf@buici.com> writes:
> Looks like something's borked.
Cogito I slurped about half hour ago has a quite different
git-clone-script from your 4-line version. It is not surprising
"git clone -l" would not work with it ;-).
I just checked. Are you using Cogito 0.12 by any chance?
Unfortunately it is ancient in this area. Selected diffstat
between 0.12 and Pasky head I think relevant is this:
git-clone-script | 97 ++++
^ permalink raw reply
* Re: git clone rsync:... ?
From: Marc Singer @ 2005-07-11 22:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4qb1ouwk.fsf@assigned-by-dhcp.cox.net>
On Mon, Jul 11, 2005 at 03:11:23PM -0700, Junio C Hamano wrote:
> Marc Singer <elf@buici.com> writes:
>
> > elf@florence /git > git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6
> > defaulting to local storage area
> > ssh: rsync: Name or service not known
> > fatal: unexpected EOF
>
> Hmph. "git clone rsync://rsync.kernel.org/pub/scm/git/git.git git.git"
> seems to work so does the exact command you show above. Is it
> possible that you are running git-clone-script from an older Git?
What I've been doing is pulling the cogito source, this time directly
from the net accessible repo, building it, and then copying the
binaries to a special directory I added to my path
elf@florence ~...git/bin > cat git-clone-script
#!/bin/sh
repo="$1"
dir="$2"
mkdir "$dir" && cd "$dir" && git-init-db && git-clone-pack "$repo"
What more could I need?
>
> > Moreover, I'd like to be able to
> > keep one repo that is just pulling from the net and then clone it for
> > different working directories.
>
> That is a sane thing to ask. Assuming you have solved the above
> problem:
>
> $ ls
> linux-2.6
> $ git clone -l linux-2.6 linux-ms
> $ git clone -l linux-2.6 linux-ms-net
> $ git clone -l linux-2.6 linux-ms-ide
> $ git clone -l linux-2.6 linux-ms-usb
>
> would make local clones of vanilla linux-2.6 repo you locally
> have ("-l" knows to use hardlinks when possible).
That, too, has been failing. I think for some different reason.
elf@florence ~/z/embedded > git clone -l linux-2.6 linux-2.6-cloned
mkdir: cannot create directory `linux-2.6': File exists
Looks like something's borked.
^ permalink raw reply
* Re: git clone rsync:... ?
From: Junio C Hamano @ 2005-07-11 22:11 UTC (permalink / raw)
To: Marc Singer; +Cc: git
In-Reply-To: <20050711213050.GA18693@buici.com>
Marc Singer <elf@buici.com> writes:
> elf@florence /git > git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6
> defaulting to local storage area
> ssh: rsync: Name or service not known
> fatal: unexpected EOF
Hmph. "git clone rsync://rsync.kernel.org/pub/scm/git/git.git git.git"
seems to work so does the exact command you show above. Is it
possible that you are running git-clone-script from an older Git?
> Moreover, I'd like to be able to
> keep one repo that is just pulling from the net and then clone it for
> different working directories.
That is a sane thing to ask. Assuming you have solved the above
problem:
$ ls
linux-2.6
$ git clone -l linux-2.6 linux-ms
$ git clone -l linux-2.6 linux-ms-net
$ git clone -l linux-2.6 linux-ms-ide
$ git clone -l linux-2.6 linux-ms-usb
would make local clones of vanilla linux-2.6 repo you locally
have ("-l" knows to use hardlinks when possible).
^ permalink raw reply
* Re: [PATCH 3/6] git-gnu-progs-Makefile: git Makefile update
From: Junio C Hamano @ 2005-07-11 21:59 UTC (permalink / raw)
To: Bryan Larsen; +Cc: Linus Torvalds, bryan.larsen, pasky, git
In-Reply-To: <42D2E47E.8060602@yahoo.com>
Bryan Larsen <bryanlarsen@yahoo.com> writes:
> For the record, "${XARGS} -0r" may be uglier than "xargs -0r", but
> replacing it with several lines of shell magic is a loss.
OK, OK, the one I suggested for xargs was _U_G_L_Y_.
The one Linus suggested looks to me the cleanest. That is, to
give an extra parameter upfront to the command run by xargs. My
favorite trick is like this:
git-fsck-cache --cache --unreachable "$@" |
sed -ne '/unreachable /{
s/unreachable [^ ][^ ]* //
s|\(..\)|\1/|p
}' | {
cd "$GIT_OBJECT_DIRECTORY" || exit
- xargs -r $dryrun rm -f
+ xargs $dryrun rm -f ""
}
Dry-run would say:
rm -f 00/012345...
rm -f 01/234567...
without visual distraction of having printable phoney names, or
just (with an invisible trailing space):
rm -f
During a real run, "rm -f" would not complain "cannot remove `':
Is a directory", either.
^ permalink raw reply
* Re: Trial git RPM's..
From: Chris Wright @ 2005-07-11 21:03 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Eric W. Biederman, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0507110958400.17536@g5.osdl.org>
* Linus Torvalds (torvalds@osdl.org) wrote:
> On Mon, 11 Jul 2005, Eric W. Biederman wrote:
> >
> > A couple of pieces. The dist target has assumes git-tar-tree is in the
> > path. Making it so you have to have git installed to build the rpm.
>
> Yes. Maybe we could relax that requirement by using "./git-tar-tree" or
> something? That still requires that you have _built_ git to do the rpm,
> but at least you won't have had to install it.
>
> Does that fit the rpm build process? Or does an rpm build make something
> like that really inconvenient? I don't know, patches welcome.
No, that could be done. It's not the rpmbuild at that point, it's just
prepping to do the rpmbuild. It's only an issue for those that are trying
to build an rpm directly from the git source and who've never installed
git before. Doesn't seem necessary to me, I'm not that fond of it (will
even slightly slow down make dist process if it's done from a clean,
i.e. make clean, dir), but hey...the trivial patch below does this.
> > And it does not pass my torture test of building rpm's on debian,
> > but that is not a huge problem.
>
> Ok, why is debian problematic? Is there some missing dependency or
> something? I really haven't ever done an rpm, and the git rpm target was
> all done by Chris Wright, so I don't have any clue at all. Again, patches
> welcome.
Heh debian rpm build...I missed that bit in Eric's message. Eric, care
to give details?
thanks,
-chris
--
Use git-tar-tree directly from git source during make dist. This
handles bootstrap issue with git not being installed.
Signed-off-by: Chris Wright <chrisw@osdl.org>
---
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -175,8 +175,8 @@ git.spec: git.spec.in
sed -e 's/@@VERSION@@/$(GIT_VERSION)/g' < $< > $@
GIT_TARNAME=git-$(GIT_VERSION)
-dist: git.spec
- git-tar-tree HEAD $(GIT_TARNAME) > $(GIT_TARNAME).tar
+dist: git.spec git-tar-tree
+ ./git-tar-tree HEAD $(GIT_TARNAME) > $(GIT_TARNAME).tar
@mkdir -p $(GIT_TARNAME)
@cp git.spec $(GIT_TARNAME)
tar rf $(GIT_TARNAME).tar $(GIT_TARNAME)/git.spec
^ permalink raw reply
* Re: [PATCH 2/2] Demo support for packs via HTTP
From: Darrin Thompson @ 2005-07-11 21:49 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git, Linus Torvalds, Petr Baudis
In-Reply-To: <Pine.LNX.4.21.0507101555271.30848-100000@iabervon.org>
On Sun, 2005-07-10 at 15:56 -0400, Daniel Barkalow wrote:
> + curl_easy_setopt(curl, CURLOPT_FILE, indexfile);
> + curl_easy_setopt(curl, CURLOPT_WRITEFUNCTION, fwrite);
> + curl_easy_setopt(curl, CURLOPT_URL, url);
I was hoping to send in a patch which would turn on user auth and turn
off ssl peer verification.
Your (preliminary obviously) patch puts curl handling in two places. Is
there a place were I can safely start working on adding the needed
setopts?
--
Darrin
^ permalink raw reply
* Re: arch 2.0 first source available (git related)
From: Thomas Lord @ 2005-07-11 21:36 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050711193944.GA5981@pasky.ji.cz>
On Mon, 2005-07-11 at 21:39 +0200, Petr Baudis wrote:
> Dear diary, on Sat, Jul 09, 2005 at 04:20:13PM CEST, I got a letter
> where Thomas Lord <lord@emf.net> told me that...
> > The prereq graph is, indeed, an improvement.
> ..snip..
> But object retrieval can be potentially as much as linear to the depth
> of the prereq graph, right?
Potentially but not, by far, in the common case.
Moreover, that depth is an arbitrary parameter which user's can
freely vary -- that's part of the point.
> I don't think any of the benefits you listed
> are worth the complication, and you can still do the reachability
> analysis pretty easily. (And I think it takes the same number of
> roundtrips when downloading from remote server?)
>
I don't agree that any complication is added. I know that
some complications are avoided with this approach.
-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