* Re: Merging submodules
From: H.Merijn Brand @ 2008-07-31 20:44 UTC (permalink / raw)
To: Santi Béjar; +Cc: Petr Baudis, Brian Gernhardt, Git List, Lars Noschinski
In-Reply-To: <8aa486160807311203o3fb4deb8u4a5ae57818c76fab@mail.gmail.com>
On Thu, 31 Jul 2008 21:03:26 +0200, "Santi Béjar" <sbejar@gmail.com>
wrote:
> On Thu, Jul 31, 2008 at 20:15, H.Merijn Brand <h.m.brand@xs4all.nl> wrote:
> > On Thu, 31 Jul 2008 17:24:40 +0200, "Santi Béjar" <sbejar@gmail.com>
> > wrote:
> >
> >> I see all OK. Can you provide a self consistent simple testcase that
> >> shows what is wrong?
> >
> > Yes. was rather easy.
> > http://www.xs4all.nl/~hmbrand/testcase.tgz
> >
>
> It is because you cannot merge a branch with an empty branch.
Super. So I start with a .gitignore and continue this process. It
worked!
> So, or you create an initial commit in the "superproject" or you
> create a commit just moving the files of the first module as in:
>
> http://article.gmane.org/gmane.comp.version-control.git/79887
Thanks again!
--
H.Merijn Brand Amsterdam Perl Mongers http://amsterdam.pm.org/
using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00,
11.11, 11.23, and 11.31, SuSE 10.1, 10.2, and 10.3, AIX 5.2, and Cygwin.
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
^ permalink raw reply
* RE: Git vs Monotone
From: Blum, Robert @ 2008-07-31 20:42 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git@vger.kernel.org
In-Reply-To: <alpine.LFD.1.10.0807311244240.3277@nehalem.linux-foundation.org>
>The fact is, even without "-s", a local clone will do hardlinks for the
>database. And since the original pack-file is marked as a 'keep' file,
>that original pack-file won't even be broken apart.
Then again, Pidgin is, among other things, a Windows project. I.e. hardlinks are not exactly trivial. There's a good chance nobody jumped through the hoops of junction points for git on win32... (Somebody correct me if I'm wrong)
>So literally, if he had just bothered to even _try_ the git setup, he'd
>have noticed that git actually uses less disk than monotone would do. But
>it sounds like he didn't even try it.
Well, he *did* try it, for *one* repository. He just didn't know that there's a better way than having 11 clones. And I lay the blame for that squarely at the git documentation ;)
Yes, I know, why don't I make it better...?
Because I'm fairly new to git and would feel like an idiot 'documenting' something that I feel I've only scratched the surface of. I do expect to write a few uninformed rants on my blog, though. And maybe at some point, I can contribute to actual docs :)
Either way, it's another interesting data point for all of us still comparing DVCSs. I just wish he had comments on his blog so somebody could inform him that he's mistaken...
- Robert
^ permalink raw reply
* RE: Monotone workflow compared to Git workflow ( was RE: Git vs Monotone)
From: Craig L. Ching @ 2008-07-31 20:37 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailinglist
In-Reply-To: <alpine.LFD.1.10.0807311253140.3277@nehalem.linux-foundation.org>
> From: Linus Torvalds [mailto:torvalds@linux-foundation.org]
> Sent: Thursday, July 31, 2008 3:09 PM
>
> Sure, if you want to keep the build tree around, you would
> probably not use branches.
>
I think we'd still use branches, but we just need to isolate their
workdirs from each other.
> But yes, then you'd likely do "git clone -s" with some single
> "common point" or use "git worktree". And even if you don't
> use "-s", you should _still_ effectively share at least all
> the old history (which tends to be the bulk) thanks to even a
> default "git clone" will just hardlink the pack-files.
>
> So literally, if you do
>
> git clone <cntral-repo-over-network> <local>
>
> and then do
>
> git clone <local> <otherlocal>
> git clone <local> <thirdlocal>
>
> then all of those will all share the initial pack-file
> on-disk. Try it.
>
> (You may then want to edit the "origin" branch info in the
> .git/config to point to the network one etc, of course).
>
Yes, thank you for the explanation. Having used git a fair amount now,
that makes perfect sense to me, in fact, it sounds a lot like
git-new-workdir, but I think I'll change our use of git-new-workdir to
something more "core" git. It seems to me that maybe this is something
that could be documented more prominently? Or maybe it is and I've just
missed it. This would have saved me a lot of time originally to be
sure.
> Oh, and to make sure I'm not lying I actually did test this,
> but I also noticed that "git clone" no longer marks the
> initial pack-file with "keep", so it looks like "git gc" will
> then break the link. That's sad. I wonder when that changed,
> or maybe I'm just confused and it never did.
>
What's the consequence of that then? Because of that, would you say
"don't gc your master local repo until all derived repos are merged?"
If that link is broken is it just a loss of space? Or is it more?
> Linus
>
Thanks again!
Cheers,
Craig
^ permalink raw reply
* Re: Git vs Monotone
From: Linus Torvalds @ 2008-07-31 20:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Craig L. Ching, sverre, Git Mailinglist
In-Reply-To: <7vmyjxyf7a.fsf@gitster.siamese.dyndns.org>
On Thu, 31 Jul 2008, Junio C Hamano wrote:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
> > ... And since the original pack-file is marked as a 'keep' file,
> > that original pack-file won't even be broken apart.
>
> Oops, isn't that something we fixed recently as a "bug"?
Ehh, apparently. I had thought it was a feature (not that it was me who
implemented it), and didn't realize that others thought it was a bug.
Oops.
The default *.keep file was _wonderful_ for cloning a large tree onto a
small machine. It did exactly the right thing (never mind any shared
repositories - it just made repacking much more reasonable).
So maybe it was unintentional (a "bug"), but I had always seen it as being
something good.
Linus
^ permalink raw reply
* Re: [PATCH 0/2] gitweb use sections
From: Petr Baudis @ 2008-07-31 20:32 UTC (permalink / raw)
To: Gustavo Sverzut Barbieri; +Cc: git, Jakub Narebski
In-Reply-To: <b1f2b8c40807311243i5689683avcc3c3c91e4e6a900@mail.gmail.com>
Hi,
On Thu, Jul 31, 2008 at 04:43:35PM -0300, Gustavo Sverzut Barbieri wrote:
> Since nobody replied and I missed some gitweb guys in CC, I'm adding
> Petr and Jakub, as some guys said on IRC.
>
> Have anyone tried this patch, any problems?
sorry, I have it in my review queue. At first pass it was looking
good, but I wanted to look at it better before commenting.
One thing I'm wondering about is how to make this stuff configurable,
since I'm not very comfortable with adding more "unbound" configuration
variables and would rather prefer stuff to be added to the $features
array... I'm not at all sure about my own sentiment here, however.
--
Petr "Pasky" Baudis
As in certain cults it is possible to kill a process if you know
its true name. -- Ken Thompson and Dennis M. Ritchie
^ permalink raw reply
* Re: Git vs Monotone
From: Jeff King @ 2008-07-31 20:32 UTC (permalink / raw)
To: sverre
Cc: Craig L. Ching, Petr Baudis, Stephen R. van den Berg,
Git Mailinglist
In-Reply-To: <bd6139dc0807311219h670f782cm8bed74bed2b4558@mail.gmail.com>
On Thu, Jul 31, 2008 at 09:19:41PM +0200, Sverre Rabbelier wrote:
> I repacked with --depth=100 and --window=100, I tried out 500 at first
> but it was just insanely slow (on a VM with one 2.4Ghz Core
> available). This resulted in a .git dir of 76MB. With that dir I did
> the following:
I tried 200/200 and got a 74M packfile. So I think we're getting into
diminishing returns.
> $ du -sh .
> 742M .
>
> So... monotone, eat your heart out ;).
:)
-Peff
^ permalink raw reply
* Re: Git vs Monotone
From: Junio C Hamano @ 2008-07-31 20:24 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Craig L. Ching, sverre, Git Mailinglist
In-Reply-To: <alpine.LFD.1.10.0807311244240.3277@nehalem.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> ... And since the original pack-file is marked as a 'keep' file,
> that original pack-file won't even be broken apart.
Oops, isn't that something we fixed recently as a "bug"?
> So completely ignoring the fact that you could do a single database with
> git, and completely ignoring the fact that with git you'd probably use
> branches for at least some of those 11 repos anyway, he'd _still_ have had
> less disk space used by git unless he would do something intentionally odd
> (like clone all the repositories over the network separately).
Well, people are not perfect and they are free to express their opinions
based on faulty understanding of reality on their blogs. The right things
to do are (1) ignore them on the list and not waste many people's time,
and/or (2) educate them, but in private or in a circle where many other
similar ignorants benefit from such education. That is not here but
perhaps on #monotone channel?
^ permalink raw reply
* Re: git-scm.com
From: Kevin Ballard @ 2008-07-31 20:19 UTC (permalink / raw)
To: Jon Loeliger; +Cc: Tom Werner, git
In-Reply-To: <489206E4.2030901@freescale.com>
On Jul 31, 2008, at 11:39 AM, Jon Loeliger wrote:
> Tom Werner wrote:
>>
>> The problem is that I'm only a casual C coder. It takes me a while to
>> figure out what's going on in the git source. We needed a way to
>> serve
>> public git repositories from a hashed directory structure (e.g.
>> /a/b/c/user/repo.git) and we needed it fast.
>
> I'm not exactly sure what you mean by "hashed directory structure",
> but I suspect that your goal is some form of virtualized hosting
> that allows for directory names to be dynamically constructed with
> a component that appears to be the user name.
>
> Wouldn't the --interpolated-path ability of git-daemon either
> directly or with minor modifications directly support that?
Tom, correct me if I'm wrong, but my understanding of this is that,
with GFS, they were running into the problem of too many dirents in
one directory, thus causing lots of stability problems (GFS has a far
lower limit than other filesystems in this regard). So the GitHub guys
had to switch to a directory sharding structure (similar to how the
git objects db uses the first 2 characters of the hash as the dir
name) to split this up and keep the numbers manageable. However, they
still had to support the old git://github.com/user/project.git paths.
-Kevin Ballard
--
Kevin Ballard
http://kevin.sb.org
kevin@sb.org
http://www.tildesoft.com
^ permalink raw reply
* Re: Monotone workflow compared to Git workflow ( was RE: Git vs Monotone)
From: Shawn O. Pearce @ 2008-07-31 20:18 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Craig L. Ching, sverre, Git Mailinglist
In-Reply-To: <alpine.LFD.1.10.0807311253140.3277@nehalem.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> Oh, and to make sure I'm not lying I actually did test this, but I also
> noticed that "git clone" no longer marks the initial pack-file with
> "keep", so it looks like "git gc" will then break the link. That's sad. I
> wonder when that changed, or maybe I'm just confused and it never did.
It was a bug in git-clone that we were recording the .keep file on
initial clone. We left the lock file in place after the fetch pack
call was done, but didn't remove it after the refs were updated.
If we want to go back to .keep'ing the original pack creating
during clone it probably should be threshold based. For many
smaller projects with only a 25M pack (or less) there is no point
in .keep'ing that first pack. For larger projects where the pack
is over a few hundred megabytes, then yea, maybe there is value
in .keep'ing it during clone.
--
Shawn.
^ permalink raw reply
* Re: Monotone workflow compared to Git workflow ( was RE: Git vs Monotone)
From: Linus Torvalds @ 2008-07-31 20:09 UTC (permalink / raw)
To: Craig L. Ching; +Cc: sverre, Git Mailinglist
In-Reply-To: <63BEA5E623E09F4D92233FB12A9F79430238A5EE@emailmn.mqsoftware.com>
On Thu, 31 Jul 2008, Craig L. Ching wrote:
>
> We find ourselves constantly having to shift gears and work on other
> things in the middle of whatever it is we're currently working on. For
> instance, in the scenario above, A might be branch that contains a
> feature going into our next release. B might be a bugfix and takes
> priority over A, so you have to leave A as-is and start work on B. When
> I come back to work on A, I have to rebuild A to continue working, and
> that's just too expensive for us. So we use the monotone-like
> new-workdir which allows us to save those build artifacts.
>
> So, that said, I ask again, am I missing something? Is there a better
> way to do this? How do the kernel developers do this, surely they're
> switching branches back and forth having to build in-between?
Sure, if you want to keep the build tree around, you would probably not
use branches.
But yes, then you'd likely do "git clone -s" with some single "common
point" or use "git worktree". And even if you don't use "-s", you should
_still_ effectively share at least all the old history (which tends to be
the bulk) thanks to even a default "git clone" will just hardlink the
pack-files.
So literally, if you do
git clone <cntral-repo-over-network> <local>
and then do
git clone <local> <otherlocal>
git clone <local> <thirdlocal>
then all of those will all share the initial pack-file on-disk. Try it.
(You may then want to edit the "origin" branch info in the .git/config to
point to the network one etc, of course).
Oh, and to make sure I'm not lying I actually did test this, but I also
noticed that "git clone" no longer marks the initial pack-file with
"keep", so it looks like "git gc" will then break the link. That's sad. I
wonder when that changed, or maybe I'm just confused and it never did.
Junio?
Linus
^ permalink raw reply
* RE: Git vs Monotone
From: Linus Torvalds @ 2008-07-31 19:52 UTC (permalink / raw)
To: Craig L. Ching; +Cc: sverre, Git Mailinglist
In-Reply-To: <63BEA5E623E09F4D92233FB12A9F79430238A5EC@emailmn.mqsoftware.com>
On Thu, 31 Jul 2008, Craig L. Ching wrote:
>
> It's possible he's doing that, but it's also possible he just isn't that
> familiar with git.
Possible. But it really sounded like he didn't even try. Because quite
frankly, if he had even bothered to _try_, he wouldn't have gotten the
numbers he got.
The fact is, even without "-s", a local clone will do hardlinks for the
database. And since the original pack-file is marked as a 'keep' file,
that original pack-file won't even be broken apart.
So literally, if he had just bothered to even _try_ the git setup, he'd
have noticed that git actually uses less disk than monotone would do. But
it sounds like he didn't even try it.
So completely ignoring the fact that you could do a single database with
git, and completely ignoring the fact that with git you'd probably use
branches for at least some of those 11 repos anyway, he'd _still_ have had
less disk space used by git unless he would do something intentionally odd
(like clone all the repositories over the network separately).
Linus
^ permalink raw reply
* Monotone workflow compared to Git workflow ( was RE: Git vs Monotone)
From: Craig L. Ching @ 2008-07-31 19:48 UTC (permalink / raw)
To: Linus Torvalds, sverre; +Cc: Git Mailinglist
In-Reply-To: <alpine.LFD.1.10.0807311211260.3277@nehalem.linux-foundation.org>
> -----Original Message-----
> From: git-owner@vger.kernel.org
> [mailto:git-owner@vger.kernel.org] On Behalf Of Linus Torvalds
> Sent: Thursday, July 31, 2008 2:18 PM
> single database for git, but wants to force a full clone for
> each. Not to mention that in git, you'd normally not do 11
> clones to begin with, you'd just do 11 branches in one repo.
>
I have a question about this. I asked this awhile back and didn't
really get any satisfactory answers except to use git-new-workdir, which
makes git behave a lot like monotone. In our workflow, we do create
branches for nearly everything, but we do find that we have a need to
keep the build artifacts of those branches isolated from each other
because rebuilding is expensive. IOW, we have this sort of workflow:
git checkout A
[work on A, build, test, do some commits]
git checkout B
[work on B, build, test, do some commits]
git checkout A
[work on A, re-build, test, do some commits]
We find ourselves constantly having to shift gears and work on other
things in the middle of whatever it is we're currently working on. For
instance, in the scenario above, A might be branch that contains a
feature going into our next release. B might be a bugfix and takes
priority over A, so you have to leave A as-is and start work on B. When
I come back to work on A, I have to rebuild A to continue working, and
that's just too expensive for us. So we use the monotone-like
new-workdir which allows us to save those build artifacts.
So, that said, I ask again, am I missing something? Is there a better
way to do this? How do the kernel developers do this, surely they're
switching branches back and forth having to build in-between?
> Linus
> --
> To unsubscribe from this list: send the line "unsubscribe
> git" in the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Cheers,
Craig
^ permalink raw reply
* Re: [PATCH 0/2] gitweb use sections
From: Gustavo Sverzut Barbieri @ 2008-07-31 19:43 UTC (permalink / raw)
To: git; +Cc: Petr Baudis, Jakub Narebski
In-Reply-To: <1217298868-16513-1-git-send-email-barbieri@profusion.mobi>
Since nobody replied and I missed some gitweb guys in CC, I'm adding
Petr and Jakub, as some guys said on IRC.
Have anyone tried this patch, any problems?
On Mon, Jul 28, 2008 at 11:34 PM, Gustavo Sverzut Barbieri
<barbieri@profusion.mobi> wrote:
> The following two patches will add sections to gitweb so usability is
> improved for large project listing. It looks like:
>
> http://staff.get-e.org/
>
> but it's a new code that also supports owner sort.
>
> Patches orverview:
>
> * [PATCH 1/2] gitweb: sort projects by path.
> This one is required to fix project sort. Since we use paths, we
> should compare individual components to make it look like a
> tree. Since we now can enable sections this error will be more
> evident, so there is the fix.
>
> * [PATCH 2/2] gitweb: add section support to gitweb project listing.
> The real section work. This will add use_sections variable and if
> it evaluates to true sections will be enabled. Just project and
> owner sections are implemented.
>
> I hope it looks good for inclusion. Last time I did perl was about 8
> years ago, please point any problems and I'll fix them.
>
>
> --
> Gustavo Sverzut Barbieri
> http://profusion.mobi embedded systems
> --------------------------------------
> MSN: barbieri@gmail.com
> Skype: gsbarbieri
> Mobile: +55 (19) 9225-2202
>
>
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--------------------------------------
MSN: barbieri@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
^ permalink raw reply
* RE: Git vs Monotone
From: Craig L. Ching @ 2008-07-31 19:28 UTC (permalink / raw)
To: Linus Torvalds, sverre; +Cc: Git Mailinglist
In-Reply-To: <alpine.LFD.1.10.0807311211260.3277@nehalem.linux-foundation.org>
> [mailto:git-owner@vger.kernel.org] On Behalf Of Linus Torvalds
> Sent: Thursday, July 31, 2008 2:18 PM
> Subject: Re: Git vs Monotone
>
> On Thu, 31 Jul 2008, Sverre Rabbelier wrote:
> >
> The guy is apparently happy using a single database for
> monotone (which apparently has a database that is two times
> the size of the git one), but then doesn't want to use a
> single database for git, but wants to force a full clone for
> each. Not to mention that in git, you'd normally not do 11
> clones to begin with, you'd just do 11 branches in one repo.
>
Having come from monotone to git recently, I have to say that it isn't
immediately obvious how you get the single database for git a la
monotone (with remotes that point to the right place, etc.). At first,
I also thought that you didn't share the object database on clones and I
had to discover that myself. It's possible that I'm just an idiot too
;-)
> So there is no point discussing things with people like that.
> If he wants to skew things in monotone's favor, he can do it.
> Let him.
>
It's possible he's doing that, but it's also possible he just isn't that
familiar with git.
> Linus
> --
Cheers,
Craig
^ permalink raw reply
* Re: Git vs Monotone
From: Theodore Tso @ 2008-07-31 19:24 UTC (permalink / raw)
To: sverre; +Cc: Git Mailinglist
In-Reply-To: <bd6139dc0807311113n50dda9f0t1aab46b724510de2@mail.gmail.com>
On Thu, Jul 31, 2008 at 08:13:59PM +0200, Sverre Rabbelier wrote:
>
> I just read this blog post [0] in which one of the Pidgin devs sheds
> his light on their 'tool choice'. In the post he mentions the
> following figures:
The main thing this proves was that the Pidgin devs were most familiar
with Monotone, and weren't sufficiently familiar with git; hence, they
didn't know how to do a fair comparison. First of all, sure, if they
are willing to use a single working directory and want to switch
between branches using "git checkout", that works well. But suppose
they really want separate working directories. The simplist and
easist way is to use "git clone -s".
So if they do:
git clone git://github.com/felipec/pidgin-clone.git pidgin
git clone -s pidgin clone-1
git clone -s pidgin clone-2
git clone -s pidgin clone-3
git clone -s pidgin clone-4
git clone -s pidgin clone-5
git clone -s pidgin clone-6
git clone -s pidgin clone-7
git clone -s pidgin clone-8
git clone -s pidgin clone-9
git clone -s pidgin clone-10
The net disk usage is 746 megabytes, as compared to the 900 megabytes
claimed in the blog post. The main difference is the git database is
only takes 87 megabytes, compared to the 229 megabytes for the
Monotone database. The main issue is the pidgin developers simply
didn't know how to use the -s flag so they didn't need to duplicate
the git database for every single clone.
Shrug; whatever, I've always said the biggest issue for any tool is
what the developers are familiar with. It may be that monotone was
the right choice for the pidgin core developers, if they weren't
familiar enough with git.
- Ted
^ permalink raw reply
* Re: Git vs Monotone
From: Linus Torvalds @ 2008-07-31 19:17 UTC (permalink / raw)
To: sverre; +Cc: Git Mailinglist
In-Reply-To: <bd6139dc0807311113n50dda9f0t1aab46b724510de2@mail.gmail.com>
On Thu, 31 Jul 2008, Sverre Rabbelier wrote:
>
> I just read this blog post [0] in which one of the Pidgin devs sheds
> his light on their 'tool choice'. In the post he mentions the
> following figures:
Don't even bother. The guy is apparently not even trying to work with his
tools, he just has an agenda to push.
Quite frankly, anybody who wants to stay with monotone, we should
_encourage_ them. They add nothing to any possible project, because they
are clearly not very intelligent.
The guy is apparently happy using a single database for monotone (which
apparently has a database that is two times the size of the git one), but
then doesn't want to use a single database for git, but wants to force a
full clone for each. Not to mention that in git, you'd normally not do 11
clones to begin with, you'd just do 11 branches in one repo.
So there is no point discussing things with people like that. If he wants
to skew things in monotone's favor, he can do it. Let him.
Linus
^ permalink raw reply
* Re: Git vs Monotone
From: Sverre Rabbelier @ 2008-07-31 19:19 UTC (permalink / raw)
To: Jeff King, Craig L. Ching, Petr Baudis, Stephen R. van den Berg
Cc: Git Mailinglist
In-Reply-To: <20080731190209.GA8372@sigill.intra.peff.net>
On Thu, Jul 31, 2008 at 21:02, Jeff King <peff@peff.net> wrote:
> and the _whole thing_ is 148M, including the working tree. His object db
> is only 88M. So he can do his 11 trees in 61 * 11 + 88 = 759M, saving
> 141M over monotone.
Yeah, that's rather unfair indeed, counting that way he'd have to add
the 229MB for the Monotone db too ;).
> And I am repacking with insane depth and window right now to see if we
> can get it smaller (though really, it is not that big a deal, since the
> size is dominated by his 11 working trees).
I repacked with --depth=100 and --window=100, I tried out 500 at first
but it was just insanely slow (on a VM with one 2.4Ghz Core
available). This resulted in a .git dir of 76MB. With that dir I did
the following:
$mkdir pidgins
$git clone --no-hardlinks --bare pidgin pidgin-bare
$mv pidgin-bare pidgins
$cd pidgins
$for i in 1 2 3 4 5 6 7 8 9 10 11; do git clone pidgin-bare pidgin$i; done
$ du -sh .
742M .
So... monotone, eat your heart out ;).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* RE: Git vs Monotone
From: Craig L. Ching @ 2008-07-31 19:11 UTC (permalink / raw)
To: Jeff King, sverre; +Cc: Git Mailinglist
In-Reply-To: <20080731190209.GA8372@sigill.intra.peff.net>
> -----Original Message-----
> From: git-owner@vger.kernel.org
> [mailto:git-owner@vger.kernel.org] On Behalf Of Jeff King
> Sent: Thursday, July 31, 2008 2:02 PM
> To: sverre@rabbelier.nl
> Cc: Git Mailinglist
> Subject: Re: Git vs Monotone
>
> On Thu, Jul 31, 2008 at 08:13:59PM +0200, Sverre Rabbelier wrote:
>
> > If I clone the git mirror of our monotone repository, I find a
> > checkout size of 148 MB after git-repack--running git-gc also
> > increased the size by 2 MB, but I'll stick with the initial
> checkout
> > size for fairness. If I multiply this by my 11 checkouts, I
> will have
> > 1628 MB. This is even more compelling for me, as I now save
> 728 MB of
> > disk space with monotone."
>
> Yikes. This is not even remotely a fair comparison to
> monotone, which is keeping a central db.
>
I think it is a fair comparison, but as you point out, the author is
doing the comparison wrong. Monotone's "central db" (as you call it) is
really equivalent to git's object database.
> > I'm in the process of cloning the repo myself, and will
> check if doing
> > a more aggressive (high --window and --depth values) repack
> will get
> > us below that 148, but I'm thinking it's just that big a
> repo. Anyway,
>
> It's much better than that. I just cloned
>
> git://github.com/felipec/pidgin-clone.git
>
> and the _whole thing_ is 148M, including the working tree.
> His object db is only 88M. So he can do his 11 trees in 61 *
> 11 + 88 = 759M, saving 141M over monotone.
>
Right, that's been my experience too, that git is smaller than monotone.
The author just needs to compare eqivalent concepts ;-)
> -Peff
> --
Cheers,
Craig
^ permalink raw reply
* [RFC] hash-object --no-filters
From: Dmitry Potapov @ 2008-07-31 19:09 UTC (permalink / raw)
To: git; +Cc: Alexander Litvinov
In-Reply-To: <20080731104529.GE7008@dpotapov.dyndns.org>
Hi All,
I am tryint to add the --no-filters option. It is useful for git-svn
and other importers that want to add file as-is without being affected
by any filter (in particular, autocrlf). Though, the patch below works,
I am not happy with the hackish way of passing no-filter requirement
to the index_fd() function. So, I wonder what would be preferable:
- to change 'write_object' to be flags (bit 0: write_object,
bit 1: no-filters )
- to add some global the no_filters flag to environment.c, which can
be checked inside of convert_to_git(), so it may be used in the
future in some other cases (though I don't see where else it can
be useful).
Another question: currently git hash-object --input imply no filters.
I don't know if it was done intentionally (it can be argued in both
ways). I don't think it is reasonable now to change this behavior,
so I want to add just one line to documentation, so there will be
no surprise among users.
Dmitry
-- 8< --
From: Dmitry Potapov <dpotapov@gmail.com>
Date: Thu, 31 Jul 2008 21:10:26 +0400
Subject: [PATCH] hash-object --no-filters
The --no-filters option makes git hash-object to work as there were no
input filters. This option is useful for importers such as git-svn to
put new version of files as is even if autocrlf is set.
---
Documentation/git-hash-object.txt | 6 ++++++
hash-object.c | 7 ++++++-
2 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-hash-object.txt b/Documentation/git-hash-object.txt
index ac928e1..69a17c7 100644
--- a/Documentation/git-hash-object.txt
+++ b/Documentation/git-hash-object.txt
@@ -35,6 +35,12 @@ OPTIONS
--stdin-paths::
Read file names from stdin instead of from the command-line.
+--no-filters::
+ If this option is given then the file is hashed as is ignoring
+ all filters specified in the configuration, including crlf
+ conversion. If the file is read from standard input then no
+ filters is always implied.
+
Author
------
Written by Junio C Hamano <gitster@pobox.com>
diff --git a/hash-object.c b/hash-object.c
index 46c06a9..1e7fe8a 100644
--- a/hash-object.c
+++ b/hash-object.c
@@ -8,6 +8,8 @@
#include "blob.h"
#include "quote.h"
+static unsigned no_filters;
+
static void hash_object(const char *path, enum object_type type, int write_object)
{
int fd;
@@ -16,7 +18,8 @@ static void hash_object(const char *path, enum object_type type, int write_objec
fd = open(path, O_RDONLY);
if (fd < 0 ||
fstat(fd, &st) < 0 ||
- index_fd(sha1, fd, &st, write_object, type, path))
+ ((no_filters ? st.st_mode &= ~S_IFREG : 0),
+ index_fd(sha1, fd, &st, write_object, type, path)))
die(write_object
? "Unable to add %s to database"
: "Unable to hash %s", path);
@@ -104,6 +107,8 @@ int main(int argc, char **argv)
die("Multiple --stdin arguments are not supported");
hashstdin = 1;
}
+ else if (!strcmp(argv[i], "--no-filters"))
+ no_filters = 1;
else
usage(hash_object_usage);
}
--
1.6.0.rc1.32.gc84cb
^ permalink raw reply related
* RE: git-p4, msysgit, and strange behavior
From: Blum, Robert @ 2008-07-31 19:03 UTC (permalink / raw)
To: Stephen R. van den Berg; +Cc: git@vger.kernel.org
In-Reply-To: <20080731183641.GB31085@cuci.nl>
Hi Stephen!
> greetings from RWTH-Aachen ;-).
Heh - wonder who else from back then is lingering on those lists ;)
>Checked the environment? I vaguely recall that p4 has some "magical
dependencies" there.
Yes, did that - 'p4 set' prints all relevant environment vars, and they seem to be set correctly.
You set me off on a slightly longer search, though. And indeed, here's the answer to the mystery (for the benefit of google/later readers).
Git-bash sets $PWD to your current working directory, and that variable is not affected by python's os.chdir(). (Neither in 2.5 nor 2.4, at least)
P4, for strange reasons, decides that that takes precedence over the actual working directory.
Well, actually not that strange. If p4 is using libiberty, they're using a version of getpwd that assumes that PWD is always up to date and no chdirs occur between calls to getpwd. I'm sure there was a good reason for that, but I really can't think why anybody would want to implement getpwd that way...
I'll create a patch for git-p4, but it's really up to P4 to actually *fix* that mess...
- Robert
^ permalink raw reply
* Re: Merging submodules
From: Santi Béjar @ 2008-07-31 19:03 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: Petr Baudis, Brian Gernhardt, Git List, Lars Noschinski
In-Reply-To: <20080731201530.067be667@pc09.procura.nl>
On Thu, Jul 31, 2008 at 20:15, H.Merijn Brand <h.m.brand@xs4all.nl> wrote:
> On Thu, 31 Jul 2008 17:24:40 +0200, "Santi Béjar" <sbejar@gmail.com>
> wrote:
>
>> I see all OK. Can you provide a self consistent simple testcase that
>> shows what is wrong?
>
> Yes. was rather easy.
> http://www.xs4all.nl/~hmbrand/testcase.tgz
>
It is because you cannot merge a branch with an empty branch. So, or
you create an initial commit in the "superproject" or you create a
commit just moving the files of the first module as in:
http://article.gmane.org/gmane.comp.version-control.git/79887
Santi
^ permalink raw reply
* Re: Git vs Monotone
From: Jeff King @ 2008-07-31 19:02 UTC (permalink / raw)
To: sverre; +Cc: Git Mailinglist
In-Reply-To: <bd6139dc0807311113n50dda9f0t1aab46b724510de2@mail.gmail.com>
On Thu, Jul 31, 2008 at 08:13:59PM +0200, Sverre Rabbelier wrote:
> If I clone the git mirror of our monotone repository, I find a
> checkout size of 148 MB after git-repack--running git-gc also
> increased the size by 2 MB, but I'll stick with the initial checkout
> size for fairness. If I multiply this by my 11 checkouts, I will have
> 1628 MB. This is even more compelling for me, as I now save 728 MB of
> disk space with monotone."
Yikes. This is not even remotely a fair comparison to monotone, which is
keeping a central db.
> I'm in the process of cloning the repo myself, and will check if doing
> a more aggressive (high --window and --depth values) repack will get
> us below that 148, but I'm thinking it's just that big a repo. Anyway,
It's much better than that. I just cloned
git://github.com/felipec/pidgin-clone.git
and the _whole thing_ is 148M, including the working tree. His object db
is only 88M. So he can do his 11 trees in 61 * 11 + 88 = 759M, saving
141M over monotone.
And I am repacking with insane depth and window right now to see if we
can get it smaller (though really, it is not that big a deal, since the
size is dominated by his 11 working trees).
-Peff
^ permalink raw reply
* Re: markdown 2 man, was Re: Git Community Book
From: Miklos Vajna @ 2008-07-31 19:00 UTC (permalink / raw)
To: Abdelrazak Younes
Cc: git, Johannes Schindelin, Julian Phillips, Scott Chacon,
Petr Baudis
In-Reply-To: <4891DA49.2070407@lyx.org>
[-- Attachment #1: Type: text/plain, Size: 645 bytes --]
On Thu, Jul 31, 2008 at 05:29:13PM +0200, Abdelrazak Younes <younes@lyx.org> wrote:
> I understand that but my point is that writing a book or a manual is too
> big a task for a wiki.
That's probably subjective. There is http://wikibooks.org/, after all.
;-)
> Anyway, if there is an interest to switch to LyX for the user manual, just
> let me know. Ascii has a LateX backend* and LyX can import LateX so the
> task should be easy.
>
> * http://www.methods.co.nz/asciidoc/latex-backend.html
Last time I checked it was actually broken, but dblatex can transform
asciidoc's docbook output to latex, if that's really wished.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linking libgit.a in C++ projects
From: Avery Pennarun @ 2008-07-31 18:55 UTC (permalink / raw)
To: Alex Riesen; +Cc: Boaz Harrosh, cte, git
In-Reply-To: <20080731183732.GA7598@steel.home>
On 7/31/08, Alex Riesen <raa.lkml@gmail.com> wrote:
> Boaz Harrosh, Thu, Jul 31, 2008 15:04:50 +0200:
> > Produce a C file and header that defines some stable API to your
> > GUI application, that does not expose any git internal headers.
> > Then compile that, say git_api.c, with C compiler in Makefile
> > and extern "C" link that file to your C++ application. This will
> > completely insulate you from any git code.
>
> no, it wont. He still have to resolve name conflicts at the link time.
Language keywords (as opposed to function names) like 'new' and
'typename' are definitely not exported to the object files. Moreover,
function parameter names aren't either.
Avery
^ permalink raw reply
* Re: Git vs Monotone
From: Petr Baudis @ 2008-07-31 18:52 UTC (permalink / raw)
To: Stephen R. van den Berg; +Cc: Sverre Rabbelier, Git Mailinglist
In-Reply-To: <20080731183317.GA31085@cuci.nl>
On Thu, Jul 31, 2008 at 08:33:17PM +0200, Stephen R. van den Berg wrote:
> Sverre Rabbelier wrote:
> >If I clone the git mirror of our monotone repository, I find a
> >checkout size of 148 MB after git-repack--running git-gc also
> >increased the size by 2 MB, but I'll stick with the initial checkout
> >size for fairness. If I multiply this by my 11 checkouts, I will have
> >1628 MB. This is even more compelling for me, as I now save 728 MB of
> >disk space with monotone."
>
> You have at least two options to reduce diskspace:
> a. Clone once from remote, then clone from that clone, it should
> hardlink the larger packfiles to the initial clone and therefore not
> cost you a lot.
> b. Clone once from remote, and create 11 branches inside the new cloned
> repo. Switch branches while doing development.
>
> Most git users pick b. It's easier to work with. Having 11 unpacked
> repos means that all the object files in those trees are almost up to
> date, but it adds to the complexity of comparing changes and merging
> changes between branches. The compilation speed can be increased with
> ccache if need be.
c. Still clone from the remote, but set up alternates to a single
local "reference repository". Then all common objects will be stored
only once in this reference repository. The advantage to (a) is that
your remotes are actually set up sensibly.
(Note that the blog post talks about .git + checkout sizes, in case
someone got confused like I did, counting only .git. :-)
--
Petr "Pasky" Baudis
As in certain cults it is possible to kill a process if you know
its true name. -- Ken Thompson and Dennis M. Ritchie
^ 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