* Re: [PATCH] shared repository settings enhancement.
From: Linus Torvalds @ 2006-06-10 0:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Post, Mark K
In-Reply-To: <7vver9lu8g.fsf_-_@assigned-by-dhcp.cox.net>
On Fri, 9 Jun 2006, Junio C Hamano wrote:
>
> This lets you say:
>
> [core]
> sharedrepository = 075
I really think it's better to express this as some more traditional
number.
I had to think about what 075 meant, while saying
[core]
sharedrepository = 0644
just makes sense more or less automatically (and yes, for directories, the
read bit should obviously be expanded as an execute bit).
The difference is just that the latter is how you _usually_ express
permissions, so people are used to it.
And "being used to it" is what "ease of use" really all boils down to.
Linus
^ permalink raw reply
* Re: Figured out how to get Mozilla into git
From: Martin Langhoff @ 2006-06-10 1:14 UTC (permalink / raw)
To: Jon Smirl; +Cc: git
In-Reply-To: <46a038f90606082006t5c6a5623q4b9cf7b036dad1e5@mail.gmail.com>
On 6/9/06, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> mozilla.git$ du -sh .git/
> 2.0G .git/
Ok -- pushed the repository out to our mirror box. Try:
git-clone http://mirrors.catalyst.net.nz/pub/mozilla.git/
Now, good news. No, _very_ good news. As I was rsync'ing this out, and
looking at the repo, suddently something was odd. Apparently after a
git-repack -a -d OOMd on me, and I had posted this message, I re-ran
it.
[As it happens I have been running several imports of gentoo and moz
lately on thebox. It is entirely possible that cvsps or a stray
git-cvsimport was sitting on a whole lot of ram at the time]
Now I don't know how much memory or time this took, but it clearly
completed ok. And, it's now a single pack, weighting a grand total of
617MB
So my comments about OOM'ing were wrong apparently. Hey, if the whole
history is actually only 617MB, then initial checkouts are back to
something reasonable, I'd say.
cheers,
martin
^ permalink raw reply
* Re: Figured out how to get Mozilla into git
From: Martin Langhoff @ 2006-06-10 1:23 UTC (permalink / raw)
To: Jon Smirl; +Cc: Linus Torvalds, git
In-Reply-To: <9e4733910606091317p26d66579mdf93db293f93fb50@mail.gmail.com>
On 6/10/06, Jon Smirl <jonsmirl@gmail.com> wrote:
> The git tree that Martin got from cvsps is much smaller that the git
> tree I got from going to svn then to git. I don't why the trees are
> 700KB different, it may be different amounts of packing, or one of the
> conversion tools is losing something.
Don't read too much into that. Packing/repacking points make a _huge_
difference, and even if one of our trees is a bit corrupt, the
packsizes should be about the same.
(With the patches I sent you we _are_ choosing to ignore a few
branches that don't seem to make sense in cvsps output. These will
show up in the error output -- what I saw were very old, possibly
corrupt branches there, stuff I wouldn't shed a tear over, but it is
worth reviewing).
> I haven't come up with anything that is likely to result in Mozilla
> switching over to git. Right now it takes three days to convert the
> tree. The tree will have to be run in parallel for a while to convince
> everyone to switch. I don't have a solution to keeping it in sync in
> near real time (commits would still go to CVS). Most Mozilla
> developers are interested but the infrastructure needs some help.
Don't worry about the initial import time. Once you've done it, you
can run the incremental import (which will take a few minutes) even
hourly to keep 'in sync'.
> Martin has also brought up the problem with needing a partial clone so
> that everyone doesn't have to bring down the entire repository. A
> trunk checkout is 340MB and Martin's git tree is 2GB (mine 2.7GB). A
> kernel tree is only 680M.
Now that I have managed to repack the repo, it is indeed back in the
600M range. Actually, I just re-repacked, it took under a minute, and
it shrank down to 607MB.
Yay.
I'm sure that if you git-repack -a -d on a machine with plenty of
memory once or twice, we'll have matching packs.
cheers,
martin
^ permalink raw reply
* Re: Figured out how to get Mozilla into git
From: Linus Torvalds @ 2006-06-10 1:33 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Jon Smirl, git
In-Reply-To: <46a038f90606091814n1922bf25l94d913238b260296@mail.gmail.com>
On Sat, 10 Jun 2006, Martin Langhoff wrote:
>
> Now I don't know how much memory or time this took, but it clearly
> completed ok. And, it's now a single pack, weighting a grand total of
> 617MB
Ok, that's more than reasonable. That should be fairly easily mapped on a
32-bit architecture without any huge problems, even with some VM
fragmentation going on. It might be borderline (and you definitely want a
3:1 VM user:kernel split), but considering that the original CVS archive
was apparently 3GB, having a single 617M pack-file is still pretty damn
good. That's like 20% of the original, with all the obvious distribution
advantages.
Clearly this whole thing _does_ show that we could improve the process of
importing things from CVS a whole lot, and I assume your 617MB pack
doesn't have the nice name/email translations so it needs to be fixed up,
but it sounds like on the whole the core git design came through with
shining colors, even if we may want to polish things up a bit ;)
I'm downloading the thing right now.
Linus
^ permalink raw reply
* Re: [PATCH] shared repository settings enhancement.
From: Jakub Narebski @ 2006-06-10 1:38 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0606091743410.5498@g5.osdl.org>
Linus Torvalds wrote:
>
>
> On Fri, 9 Jun 2006, Junio C Hamano wrote:
>>
>> This lets you say:
>>
>> [core]
>> sharedrepository = 075
>
> I really think it's better to express this as some more traditional
> number.
>
> I had to think about what 075 meant, while saying
>
> [core]
> sharedrepository = 0644
Yet another solution would be to actually set umask.
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: Figured out how to get Mozilla into git
From: Linus Torvalds @ 2006-06-10 1:43 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Jon Smirl, git
In-Reply-To: <Pine.LNX.4.64.0606091825080.5498@g5.osdl.org>
On Fri, 9 Jun 2006, Linus Torvalds wrote:
>
> That's like 20% of the original, with all the obvious distribution
> advantages.
Btw, does anybody know roughly how much data a initial "cvs co" takes on
the mozilla repo? Git will obviously get the whole history, and that will
inevitably be bigger than getting a single check-out, but it's not
necessarily orders of magnitude bigger.
It could be that getting a whole git archive is not _that_ much more
expnsive than getting a single version, considering how well history
compresses (eg the kernel git arhive isn't orders of magnitude bigger than
a single compressed tar-ball of the sources).
At that point, it's probably a pretty usable alternative.
(Although, to be fair, we almost certainly have to improve "git-rev-list
--objects --all" performance on that thing, since that's going to
otherwise make it totally impossible to do initial clones using the native
git protocol, and make git look bad).
Linus
^ permalink raw reply
* Re: Figured out how to get Mozilla into git
From: Jon Smirl @ 2006-06-10 1:48 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Martin Langhoff, git
In-Reply-To: <Pine.LNX.4.64.0606091837040.5498@g5.osdl.org>
On 6/9/06, Linus Torvalds <torvalds@osdl.org> wrote:
>
>
> On Fri, 9 Jun 2006, Linus Torvalds wrote:
> >
> > That's like 20% of the original, with all the obvious distribution
> > advantages.
>
> Btw, does anybody know roughly how much data a initial "cvs co" takes on
> the mozilla repo? Git will obviously get the whole history, and that will
> inevitably be bigger than getting a single check-out, but it's not
> necessarily orders of magnitude bigger.
339MB for initial checkout
> It could be that getting a whole git archive is not _that_ much more
> expnsive than getting a single version, considering how well history
> compresses (eg the kernel git arhive isn't orders of magnitude bigger than
> a single compressed tar-ball of the sources).
>
> At that point, it's probably a pretty usable alternative.
>
> (Although, to be fair, we almost certainly have to improve "git-rev-list
> --objects --all" performance on that thing, since that's going to
> otherwise make it totally impossible to do initial clones using the native
> git protocol, and make git look bad).
>
> Linus
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Figured out how to get Mozilla into git
From: Linus Torvalds @ 2006-06-10 1:59 UTC (permalink / raw)
To: Jon Smirl; +Cc: Martin Langhoff, git
In-Reply-To: <9e4733910606091848r5fb4d565taabfc5198140daf2@mail.gmail.com>
On Fri, 9 Jun 2006, Jon Smirl wrote:
> >
> > Btw, does anybody know roughly how much data a initial "cvs co" takes on
> > the mozilla repo? Git will obviously get the whole history, and that will
> > inevitably be bigger than getting a single check-out, but it's not
> > necessarily orders of magnitude bigger.
>
> 339MB for initial checkout
And I think people run :pserver: with compression by default, so we're
likely talking about half that in actual download overhead, no?
So a git clone would be about (wild handwaving, don't look at all the
assumptions) four times as expensive - assuming we only look at a poor DSL
line as the expense - as an initial CVS co, but you'd get the _whole_
history. Which may or may not make up for it. For some people it will, for
others it won't.
Of course, to make up for some of the initial costs, I suspect that some
people who are used to "cvs update" taking 15 minutes to update two files,
it would be a serious relief to see the git kind of "300 objects in five
seconds" kinds of pulls.
Although I guess that's one of the CVS things that SVN improved on. At
least I'd hope so ;/
Linus
^ permalink raw reply
* [PATCH] Fix formatting of Documentation/git-clone.txt
From: Horst H. von Brand @ 2006-06-10 2:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Signed-off-by: Horst H. von Brand <vonbrand@inf.utfsm.cl>
---
Documentation/git-clone.txt | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index 7572e4b..a90521e 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -95,8 +95,8 @@ OPTIONS
defined default, typically `/usr/share/git-core/templates`.
--use-separate-remote::
- Save remotes heads under `$GIT_DIR/remotes/origin/' instead
- of `$GIT_DIR/refs/heads/'. Only the master branch is saved
+ Save remotes heads under `$GIT_DIR/remotes/origin/` instead
+ of `$GIT_DIR/refs/heads/`. Only the master branch is saved
in the latter.
<repository>::
--
1.4.0.rc2.g7612
^ permalink raw reply related
* Re: Figured out how to get Mozilla into git
From: Jon Smirl @ 2006-06-10 2:21 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Martin Langhoff, git
In-Reply-To: <Pine.LNX.4.64.0606091853180.5498@g5.osdl.org>
On 6/9/06, Linus Torvalds <torvalds@osdl.org> wrote:
>
>
> On Fri, 9 Jun 2006, Jon Smirl wrote:
> > >
> > > Btw, does anybody know roughly how much data a initial "cvs co" takes on
> > > the mozilla repo? Git will obviously get the whole history, and that will
> > > inevitably be bigger than getting a single check-out, but it's not
> > > necessarily orders of magnitude bigger.
> >
> > 339MB for initial checkout
>
> And I think people run :pserver: with compression by default, so we're
> likely talking about half that in actual download overhead, no?
>
> So a git clone would be about (wild handwaving, don't look at all the
> assumptions) four times as expensive - assuming we only look at a poor DSL
> line as the expense - as an initial CVS co, but you'd get the _whole_
> history. Which may or may not make up for it. For some people it will, for
> others it won't.
Could you clone the repo and delete changesets earlier than 2004? Then
I would clone the small repo and work with it. Later I decide I want
full history, can I pull from a full repository at that point and get
updated? That would need a flag to trigger it since I don't want full
history to come over if I am just getting updates from someone else's
tree that has a full history.
>
> Of course, to make up for some of the initial costs, I suspect that some
> people who are used to "cvs update" taking 15 minutes to update two files,
> it would be a serious relief to see the git kind of "300 objects in five
> seconds" kinds of pulls.
No more cvs diff taking four minutes to finish. I have to do that
every time I want to generate a 10 line patch. Diffs can run locally.
No more cvs update to replace files I deleted because I messed up
edits in them. And I can have local branches, yeah!
What are we going to do about the BEOS developers on Mozilla? There
are a couple more obscure OSes.
> Although I guess that's one of the CVS things that SVN improved on. At
> least I'd hope so ;/
>
> Linus
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Figured out how to get Mozilla into git
From: Jon Smirl @ 2006-06-10 2:30 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Martin Langhoff, git
In-Reply-To: <Pine.LNX.4.64.0606091853180.5498@g5.osdl.org>
On 6/9/06, Linus Torvalds <torvalds@osdl.org> wrote:
>
>
> On Fri, 9 Jun 2006, Jon Smirl wrote:
> > >
> > > Btw, does anybody know roughly how much data a initial "cvs co" takes on
> > > the mozilla repo? Git will obviously get the whole history, and that will
> > > inevitably be bigger than getting a single check-out, but it's not
> > > necessarily orders of magnitude bigger.
> >
> > 339MB for initial checkout
I ran the checkout through bzip and it is 36.4MB, 46.4MB with zip.
So the ratio may be 15 to 1 for the cvs co vs git
> And I think people run :pserver: with compression by default, so we're
> likely talking about half that in actual download overhead, no?
>
> So a git clone would be about (wild handwaving, don't look at all the
> assumptions) four times as expensive - assuming we only look at a poor DSL
> line as the expense - as an initial CVS co, but you'd get the _whole_
> history. Which may or may not make up for it. For some people it will, for
> others it won't.
>
> Of course, to make up for some of the initial costs, I suspect that some
> people who are used to "cvs update" taking 15 minutes to update two files,
> it would be a serious relief to see the git kind of "300 objects in five
> seconds" kinds of pulls.
>
> Although I guess that's one of the CVS things that SVN improved on. At
> least I'd hope so ;/
>
> Linus
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Figured out how to get Mozilla into git
From: Carl Worth @ 2006-06-10 2:34 UTC (permalink / raw)
To: Jon Smirl; +Cc: Linus Torvalds, Martin Langhoff, git
In-Reply-To: <9e4733910606091921o1d07826w8292dc22b1872345@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1121 bytes --]
On Fri, 9 Jun 2006 22:21:17 -0400, "Jon Smirl" wrote:
>
> Could you clone the repo and delete changesets earlier than 2004? Then
> I would clone the small repo and work with it. Later I decide I want
> full history, can I pull from a full repository at that point and get
> updated? That would need a flag to trigger it since I don't want full
> history to come over if I am just getting updates from someone else's
> tree that has a full history.
This is clearly a desirable feature, and has been requested by several
people (including myself) looking to switch some large-ish histories
from an existing system to git.
If you'd like to look through git archives for some discussion of the
issues that would be involved here, look for "shallow clone".
There's a related proposal termed "lazy clone" for one that would pull
down missing objects as needed over the network.
My impression is that both things will eventually be implemented.
There's certainly nothing fundamental in git that will prevent them,
(though there will be some interesting things to resolve as a real
patch for this stuff is explored).
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Figured out how to get Mozilla into git
From: Linus Torvalds @ 2006-06-10 3:01 UTC (permalink / raw)
To: Jon Smirl; +Cc: Martin Langhoff, git
In-Reply-To: <9e4733910606091921o1d07826w8292dc22b1872345@mail.gmail.com>
On Fri, 9 Jun 2006, Jon Smirl wrote:
>
> No more cvs diff taking four minutes to finish. I have to do that
> every time I want to generate a 10 line patch. Diffs can run locally.
> No more cvs update to replace files I deleted because I messed up
> edits in them. And I can have local branches, yeah!
More importantly, when the CVS server is down (can you say
"sourceforge"?), who cares?
> What are we going to do about the BEOS developers on Mozilla? There
> are a couple more obscure OSes.
Well, the git cvsserver exporter apparently works well enough...
Linus
^ permalink raw reply
* Re: Figured out how to get Mozilla into git
From: Linus Torvalds @ 2006-06-10 3:08 UTC (permalink / raw)
To: Carl Worth; +Cc: Jon Smirl, Martin Langhoff, git
In-Reply-To: <87y7w5lowc.wl%cworth@cworth.org>
On Fri, 9 Jun 2006, Carl Worth wrote:
> On Fri, 9 Jun 2006 22:21:17 -0400, "Jon Smirl" wrote:
> >
> > Could you clone the repo and delete changesets earlier than 2004? Then
> > I would clone the small repo and work with it. Later I decide I want
> > full history, can I pull from a full repository at that point and get
> > updated? That would need a flag to trigger it since I don't want full
> > history to come over if I am just getting updates from someone else's
> > tree that has a full history.
>
> This is clearly a desirable feature, and has been requested by several
> people (including myself) looking to switch some large-ish histories
> from an existing system to git.
The thing is, to some degree it's really fundamentally hard.
It's easy for a linear history. What you do for a linear history is to
just get the top commit, and the tree associated with it, and then you
cauterize the parent by just grafting it to go away. Boom. You're done.
The problems are that if the preceding history _wasn't_ linear (or, in
fact, _subsequent_ development refers to it by having branched off at an
earlier point), and you try to pull your updates, the other end (that
knows about all the history) will assume you have all the history that you
don't have, and will send you a pack assuming that.
Which won't even necessarily have all the tree/blob objects (it assumed
you already had them), but more annoyingly, the history won't be
cauterized, and you'll have dangling commits. Which you can cauterize by
hand, of course, but you literally _will_ have to get the objects and
cauterize the thing by hand.
You're right that it's not "fundamentally impossible" to do: the git
format certainly _allows_ it. But the git protocol handshake really does
end up optimizing away all the unnecessary work by knowing that the other
side will have all the shared history, so lacking the shared history will
mean that you're a bit screwed.
Using the http protocol actually works. It doesn't do any handshake: it
will just fetch objects from the other end as it needs them. The downside,
of course, is that it also doesn't understand packs, so if the source is
packed (and it pretty much _will_ be, for any big source), you're going to
end up getting it all _anyway_.
Linus
^ permalink raw reply
* Re: Figured out how to get Mozilla into git
From: Martin Langhoff @ 2006-06-10 3:41 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jon Smirl, git
In-Reply-To: <Pine.LNX.4.64.0606091853180.5498@g5.osdl.org>
On 6/10/06, Linus Torvalds <torvalds@osdl.org> wrote:
> On Fri, 9 Jun 2006, Jon Smirl wrote:
> > >
> > > Btw, does anybody know roughly how much data a initial "cvs co" takes on
> > > the mozilla repo? Git will obviously get the whole history, and that will
> > > inevitably be bigger than getting a single check-out, but it's not
> > > necessarily orders of magnitude bigger.
> >
> > 339MB for initial checkout
>
> And I think people run :pserver: with compression by default, so we're
> likely talking about half that in actual download overhead, no?
Yes, most people have -z3, and I agree with you, on paper it sounds
like the cost is 1/4 of a git clone.
However.
The CVS protocol is very chatty because the client _acts_ extremely
stupid. It says, ok, I got here an empty directory, and the server
walks the client through every little step. And all that chatter is
uncompressed cleartext under pserver.
So the per-file and per-directory overhead are significant. I can do a
cvs checkout via pserver:localhost but I don't know off-the-cuff how
to measure the traffic. Hints?
cheers,
martin
^ permalink raw reply
* Re: [PATCH] shared repository settings enhancement.
From: Junio C Hamano @ 2006-06-10 3:49 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0606091743410.5498@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Fri, 9 Jun 2006, Junio C Hamano wrote:
>>
>> This lets you say:
>>
>> [core]
>> sharedrepository = 075
>
> I really think it's better to express this as some more traditional
> number.
>
> I had to think about what 075 meant, while saying
>
> [core]
> sharedrepository = 0644
>
> just makes sense more or less automatically (and yes, for directories, the
> read bit should obviously be expanded as an execute bit).
Or probably use the umask notation, 007 for traditional shared
repositories and 002 for gitweb exported ones. With your
notation, people would start wondering what the distinction
between 0755, 0644, and even 0254 is (there isn't any).
Having said that, I do not think the distinction is that
important; I would rather make the core.sharedrepository = true
to mean an equivalent of "chmod go+rX" (it does "chmod g+rX"
currently).
^ permalink raw reply
* Re: Figured out how to get Mozilla into git
From: Junio C Hamano @ 2006-06-10 3:55 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90606092041neadcc54n2acb6272d1f71de7@mail.gmail.com>
"Martin Langhoff" <martin.langhoff@gmail.com> writes:
> Yes, most people have -z3, and I agree with you, on paper it sounds
> like the cost is 1/4 of a git clone.
>
> However.
>
> The CVS protocol is very chatty because the client _acts_ extremely
> stupid. It says, ok, I got here an empty directory, and the server
> walks the client through every little step. And all that chatter is
> uncompressed cleartext under pserver.
>
> So the per-file and per-directory overhead are significant. I can do a
> cvs checkout via pserver:localhost but I don't know off-the-cuff how
> to measure the traffic. Hints?
If you have an otherwise unused interface, you can look at
ifconfig output and see RX/TX bytes? But that sounds very
crude.
Running it through a proxy perhaps?
^ permalink raw reply
* Re: Figured out how to get Mozilla into git
From: Linus Torvalds @ 2006-06-10 4:02 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Jon Smirl, git
In-Reply-To: <46a038f90606092041neadcc54n2acb6272d1f71de7@mail.gmail.com>
On Sat, 10 Jun 2006, Martin Langhoff wrote:
>
> So the per-file and per-directory overhead are significant. I can do a
> cvs checkout via pserver:localhost but I don't know off-the-cuff how
> to measure the traffic. Hints?
Over localhost, you won't see the biggest issue, which is just latency.
The git protocol should be absolutely <i>wonderful</i> with bad latency,
because once the early bakc-and-forth on what each side has is done,
there's no synchronization any more - it's all just streaming, with
full-frame TCP.
If :pserver: does per-file "hey, what are you up to" kind of
syncronization, the big killer would be the latency from one end to the
other, regardless of any throughput.
You can try to approximate the latency by just looking at the number of
packets, and using a large MTU (and on localhost, the MTU will be pretty
large - roughly 16kB. Don't count packet size at all, just count how many
packets each protocol sends (both ways), ignoring packets that are just
empty ACK's.
I don't know how to build a tcpdump expression for "TCP packet with an
empty payload", but I bet it's possible.
[ And I won't guarantee that it's a wonderful approximation for "network
cost", but I think it's potentially a reasonably good one. It's totally
realistic to equate 32kB of _streaming_ data (two packets flowing in
one direction with no synchronization) with just a single byte of data
going back-and-forth synchronously ]
Linus
^ permalink raw reply
* Re: [PATCH] shared repository settings enhancement.
From: Linus Torvalds @ 2006-06-10 4:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8xo5lleo.fsf@assigned-by-dhcp.cox.net>
On Fri, 9 Jun 2006, Junio C Hamano wrote:
>
> Having said that, I do not think the distinction is that
> important; I would rather make the core.sharedrepository = true
> to mean an equivalent of "chmod go+rX" (it does "chmod g+rX"
> currently).
How about making it be
[core]
sharedrepository = {umask | user | group | everybody}
and allow the old boolean expression syntax to mean "0/false means umask,
1/true means group".
So you'd have:
- umask/0/false means "use 0777 permissions with default umask"
- user means "use 0500 permissions"
- group means "use 0550 permissions"
- everybody means "use 0555 permissions"
(where "5" is r-x, and only for directories, and obviously degenerates to
just "4" aka r-- for regular files).
That sounds really pretty self-explanatory and obvious, wouldn't you say?
Linus
^ permalink raw reply
* Re: Figured out how to get Mozilla into git
From: Linus Torvalds @ 2006-06-10 4:11 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Jon Smirl, git
In-Reply-To: <Pine.LNX.4.64.0606092043460.5498@g5.osdl.org>
On Fri, 9 Jun 2006, Linus Torvalds wrote:
>
> You can try to approximate the latency by just looking at the number of
> packets, and using a large MTU (and on localhost, the MTU will be pretty
> large - roughly 16kB. Don't count packet size at all, just count how many
> packets each protocol sends (both ways), ignoring packets that are just
> empty ACK's.
Btw, the reason you should ignore empty acks is that they happen when you
have a nice streaming one-way thing, because the TCP rules say that you
should send an ACK every two full packets minimum, even if you have
nothing to say.
So empty acks really approximate to "streaming data", while packets with
payload _could_ obviously mean "nice streaming data going both ways", but
almost always end up being synchronization discussion of some sort.
Linus
^ permalink raw reply
* Re: [PATCH] shared repository settings enhancement.
From: Junio C Hamano @ 2006-06-10 4:19 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0606092103170.5498@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> How about making it be
>
> [core]
> sharedrepository = {umask | user | group | everybody}
>
> and allow the old boolean expression syntax to mean "0/false means umask,
> 1/true means group".
>
> So you'd have:
>
> - umask/0/false means "use 0777 permissions with default umask"
> - user means "use 0500 permissions"
> - group means "use 0550 permissions"
> - everybody means "use 0555 permissions"
>
> (where "5" is r-x, and only for directories, and obviously degenerates to
> just "4" aka r-- for regular files).
>
> That sounds really pretty self-explanatory and obvious, wouldn't you say?
Yes, the user can mistype "gruop", people would start making
noises about having "world" as a synonym for "everybody", and
the parsing becomes somewhat cumbersome, and all that trouble,
but on the other hand that is probably the easiest to explain.
^ permalink raw reply
* Re: [PATCH] shared repository settings enhancement.
From: Linus Torvalds @ 2006-06-10 4:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vver9k5gg.fsf@assigned-by-dhcp.cox.net>
On Fri, 9 Jun 2006, Junio C Hamano wrote:
>
> Yes, the user can mistype "gruop", people would start making
> noises about having "world" as a synonym for "everybody", and
> the parsing becomes somewhat cumbersome, and all that trouble,
> but on the other hand that is probably the easiest to explain.
Actually, it's quite easy to parse using the git config file parsers.
Let's say that 0 means umask, 1 means group, 2 means user and 3 means
everybody. That leaves "0/1" with the old false/true behaviour, and leaves
umask as the default.
So we'd have
enum sharedrepo {
PERM_UMASK = 0,
PERM_GROUP,
PERM_USER,
PERM_EVERYBODY
};
int git_config_perm(const char *var, const char *value)
{
if (!strncmp(value, "umask"))
return PERM_UMASK;
if (!strncmp(value, "group"))
return PERM_GROUP;
if (!strncmp(value, "user"))
return PERM_USER;
if (!strncmp(value, "world") || !strncmp(value, "everybody"))
return PERM_EVERYBODY;
return git_config_bool(var, value);
}
and then in check_repository_format_version() you just have
..
else if (strcmp(var, "core.sharedrepository") == 0)
shared_repository = git_config_perm(var, value);
..
instead of git_config_bool() there, and you're done. That's not so bad, is
it?
Linus
^ permalink raw reply
* Re: Figured out how to get Mozilla into git
From: Jon Smirl @ 2006-06-10 6:02 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Martin Langhoff, git
In-Reply-To: <Pine.LNX.4.64.0606092109380.5498@g5.osdl.org>
Here's a new transport problem. When using git-clone to fetch Martin's
tree it kept failing for me at dreamhost. I had a parallel fetch
running on my local machine which has a much slower net connection. It
finally finished and I am watching the end phase where it prints all
of the 'walk' messages. The git-http-fetch process has jumped up to
800MB in size after being 2MB during the download. dreamhost has a
500MB process size limit so that is why my fetches kept failing there.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Figured out how to get Mozilla into git
From: Junio C Hamano @ 2006-06-10 6:15 UTC (permalink / raw)
To: Jon Smirl; +Cc: git
In-Reply-To: <9e4733910606092302h646ff554p107564417183e350@mail.gmail.com>
"Jon Smirl" <jonsmirl@gmail.com> writes:
> Here's a new transport problem. When using git-clone to fetch Martin's
> tree it kept failing for me at dreamhost. I had a parallel fetch
> running on my local machine which has a much slower net connection. It
> finally finished and I am watching the end phase where it prints all
> of the 'walk' messages. The git-http-fetch process has jumped up to
> 800MB in size after being 2MB during the download. dreamhost has a
> 500MB process size limit so that is why my fetches kept failing there.
The http-fetch process uses by mmaping the downloaded pack, and
if I recall correctly we are talking about 600MB pack, so 500MB
limit sounds impossible, perhaps?
^ permalink raw reply
* Re: Figured out how to get Mozilla into git
From: Jakub Narebski @ 2006-06-10 8:21 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0606092001590.5498@g5.osdl.org>
Linus Torvalds wrote:
> On Fri, 9 Jun 2006, Carl Worth wrote:
>
>> On Fri, 9 Jun 2006 22:21:17 -0400, "Jon Smirl" wrote:
>> >
>> > Could you clone the repo and delete changesets earlier than 2004? Then
>> > I would clone the small repo and work with it. Later I decide I want
>> > full history, can I pull from a full repository at that point and get
>> > updated? That would need a flag to trigger it since I don't want full
>> > history to come over if I am just getting updates from someone else's
>> > tree that has a full history.
>>
>> This is clearly a desirable feature, and has been requested by several
>> people (including myself) looking to switch some large-ish histories
>> from an existing system to git.
>
> The thing is, to some degree it's really fundamentally hard.
>
> It's easy for a linear history. What you do for a linear history is to
> just get the top commit, and the tree associated with it, and then you
> cauterize the parent by just grafting it to go away. Boom. You're done.
>
> The problems are that if the preceding history _wasn't_ linear (or, in
> fact, _subsequent_ development refers to it by having branched off at an
> earlier point), and you try to pull your updates, the other end (that
> knows about all the history) will assume you have all the history that you
> don't have, and will send you a pack assuming that.
Couldn't it be solved by enhancing initial handshake to send from puller
(object receivier) to pullee (object sender) the contents of graft file, or
better the contents of cauterizing graft file - without splitting graft
file we better have an option to send graft file or not, when graft file is
used to join historical repository line of development not to cauterize
history.
Then the sender would use sent cauterizing history graft file for
calculating which objects to sedn _only_, "in memory" cauterizing it's own
history.
Main disadvantage is if one cauterized history too eagerly, and shallow
clone history can lack merge bases, and have no way to get them _simply_
using this approach...
Now I guess you would tell me why this very simple idea is stupid...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ 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