* Re: Figured out how to get Mozilla into git
From: Linus Torvalds @ 2006-06-09 20:40 UTC (permalink / raw)
To: Jon Smirl; +Cc: Martin Langhoff, git
In-Reply-To: <9e4733910606091317p26d66579mdf93db293f93fb50@mail.gmail.com>
On Fri, 9 Jun 2006, Jon Smirl wrote:
>
> > Git is much better at packing than either CVS or SVN. Get used to it ;)
>
> 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.
.. or one of them is adding something.
For example, it may well be that cvs2svn does a lot more commits or
something like that.
That said, I don't even see where git-svn packs anythign at all, and
you're absolutely right that when/how you repack can make a huge
difference to disk usage, much more so than any importer details.
> > Do you have all the cvsps patches? There's a few important ones floating
> > around, and David Mansfield never did a 2.2 release..
>
> I am running cvsps-2.1-3.fc5 so I may be wasting my time. Error out is
> 535MB now.
> He sent me some git patches, but none for cvsps.
I've got a couple, but I was hoping David would do a cvsps-2.2. I have
this dim memory of him saying he had done some other improvements too.
> 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.
Sure. That said, I pretty much guarantee that the size issues will be much
much worse for any other distributed SCM.
If Mozilla doesn't need the distributed thing, then SVN is probably the
best choice. It's still a total piece of crap, but hey, if crap (==
centralized) is what people are used to, a few billion flies can't be
wrong ;)
If you got your import done, is there some place I can rsync it from, and
at least I can make sure that everything works fine for a repo that size..
One day the Mozilla people will notice that they really _really_ want the
distribution, and they'll figure out quickly enough that SVK doesn't cut
it, I suspect.
Linus
^ permalink raw reply
* Re: Git-daemon messing up permissions for gitweb
From: Linus Torvalds @ 2006-06-09 20:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Post, Mark K
In-Reply-To: <7vodx2m5jp.fsf@assigned-by-dhcp.cox.net>
On Fri, 9 Jun 2006, Junio C Hamano wrote:
>
> But that should be tweakable by configuring what sshd does for
> the user, shouldn't it? The "LOGIN PROCESS" section from man
> sshd(8) seems to talk about $HOME/.ssh/environment, for example.
Yeah. That's probably the right place to set things up.
Linus
^ permalink raw reply
* Re: Figured out how to get Mozilla into git
From: Jakub Narebski @ 2006-06-09 20:44 UTC (permalink / raw)
To: git
In-Reply-To: <9e4733910606091317p26d66579mdf93db293f93fb50@mail.gmail.com>
Jon Smirl wrote:
> 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.
Partial/shallow nor lazy clone we don't have (although there might be some
shallow clone partial solutions in topic branches and/or patches flying
around in git mailing list). Yet.
But you can do what was done for Linux kernel: split repository into current
and historical, and you can join them (join the history) if needed using
grafts. And even if one need historical repository, it is neede to
clone/copy only _once_. With alternatives (using historical repository as
one of alternatives for current repository) someone who has both
repositories does need only a little more space, I think, than if one used
single repository.
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* RE: Git-daemon messing up permissions for gitweb
From: Post, Mark K @ 2006-06-09 20:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
I'm fairly familiar with SSH, but I don't know how to do this. I just
did some man commands, didn't see anything there. Can you give me a
pointer?
Mark Post
-----Original Message-----
From: Junio C Hamano [mailto:junkio@cox.net]
Sent: Friday, June 09, 2006 4:19 PM
To: Post, Mark K
Cc: git@vger.kernel.org
Subject: Re: Git-daemon messing up permissions for gitweb
"Post, Mark K" <mark.post@eds.com> writes:
> Martin is using git over SSH. I have git-shell in /etc/passwd for his
> account.
Ah, then umask git-shell gets from sshd is too restrictive.
Loosen it and you will be fine.
^ permalink raw reply
* RE: Git-daemon messing up permissions for gitweb
From: Post, Mark K @ 2006-06-09 20:52 UTC (permalink / raw)
To: Linus Torvalds, Junio C Hamano; +Cc: git
Since umask isn't an environment variable, per se, I'm not sure how this
will change anything.
One other thing I noticed is that init-db.c spells core.sharedRepository
with a capital R, but setup.c spells it "core.sharedrepository" with no
upper case letters. Would this make any difference to anything I'm
seeing?
Mark Post
-----Original Message-----
From: Linus Torvalds [mailto:torvalds@osdl.org]
Sent: Friday, June 09, 2006 4:44 PM
To: Junio C Hamano
Cc: git@vger.kernel.org; Post, Mark K
Subject: Re: Git-daemon messing up permissions for gitweb
On Fri, 9 Jun 2006, Junio C Hamano wrote:
>
> But that should be tweakable by configuring what sshd does for
> the user, shouldn't it? The "LOGIN PROCESS" section from man
> sshd(8) seems to talk about $HOME/.ssh/environment, for example.
Yeah. That's probably the right place to set things up.
Linus
^ permalink raw reply
* Re: Figured out how to get Mozilla into git
From: Jon Smirl @ 2006-06-09 20:56 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Martin Langhoff, git
In-Reply-To: <Pine.LNX.4.64.0606091331170.5498@g5.osdl.org>
On 6/9/06, Linus Torvalds <torvalds@osdl.org> wrote:
> > 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.
>
> Sure. That said, I pretty much guarantee that the size issues will be much
> much worse for any other distributed SCM.
>
> If Mozilla doesn't need the distributed thing, then SVN is probably the
> best choice. It's still a total piece of crap, but hey, if crap (==
> centralized) is what people are used to, a few billion flies can't be
> wrong ;)
They need the distributed thing whether they realize it or not. Some
of the external projects like songbird and nvu are vulnerable to drift
since they are running their own repositories. Once a few
move/renames happen they can't easily stay in sync anymore. It has
been over a year since NVU was merged back into the trunk.
That is the same reason I want it, so that I can work on stuff locally
and have a repository. The core staff doesn't have this problem
because they can make all the branches they want in the main
repository.
> If you got your import done, is there some place I can rsync it from, and
> at least I can make sure that everything works fine for a repo that size..
> One day the Mozilla people will notice that they really _really_ want the
> distribution, and they'll figure out quickly enough that SVK doesn't cut
> it, I suspect.
It would be better to rsync Martins copy, he has a lot more bandwidth.
It will take over a day to copy it off my cable modem. I'm signed up
to get FIOS as soon as they turn it on in my neighborhood, it's
already wired on the poles.
>
> Linus
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Git-daemon messing up permissions for gitweb
From: Jakub Narebski @ 2006-06-09 21:02 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0606091344010.5498@g5.osdl.org>
I've put proposed solution in GitWiki:
http://git.or.cz/gitwiki/GitFaq#git-push-ssh-umask
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: Failed git commands and StGIT
From: Catalin Marinas @ 2006-06-09 21:05 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060609183623.GJ11941@pasky.or.cz>
On 09/06/06, Petr Baudis <pasky@suse.cz> wrote:
> a user at #git just came with a problem with stg refresh - it turned
> out that he did not have his environment set up properly, but what is
> troublesome that stg refresh just said that "git-commit-tree failed" and
> did not show the actual error message - looking at the code, you
> probably want to keep fd 3 on the parent process' stderr, that is use
> open2, not open3.
I also found this annoying but I was too lazy to fix it. To not
capture the stderr is easy (just change pass false as the 2nd argument
to popen2.Popen3) but there is a duplicate of error messages from both
GIT and StGIT. The other option is to add a '--verbose' option to most
of the commands. I'll have a look at it this weekend.
Thanks.
--
Catalin
^ permalink raw reply
* Re: Figured out how to get Mozilla into git
From: Nicolas Pitre @ 2006-06-09 21:05 UTC (permalink / raw)
To: Jon Smirl; +Cc: Linus Torvalds, Martin Langhoff, git
In-Reply-To: <9e4733910606091317p26d66579mdf93db293f93fb50@mail.gmail.com>
On Fri, 9 Jun 2006, Jon Smirl wrote:
> 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.
This is true. GIT is still evolving and certainly needs work to cope
with environments and datasets that were never tested before. The
Mozilla repo is one of those and we're certainly interested into making
it work well. GIT might not be right for it just yet, but if you could
let us rsync your converted repo to play with that might help us work on
proper fixes for that kind of repo.
> Martin has also brought up the problem with needing a partial clone so
> that everyone doesn't have to bring down the entire repository.
If it can be repacked into a single pack that size might get much
smaller too.
Nicolas
^ permalink raw reply
* Re: Git-daemon messing up permissions for gitweb
From: Junio C Hamano @ 2006-06-09 21:06 UTC (permalink / raw)
To: Post, Mark K; +Cc: Linus Torvalds, git
In-Reply-To: <5A14AF34CFF8AD44A44891F7C9FF410507957896@usahm236.amer.corp.eds.com>
"Post, Mark K" <mark.post@eds.com> writes:
> Since umask isn't an environment variable, per se, I'm not sure how this
> will change anything.
I do not configure my sshd, so you may need a bit more reading
on it yourself; $HOME/.ssh/environment does not seem to be it,
as you said.
> One other thing I noticed is that init-db.c spells core.sharedRepository
> with a capital R, but setup.c spells it "core.sharedrepository" with no
> upper case letters. Would this make any difference to anything I'm
> seeing?
The distinction should not matter since the code downcases
(git_config_set_multivar() in config.c) it, but to avoid future
confusion we might want to downcase the one in init-db.c
^ permalink raw reply
* Re: Failed git commands and StGIT
From: Petr Baudis @ 2006-06-09 21:25 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0606091405o79002a79id02e8fdd3936a345@mail.gmail.com>
Dear diary, on Fri, Jun 09, 2006 at 11:05:47PM CEST, I got a letter
where Catalin Marinas <catalin.marinas@gmail.com> said that...
> I also found this annoying but I was too lazy to fix it. To not
> capture the stderr is easy (just change pass false as the 2nd argument
> to popen2.Popen3) but there is a duplicate of error messages from both
> GIT and StGIT. The other option is to add a '--verbose' option to most
> of the commands. I'll have a look at it this weekend.
I don't think this is actually an issue. I'd actually prefer the
behaviour of NOT having to add a '--verbose' option to a stgit command
to see the full error output.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply
* Re: Figured out how to get Mozilla into git
From: Jon Smirl @ 2006-06-09 21:46 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Linus Torvalds, Martin Langhoff, git
In-Reply-To: <Pine.LNX.4.64.0606091655420.2703@localhost.localdomain>
On 6/9/06, Nicolas Pitre <nico@cam.org> wrote:
> On Fri, 9 Jun 2006, Jon Smirl wrote:
>
> > 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.
>
> This is true. GIT is still evolving and certainly needs work to cope
> with environments and datasets that were never tested before. The
> Mozilla repo is one of those and we're certainly interested into making
> it work well. GIT might not be right for it just yet, but if you could
> let us rsync your converted repo to play with that might help us work on
> proper fixes for that kind of repo.
I'm rebuilding it on my shared hosting account at dreamhost.com. I'll
see if I can get it built before they notice and kill my process. My
account there is on a 4GB quad xeon box so hopefully it can convert
the tree faster. My account has 1TB download per month so rsync will
be ok. Not bad for $12 the first year.
It would take over a day to rsync it off from my home machine.
> > Martin has also brought up the problem with needing a partial clone so
> > that everyone doesn't have to bring down the entire repository.
>
> If it can be repacked into a single pack that size might get much
> smaller too.
>
>
> Nicolas
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Figured out how to get Mozilla into git
From: Linus Torvalds @ 2006-06-09 21:57 UTC (permalink / raw)
To: Jon Smirl; +Cc: Martin Langhoff, git
In-Reply-To: <9e4733910606091356w391b4fdao23db5b2ce3c3e282@mail.gmail.com>
On Fri, 9 Jun 2006, Jon Smirl wrote:
>
> They need the distributed thing whether they realize it or not. Some
> of the external projects like songbird and nvu are vulnerable to drift
> since they are running their own repositories. Once a few
> move/renames happen they can't easily stay in sync anymore. It has
> been over a year since NVU was merged back into the trunk.
>
> That is the same reason I want it, so that I can work on stuff locally
> and have a repository. The core staff doesn't have this problem
> because they can make all the branches they want in the main
> repository.
Yes. Anyway, I think we'll get git working well for repositories that
size, and eventually the core developers will notice how much better it
is.
In the meantime, the fact that git-cvsimport can be done incrementally
means that once we have the silly pack-file-mapping details worked out, it
should be perfectly fine to run the 3-day import just once, and then work
on it incrementally afterwards without any real problems.
So people like you who want to work on it off-line using a distributed
system _can_ do so, realistically. Maybe not practically _today_, but I
don't think the git issues are serious enough that we'd be talking about
"months from now", but more of a "in a week or so we migh have something
that works fine for your case".
[ They had this long discussion about languages on #monotone the other
day, and the reason I'll take C over anything else any day is the fact
that a well-written C program is literally only limited by hardware,
never by the language. The poor python/perl guys may write things more
quickly, but when they hit a language wall, they hit it.
I think we've got an excellent data model, and handling even something
huge like the _whole_ history of mozilla doesn't look very daunting at
all. I just want to have a real test-case to motivate me to look at the
problems. ]
> It would be better to rsync Martins copy, he has a lot more bandwidth.
> It will take over a day to copy it off my cable modem. I'm signed up
> to get FIOS as soon as they turn it on in my neighborhood, it's
> already wired on the poles.
Sure. I actually just have regular 128kbps DSL myself. I guess I should
upgrade to 256 (the downside of having deer munching on the roses in our
back yard is that I don't think I even have the option for anything
faster), but I'm so damn well distributed that the slow 128kbps is
actually more than enough - everything serious I do is local anyway.
So it will take me quite some time to download 2GB+, regardless of how fat
a pipe the other end has ;)
Linus
^ permalink raw reply
* Re: Figured out how to get Mozilla into git
From: Linus Torvalds @ 2006-06-09 22:17 UTC (permalink / raw)
To: Jon Smirl; +Cc: Martin Langhoff, git
In-Reply-To: <Pine.LNX.4.64.0606091450180.5498@g5.osdl.org>
On Fri, 9 Jun 2006, Linus Torvalds wrote:
>
> Sure. I actually just have regular 128kbps DSL myself.
Not bits, bytes. 128_KB_/s, of course. Actually, it's slightly more.
Something like 146KB/s, I guess that comes to 1.5Mbps.
Just in case somebody thought I was living in a cave in the middle ages.
Anyway, no nice 5Mbps cable for me.
Linus
^ permalink raw reply
* Redhat stateless Linux and git
From: Jon Smirl @ 2006-06-09 22:59 UTC (permalink / raw)
To: git
Redhat is looking for a scheme to sync the disk system of their
stateless Linux client. They were using rsync and now they are looking
at doing it with LVM.
What about using git?
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Figured out how to get Mozilla into git
From: Greg KH @ 2006-06-09 23:16 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jon Smirl, Martin Langhoff, git
In-Reply-To: <Pine.LNX.4.64.0606091450180.5498@g5.osdl.org>
On Fri, Jun 09, 2006 at 02:57:58PM -0700, Linus Torvalds wrote:
> > It would be better to rsync Martins copy, he has a lot more bandwidth.
> > It will take over a day to copy it off my cable modem. I'm signed up
> > to get FIOS as soon as they turn it on in my neighborhood, it's
> > already wired on the poles.
>
> So it will take me quite some time to download 2GB+, regardless of how fat
> a pipe the other end has ;)
Fed-Ex a DVD or two would probably be fastest :)
^ permalink raw reply
* Re: Figured out how to get Mozilla into git
From: Martin Langhoff @ 2006-06-09 23:37 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jon Smirl, git
In-Reply-To: <Pine.LNX.4.64.0606091450180.5498@g5.osdl.org>
Apologies, I dropped out of the conversation -- Friday night drinks
(NZ timezone) took over ;-)
Now, back on track...
On 6/10/06, Linus Torvalds <torvalds@osdl.org> wrote:
> In the meantime, the fact that git-cvsimport can be done incrementally
> means that once we have the silly pack-file-mapping details worked out, it
> should be perfectly fine to run the 3-day import just once, and then work
> on it incrementally afterwards without any real problems.
Exactly. The dog at this time is cvsps -- I also remember vague
promises from a list regular of publishing a git repo with cvsps2.1 +
some patches from the list.
In any case, and for the record, my cvsps is 2.1 pristine. It handles
the mozilla repo alright, as long as I give it a lot of RAM. I _think_
it slurped 3GB with the mozilla cvs.
I want to review that cvs2svn importer, probably to steal the test
cases and perhaps some logic to revamp/replace cvsps. The thing is --
we can't just drop/replace cvsimport because it does incrementals, so
continuity and consistency are key. All the CVS imports have to take
some hard decisions when the data is bad -- however it is we fudge it,
we kind of want to fudge it consistently ;-)
> So people like you who want to work on it off-line using a distributed
> system _can_ do so, realistically. Maybe not practically _today_
Other than "don't run repack -a", it's feasible. In fact, that's how I
use git 99% of the time -- to do DSCM stuff on projects that are using
CVS, like Moodle.
> The poor python/perl guys may write things more
> quickly, but when they hit a language wall, they hit it.
Flamebait anyone? ;-) It is a different kind of fun -- let's say that
on top of knowing the performance tricks (or, to be more hip: "design
patterns") for the hardware and OS, you also end up learning the
performance tricks of the interpreter/vm/whatever.
> > It would be better to rsync Martins copy, he has a lot more bandwidth.
I'm coming down to the office now to pick up my laptop, and I'll rsync
it out to our git machine (also NZ kernel mirror, bandwidth should be
good). That's one of the things I've discovered with these large
trees: for the initial publish action, I just use rsync or scp.
Perhaps I'm doing it wrong, but git-push doesn't optimise the
'initialise repo', and it take ages (and it this case, it'd probably
OOM).
> So it will take me quite some time to download 2GB+, regardless of how fat
> a pipe the other end has ;)
Right-o. Linus, Jon, can you guys then ping me when you have cloned it
safely so I can take it down again?
cheers,
martin
^ permalink raw reply
* Re: Figured out how to get Mozilla into git
From: Linus Torvalds @ 2006-06-09 23:43 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Jon Smirl, git
In-Reply-To: <46a038f90606091637o6a0194d5yb413237253a372fc@mail.gmail.com>
On Sat, 10 Jun 2006, Martin Langhoff wrote:
>
> Exactly. The dog at this time is cvsps -- I also remember vague
> promises from a list regular of publishing a git repo with cvsps2.1 +
> some patches from the list.
Ahh. cvsps doesn't do anything incrementally, does it?
Although it _does_ build up a cache of sorts, I think. That's not the
parts I actually ever ended up looking at.
But yeah, a cvsps that blows up to a gig of VM and takes half an hour to
parse things just for an incremental update would be a problem.
> In any case, and for the record, my cvsps is 2.1 pristine. It handles
> the mozilla repo alright, as long as I give it a lot of RAM. I _think_
> it slurped 3GB with the mozilla cvs.
Oh, wow. Every single repo I've seen ends up having tons of complaints
from pristine cvsps, but maybe that's because I only end up looking at the
ones with problems ;)
> I'm coming down to the office now to pick up my laptop, and I'll rsync
> it out to our git machine (also NZ kernel mirror, bandwidth should be
> good). That's one of the things I've discovered with these large
> trees: for the initial publish action, I just use rsync or scp.
> Perhaps I'm doing it wrong, but git-push doesn't optimise the
> 'initialise repo', and it take ages (and it this case, it'd probably
> OOM).
>
> > So it will take me quite some time to download 2GB+, regardless of how fat
> > a pipe the other end has ;)
>
> Right-o. Linus, Jon, can you guys then ping me when you have cloned it
> safely so I can take it down again?
Tell me where/when it is, and I'll start slurping. Will let you know when
I'm done.
Linus
^ permalink raw reply
* Re: Figured out how to get Mozilla into git
From: Jon Smirl @ 2006-06-10 0:00 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Martin Langhoff, git
In-Reply-To: <Pine.LNX.4.64.0606091640200.5498@g5.osdl.org>
On 6/9/06, Linus Torvalds <torvalds@osdl.org> wrote:
> On Sat, 10 Jun 2006, Martin Langhoff wrote:
> > In any case, and for the record, my cvsps is 2.1 pristine. It handles
> > the mozilla repo alright, as long as I give it a lot of RAM. I _think_
> > it slurped 3GB with the mozilla cvs.
>
> Oh, wow. Every single repo I've seen ends up having tons of complaints
> from pristine cvsps, but maybe that's because I only end up looking at the
> ones with problems ;)
Are we sure cvsps is ok? It is generating 500MB of warnings when I run it.
I have cvsps running at dreamhost currently. I had to modify cvs,
cvps, git, etc to not repsond to signals to keep them from killing
everything.
I can clone 2GB git tree there. Let me know when it is up.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Figured out how to get Mozilla into git
From: Linus Torvalds @ 2006-06-10 0:11 UTC (permalink / raw)
To: Jon Smirl; +Cc: Martin Langhoff, git
In-Reply-To: <9e4733910606091700s49018cd5p3b66f8ef51b22d2e@mail.gmail.com>
On Fri, 9 Jun 2006, Jon Smirl wrote:
>
> Are we sure cvsps is ok? It is generating 500MB of warnings when I run it.
Do they go away with these patches?
Linus
---
commit 3d1ebcef6b4f9f6c9064efd64da4dd30d93c3c96
Author: Linus Torvalds <torvalds@g5.osdl.org>
Date: Wed Mar 22 17:20:20 2006 -0800
Fix branch ancestor calculation
Not having any ancestor at all means that any valid ancestor (even of
"depth 0") is fine.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
diff --git a/cvsps.c b/cvsps.c
index c22147e..2695a0f 100644
--- 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)
commit 82fcf7e31bbeae3b01a8656549e9b8fd89d598eb
Author: Linus Torvalds <torvalds@g5.osdl.org>
Date: Wed Mar 22 11:23:37 2006 -0800
Improve handling of file collisions in the same patchset
Take the file revision into account.
diff --git a/cvsps.c b/cvsps.c
index 1e64e3c..c22147e 100644
--- a/cvsps.c
+++ b/cvsps.c
@@ -2384,8 +2384,31 @@ void patch_set_add_member(PatchSet * ps,
for (next = ps->members.next; next != &ps->members; next = next->next)
{
PatchSetMember * m = list_entry(next, PatchSetMember, link);
- if (m->file == psm->file && ps->collision_link.next == NULL)
- list_add(&ps->collision_link, &collisions);
+ if (m->file == psm->file) {
+ int order = compare_rev_strings(psm->post_rev->rev, m->post_rev->rev);
+
+ /*
+ * Same revision too? Add it to the collision list
+ * if it isn't already.
+ */
+ if (!order) {
+ if (ps->collision_link.next == NULL)
+ list_add(&ps->collision_link, &collisions);
+ return;
+ }
+
+ /*
+ * If this is an older revision than the one we already have
+ * in this patchset, just ignore it
+ */
+ if (order < 0)
+ return;
+
+ /*
+ * This is a newer one, remove the old one
+ */
+ list_del(&m->link);
+ }
}
psm->ps = ps;
commit 534120d9a47062eecd7b53fd7ac0b70d97feb4fd
Author: Linus Torvalds <torvalds@g5.osdl.org>
Date: Wed Mar 22 11:20:59 2006 -0800
Increase log-length limit to 64kB
Yeah, it should be dynamic. I'm lazy.
diff --git a/cvsps_types.h b/cvsps_types.h
index b41e2a9..dba145d 100644
--- a/cvsps_types.h
+++ b/cvsps_types.h
@@ -8,7 +8,7 @@ #define CVSPS_TYPES_H
#include <time.h>
-#define LOG_STR_MAX 32768
+#define LOG_STR_MAX 65536
#define AUTH_STR_MAX 64
#define REV_STR_MAX 64
#define MIN(a, b) ((a) < (b) ? (a) : (b))
^ permalink raw reply related
* Re: Figured out how to get Mozilla into git
From: Jon Smirl @ 2006-06-10 0:16 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Martin Langhoff, git
In-Reply-To: <Pine.LNX.4.64.0606091710560.5498@g5.osdl.org>
I'll apply and give it a test.
They look like this for most of them.
WARNING: Invalid PatchSet 151492, Tag JSS_4_0_RTM:
security/coreconf/HP-UX.mk:1.8=after,
security/jss/org/mozilla/jss/crypto/KeyPairAlgorithm.java:1.5=before.
Treated as 'before'
WARNING: Invalid PatchSet 151492, Tag JSS_4_0_RTM:
security/coreconf/HP-UX.mk:1.8=after,
security/jss/org/mozilla/jss/crypto/KeyPairGenerator.java:1.5=before.
Treated as 'before'
WARNING: Invalid PatchSet 151492, Tag JSS_4_0_RTM:
security/coreconf/HP-UX.mk:1.8=after,
security/jss/org/mozilla/jss/crypto/KeyPairGeneratorSpi.java:1.3=before.
Treated as 'before'
WARNING: Invalid PatchSet 151492, Tag JSS_4_0_RTM:
security/coreconf/HP-UX.mk:1.8=after,
security/jss/org/mozilla/jss/crypto/KeyWrapAlgorithm.java:1.8=before.
Treated as 'before'
WARNING: Invalid PatchSet 151492, Tag JSS_4_0_RTM:
security/coreconf/HP-UX.mk:1.8=after,
security/jss/org/mozilla/jss/crypto/KeyWrapper.java:1.8=before.
Treated as 'before'
WARNING: Invalid PatchSet 151492, Tag JSS_4_0_RTM:
security/coreconf/HP-UX.mk:1.8=after,
security/jss/org/mozilla/jss/crypto/Makefile:1.2=before. Treated as
'before'
WARNING: Invalid PatchSet 151492, Tag JSS_4_0_RTM:
security/coreconf/HP-UX.mk:1.8=after,
security/jss/org/mozilla/jss/crypto/NoSuchItemOnTokenException.java:1.3=before.
Treated as 'before'
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* [PATCH/RFC] Retire SIMPLE_*** stuff.
From: Junio C Hamano @ 2006-06-10 0:35 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <7virnam435.fsf@assigned-by-dhcp.cox.net>
It used to be a good idea to keep simple stuff without linking with git
library, but more and more programs are using the config mechanism, and
yet more things are becoming internal.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Makefile | 24 +++++-------------------
1 files changed, 5 insertions(+), 19 deletions(-)
diff --git a/Makefile b/Makefile
index 5226fa1..d65fc71 100644
--- a/Makefile
+++ b/Makefile
@@ -142,12 +142,7 @@ SCRIPTS = $(patsubst %.sh,%,$(SCRIPT_SH)
$(patsubst %.py,%,$(SCRIPT_PYTHON)) \
git-cherry-pick git-status
-# The ones that do not have to link with lcrypto, lz nor xdiff.
-SIMPLE_PROGRAMS = \
- git-get-tar-commit-id$X git-mailsplit$X \
- git-stripspace$X git-daemon$X
-
-# ... and all the rest that could be moved out of bindir to gitexecdir
+# Programs could be moved out of bindir to gitexecdir
PROGRAMS = \
git-checkout-index$X git-clone-pack$X \
git-convert-objects$X git-fetch-pack$X git-fsck-objects$X \
@@ -162,7 +157,9 @@ PROGRAMS = \
git-upload-pack$X git-verify-pack$X git-write-tree$X \
git-update-ref$X git-symbolic-ref$X \
git-name-rev$X git-pack-redundant$X git-repo-config$X git-var$X \
- git-describe$X git-merge-tree$X git-blame$X git-imap-send$X
+ git-describe$X git-merge-tree$X git-blame$X git-imap-send$X \
+ git-get-tar-commit-id$X git-mailsplit$X \
+ git-stripspace$X git-daemon$X
BUILT_INS = git-log$X git-whatchanged$X git-show$X \
git-count-objects$X git-diff$X git-push$X \
@@ -175,7 +172,7 @@ BUILT_INS = git-log$X git-whatchanged$X
git-diff-index$X git-diff-stages$X git-diff-tree$X git-cat-file$X
# what 'all' will build and 'install' will install, in gitexecdir
-ALL_PROGRAMS = $(PROGRAMS) $(SIMPLE_PROGRAMS) $(SCRIPTS)
+ALL_PROGRAMS = $(PROGRAMS) $(SCRIPTS)
# Backward compatibility -- to be removed after 1.0
PROGRAMS += git-ssh-pull$X git-ssh-push$X
@@ -386,11 +383,9 @@ else
endif
ifdef NEEDS_SOCKET
LIBS += -lsocket
- SIMPLE_LIB += -lsocket
endif
ifdef NEEDS_NSL
LIBS += -lnsl
- SIMPLE_LIB += -lnsl
endif
ifdef NO_D_TYPE_IN_DIRENT
ALL_CFLAGS += -DNO_D_TYPE_IN_DIRENT
@@ -428,6 +428,8 @@ endif
ifdef NO_ICONV
ALL_CFLAGS += -DNO_ICONV
+else
+ LIBS += $(LIB_4_ICONV)
endif
ifdef PPC_SHA1
@@ -559,15 +554,6 @@ endif
git-%$X: %.o $(GITLIBS)
$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(LIBS)
-$(SIMPLE_PROGRAMS) : $(LIB_FILE)
-$(SIMPLE_PROGRAMS) : git-%$X : %.o
- $(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
- $(LIB_FILE) $(SIMPLE_LIB)
-
-git-mailinfo$X: mailinfo.o $(LIB_FILE)
- $(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
- $(LIB_FILE) $(SIMPLE_LIB) $(LIB_4_ICONV)
-
git-local-fetch$X: fetch.o
git-ssh-fetch$X: rsh.o fetch.o
git-ssh-upload$X: rsh.o
--
1.4.0.rc2.g55be
^ permalink raw reply related
* [PATCH] shared repository settings enhancement.
From: Junio C Hamano @ 2006-06-10 0:39 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Post, Mark K
In-Reply-To: <7virnam435.fsf@assigned-by-dhcp.cox.net>
This lets you say:
[core]
sharedrepository = 075
to allow permission bits on files under $GIT_DIR for OTHER users
(not just GROUP users) to be copied from the permission bits of
the owner of the file. This is useful for publishing a shared
repository over gitweb, when gitweb does not run as a member of
the project group and some members have umask too strict for
others to read what is created by default. The historical
boolean sharedrepository maps to 070 (i.e. if the owner can read
or write or execute it, group members can, too).
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* This patch is meant for discussion, not application, as you
can see there is one big "NEEDSWORK" in builtin-init-db.c.
Regardless of this enhancement to deal with S_I[RWX]OTH, I
spotted a couple of places that lack permission adjustment in
the existing code, which might be worth fixing first.
builtin-init-db.c | 21 ++++++++++++++++++---
config.c | 2 +-
lockfile.c | 15 ++++++++++-----
refs.c | 5 +++++
setup.c | 25 +++++++++++++++++++++++--
sha1_file.c | 9 ++++++---
6 files changed, 63 insertions(+), 14 deletions(-)
diff --git a/builtin-init-db.c b/builtin-init-db.c
index 88b39a4..4826c08 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -198,6 +198,11 @@ static void create_default_files(const c
git_config(git_default_config);
+ /* NEEDSWORK: we would have created the above under user's
+ * umask -- under shared-repository settings, we would need
+ * to fix them up by scanning under $GIT_DIR here.
+ */
+
/*
* Create the default symlink from ".git/HEAD" to the "master"
* branch, if it does not exist yet.
@@ -248,7 +253,14 @@ int cmd_init_db(int argc, const char **a
if (!strncmp(arg, "--template=", 11))
template_dir = arg+11;
else if (!strcmp(arg, "--shared"))
- shared_repository = 1;
+ shared_repository = 070; /* might want 075 */
+ else if (!strncmp(arg, "--shared=", 9)) {
+ char *end;
+ long val = strtol(arg+9, &end, 8);
+ if (*end || 077 < val)
+ die("bad option for --shared=");
+ shared_repository = val;
+ }
else
die(init_db_usage);
}
@@ -286,8 +298,11 @@ int cmd_init_db(int argc, const char **a
strcpy(path+len, "/info");
safe_create_dir(path, 1);
- if (shared_repository)
- git_config_set("core.sharedrepository", "true");
+ if (shared_repository) {
+ char buf[6];
+ sprintf(buf, "%o", shared_repository);
+ git_config_set("core.sharedrepository", buf);
+ }
return 0;
}
diff --git a/config.c b/config.c
index 2ae6153..c474970 100644
--- a/config.c
+++ b/config.c
@@ -536,7 +536,7 @@ int git_config_set_multivar(const char*
* contents of .git/config will be written into it.
*/
fd = open(lock_file, O_WRONLY | O_CREAT | O_EXCL, 0666);
- if (fd < 0) {
+ if (fd < 0 || adjust_shared_perm(lock_file)) {
fprintf(stderr, "could not lock config file\n");
free(store.key);
ret = -1;
diff --git a/lockfile.c b/lockfile.c
index 9bc6083..2346e0e 100644
--- a/lockfile.c
+++ b/lockfile.c
@@ -27,11 +27,16 @@ int hold_lock_file_for_update(struct loc
int fd;
sprintf(lk->filename, "%s.lock", path);
fd = open(lk->filename, O_RDWR | O_CREAT | O_EXCL, 0666);
- if (fd >=0 && !lk->next) {
- lk->next = lock_file_list;
- lock_file_list = lk;
- signal(SIGINT, remove_lock_file_on_signal);
- atexit(remove_lock_file);
+ if (0 <= fd) {
+ if (!lk->next) {
+ lk->next = lock_file_list;
+ lock_file_list = lk;
+ signal(SIGINT, remove_lock_file_on_signal);
+ atexit(remove_lock_file);
+ }
+ if (adjust_shared_perm(lk->filename))
+ return error("cannot fix permission bits on %s",
+ lk->filename);
}
return fd;
}
diff --git a/refs.c b/refs.c
index f91b771..713ca46 100644
--- a/refs.c
+++ b/refs.c
@@ -104,6 +104,11 @@ #endif
error("Unable to create %s", git_HEAD);
return -3;
}
+ if (adjust_shared_perm(git_HEAD)) {
+ unlink(lockpath);
+ error("Unable to fix permissions on %s", lockpath);
+ return -4;
+ }
return 0;
}
diff --git a/setup.c b/setup.c
index fe7f884..213c596 100644
--- a/setup.c
+++ b/setup.c
@@ -223,8 +223,29 @@ int check_repository_format_version(cons
{
if (strcmp(var, "core.repositoryformatversion") == 0)
repository_format_version = git_config_int(var, value);
- else if (strcmp(var, "core.sharedrepository") == 0)
- shared_repository = git_config_bool(var, value);
+ else if (strcmp(var, "core.sharedrepository") == 0) {
+ /* This is unfortunate, but historically this
+ * variable was bool, and it now takes the umask
+ * to say if we want to keep the same access bits for
+ * the user to group members and others.
+ */
+ if (!value)
+ shared_repository = 070; /* "true" - perhaps 075? */
+ else if (!*value)
+ ; /* bool "false" */
+ else if (!strcasecmp(value, "true"))
+ shared_repository = 070; /* "true" - perhaps 075? */
+ else if (!strcasecmp(value, "false"))
+ ; /* bool "false" */
+ else if (strchr("01234567", *value)) {
+ char *end;
+ long val = strtol(value, &end, 8);
+ if (*end || 077 < val)
+ die("bad config value '%s' for '%s'",
+ value, var);
+ shared_repository = val;
+ }
+ }
return 0;
}
diff --git a/sha1_file.c b/sha1_file.c
index aea0f40..fa19835 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -61,11 +61,14 @@ int adjust_shared_perm(const char *path)
return -1;
mode = st.st_mode;
if (mode & S_IRUSR)
- mode |= S_IRGRP;
+ mode |= ( ((shared_repository & 040) ? S_IRGRP : 0) |
+ ((shared_repository & 004) ? S_IROTH : 0) );
if (mode & S_IWUSR)
- mode |= S_IWGRP;
+ mode |= ( ((shared_repository & 020) ? S_IWGRP : 0) |
+ ((shared_repository & 002) ? S_IWOTH : 0) );
if (mode & S_IXUSR)
- mode |= S_IXGRP;
+ mode |= ( ((shared_repository & 010) ? S_IXGRP : 0) |
+ ((shared_repository & 001) ? S_IXOTH : 0) );
if (S_ISDIR(mode))
mode |= S_ISGID;
if (chmod(path, mode) < 0)
--
1.4.0.rc2.g55be
^ permalink raw reply related
* Re: Figured out how to get Mozilla into git
From: Jon Smirl @ 2006-06-10 0:45 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Martin Langhoff, git
In-Reply-To: <9e4733910606091716q67d4c5f9ra807b712d871e562@mail.gmail.com>
They must be running some kind of process accounting at my host. As
soon as I hit 500MB RAM I get killed immediately. It is not from a
signal, I'm catching all of those. Maybe some kind of process
accounting.
I get this on the console:
[1]+ Killed
CVSROOT=~/jonsmirl.dreamhosters.com/mozilla/ cvsps -x --norc -A
mozilla >mozilla.cvsps 2>mozilla.cvspserr
and nothing on stdout or stderr.
kernel string:
2.4.29-grsec+w+fhs6b+gr0501+nfs+a32+++p4+sata+c4+gr2b-v6.189
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* 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
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