* Re: markdown 2 man, was Re: Git Community Book
From: Miklos Vajna @ 2008-07-31 15:09 UTC (permalink / raw)
To: Abdelrazak Younes
Cc: git, Johannes Schindelin, Julian Phillips, Scott Chacon,
Petr Baudis
In-Reply-To: <4891CD34.1070308@lyx.org>
[-- Attachment #1: Type: text/plain, Size: 616 bytes --]
On Thu, Jul 31, 2008 at 04:33:24PM +0200, Abdelrazak Younes <younes@lyx.org> wrote:
> I just had a look at the user manual and, well unless you have a special
> emacs mode or whatever that can automate the markup tag insertion, I wonder
> how can anybody think that writing with this markup language is easier than
> within LyX, really (genuine question, not sarcasm).
People usually find it easy to contribute to a wiki, due to its easy
markup language.
asciidoc's markup is configurable, but the default one is really similar
to a wiki syntax, so at the end, people find it easy, including myself.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Merging submodules
From: Santi Béjar @ 2008-07-31 15:24 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: Petr Baudis, Brian Gernhardt, Git List, Lars Noschinski
In-Reply-To: <20080731170123.79e0d3e9@pc09.procura.nl>
On Thu, Jul 31, 2008 at 17:01, H.Merijn Brand <h.m.brand@xs4all.nl> wrote:
> On Thu, 31 Jul 2008 15:06:26 +0200, Petr Baudis <pasky@suse.cz> wrote:
>
>> On Thu, Jul 31, 2008 at 02:39:55PM +0200, H.Merijn Brand wrote:
>> >
>> > There is a slight problem with this merging approach. The path names
>> > are as they are/were in the submodules. In module_a, foo.pl was without
>> > a leading module_a/ path, and now after integration, it still is. Is it
>> > possible to rethink this whole process that integrates/merges the
>> > several git repo's in subfolders into the current folder, as-if they
>> > would have been in this folder in the first place?
>>
>> I would suggest re-reading Santi's suggestions:
>>
>> > You have, basically, two possibilities:
>> >
>> > 1) Add the module_# as submodules:
>> > http://www.kernel.org/pub/software/scm/git/docs/git-submodule.html
>> > http://git.or.cz/gitwiki/GitSubmoduleTutorial
>> > 2) Add the submodules as subtrees (as gitk and git-gui in git.git)
>> > http://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html
>>
>> I think the latter is specifically what you want.
>
> I got stuck in that process, as the new repo thinks all the files from
> the sub-folders belong to the top-folder: After this process, there are
> a lot of files from subfolder include in the "new" top-level folder.
>
I see all OK. Can you provide a self consistent simple testcase that
shows what is wrong?
# prepare the project and the modules
mkdir project
cd project
git init
...
mkdir module_a
cd module_a
git init
...
# your script
# show what you get and what you expect, for example:
$ git show HEAD: # or something equivalent
$ ls
$ git status
...
> --8<--- git-join.sh
> #!/bin/sh
>
> export MODS
> MODS="include fnc"
> MODS="$MODS i00f000 i99f000"
> MODS="$MODS l00m000 l01f000 l02f000 l03f000 l06f000 l90z000"
> MODS="$MODS rpt"
> MODS="$MODS leerpl mutbev prtabel tabellen zoomen"
>
> echo "Creating merge environment"
> rm -rf new
> mkdir new
> cd new
>
> echo "Recovering original repo's"
> tbz -s -x ../lep4gl-git
>
> echo "Initializing new repo"
> git init
>
> for mod in $MODS ; do
> echo "Merging $mod ..."
> git remote add -f B$mod $mod
> git merge -s ours --no-commit B$mod/master
> git read-tree --prefix=$mod/ -u B$mod/master
> git commit -m "Merge $mod as our subdirectory"
> git pull -s subtree B$mod master
This is only needed when updating the subtree if the module has been
updated (but it should do nothing in you case).
> done
>
> echo Done
> -->8---
Santi
^ permalink raw reply
* Re: markdown 2 man, was Re: Git Community Book
From: Abdelrazak Younes @ 2008-07-31 15:29 UTC (permalink / raw)
To: Miklos Vajna
Cc: git, Johannes Schindelin, Julian Phillips, Scott Chacon,
Petr Baudis
In-Reply-To: <20080731150958.GO32057@genesis.frugalware.org>
Hi Miklos,
Miklos Vajna wrote:
> On Thu, Jul 31, 2008 at 04:33:24PM +0200, Abdelrazak Younes<younes@lyx.org> wrote:
>
>> I just had a look at the user manual and, well unless you have a special
>> emacs mode or whatever that can automate the markup tag insertion, I wonder
>> how can anybody think that writing with this markup language is easier than
>> within LyX, really (genuine question, not sarcasm).
>>
>
> People usually find it easy to contribute to a wiki, due to its easy
> markup language.
>
I understand that but my point is that writing a book or a manual is too
big a task for a wiki.
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
Thanks for answering :-)
Abdel.
^ permalink raw reply
* Git vs Monotone
From: Sverre Rabbelier @ 2008-07-31 18:13 UTC (permalink / raw)
To: Git Mailinglist
Heya,
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:
"I don't mind the database, myself. I have 11 working copies
(checkouts) from my single pidgin database (8 distinct branches, plus
duplicates of the last three branches I worked on or tested with).
Each clean checkout (that is, a checkout prior to running autogen.sh
and building) is approximately 61 MB. If this were SVN, each working
copy would be approximately 122 MB due to svn keeping a pristine copy
of every file to facilitate 'svn diff' and 'svn revert' without
needing to contact the server the working copy was pulled from. Now,
let's add that up. For SVN, I would have 11 times 122 MB, or 1342 MB,
just in working copies. For monotone, I have 11 times 61 MB for the
working copies (671 MB), plus 229 MB for the database, for a grand
total of 900 MB. For me, this is an excellent bargain, as I save 442
MB of disk space thanks to the monotone model. For another compelling
comparison that's sure to ruffle a few feathers, let's compare to git.
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."
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 seems git is getting screwed over in this post because he is not
taking advantage of git's object-database-sharing capabilities. Am i
right in thinking that with git-new-workdir we would end up at
61*11+148 = 819MB? (Which would actually put us below monotone by
80MB.) Not that I care much whether monotone or git is smaller in disk
size, I'm just curious if we indeed offer this capability? Perhaps
someone with more knowledge of git-new-workdir could shed a light?
[0] http://theflamingbanker.blogspot.com/2008/07/holy-war-of-tool-choice.html
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Merging submodules
From: H.Merijn Brand @ 2008-07-31 18:15 UTC (permalink / raw)
To: Santi Béjar; +Cc: Petr Baudis, Brian Gernhardt, Git List, Lars Noschinski
In-Reply-To: <8aa486160807310824h25c9630dxc25b156e80fcdb29@mail.gmail.com>
On Thu, 31 Jul 2008 17:24:40 +0200, "Santi Béjar" <sbejar@gmail.com>
wrote:
> On Thu, Jul 31, 2008 at 17:01, H.Merijn Brand <h.m.brand@xs4all.nl> wrote:
> > On Thu, 31 Jul 2008 15:06:26 +0200, Petr Baudis <pasky@suse.cz> wrote:
> >
> >> On Thu, Jul 31, 2008 at 02:39:55PM +0200, H.Merijn Brand wrote:
> >> >
> >> > There is a slight problem with this merging approach. The path names
> >> > are as they are/were in the submodules. In module_a, foo.pl was without
> >> > a leading module_a/ path, and now after integration, it still is. Is it
> >> > possible to rethink this whole process that integrates/merges the
> >> > several git repo's in subfolders into the current folder, as-if they
> >> > would have been in this folder in the first place?
> >>
> >> I would suggest re-reading Santi's suggestions:
> >>
> >> > You have, basically, two possibilities:
> >> >
> >> > 1) Add the module_# as submodules:
> >> > http://www.kernel.org/pub/software/scm/git/docs/git-submodule.html
> >> > http://git.or.cz/gitwiki/GitSubmoduleTutorial
> >> > 2) Add the submodules as subtrees (as gitk and git-gui in git.git)
> >> > http://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html
> >>
> >> I think the latter is specifically what you want.
> >
> > I got stuck in that process, as the new repo thinks all the files from
> > the sub-folders belong to the top-folder: After this process, there are
> > a lot of files from subfolder include in the "new" top-level folder.
> >
>
> 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
test 133 > ll *
23875989 -rwxr-xr-x 1 merijn users 486 2008-07-31 20:08 git-join.sh
23875990 -rw-rw-rw- 1 merijn users 14385 2008-07-31 20:07 test-git.tgz
4gl:
total 16
23871493 drwxrwxrwx 4 merijn users 4096 2008-07-31 20:01 .
23871492 drwxrwxrwx 3 merijn users 4096 2008-07-31 20:08 ..
23871494 drwxrwxrwx 3 merijn users 4096 2008-07-31 19:56 fnc
23875966 drwxrwxrwx 3 merijn users 4096 2008-07-31 20:04 include
test 134 > bash git-join.sh
Creating merge environment
Recovering original repo's
Initializing new repo
Initialized empty Git repository in /work/lep/test/new/.git/
Merging include ...
Updating Binclude
remote: Counting objects: 9, done.
remote: Compressing objects: 100% (5/5), done.
remote: Total 9 (delta 1), reused 6 (delta 1)
Unpacking objects: 100% (9/9), done.
From include
* [new branch] master -> Binclude/master
Created commit c2c491e: Merge include as our subdirectory
1 files changed, 4 insertions(+), 0 deletions(-)
create mode 100644 include/ini0.h
From include
* branch master -> FETCH_HEAD
Already up-to-date.
Merging fnc ...
Updating Bfnc
warning: no common commits
remote: Counting objects: 12, done.
remote: Compressing objects: 100% (4/4), done.
Unpacking objects: 100% (12/12), done.
remote: Total 12 (delta 0), reused 9 (delta 0)
From fnc
* [new branch] master -> Bfnc/master
Automatic merge went well; stopped before committing as requested
Created commit d7da4d6: Merge fnc as our subdirectory
From fnc
* branch master -> FETCH_HEAD
Already up-to-date.
Done
test 135 > ll new
total 24
23887892 drwxrwxrwx 5 merijn users 4096 2008-07-31 20:11 .
23871492 drwxrwxrwx 4 merijn users 4096 2008-07-31 20:11 ..
23887973 drwxrwxrwx 8 merijn users 4096 2008-07-31 20:11 .git
23887893 drwxrwxrwx 3 merijn users 4096 2008-07-31 20:11 fnc
23887933 drwxrwxrwx 3 merijn users 4096 2008-07-31 20:11 include
23888029 -rw-rw-rw- 1 merijn users 56 2008-07-31 20:11 ini0.h
test 136 > ll new/include/
total 16
23887933 drwxrwxrwx 3 merijn users 4096 2008-07-31 20:11 .
23887892 drwxrwxrwx 5 merijn users 4096 2008-07-31 20:11 ..
23887934 drwxrwxrwx 8 merijn users 4096 2008-07-31 20:04 .git
23888031 -rw-rw-rw- 1 merijn users 56 2008-07-31 20:11 ini0.h
test 137 >
What is ini0.h doing in new/ ?
test 137 > cd new
test/new 138 > git-ls-files
fnc/foo.txt
include/ini0.h
ini0.h
test/new 139 >
--
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: linking libgit.a in C++ projects
From: Sverre Rabbelier @ 2008-07-31 18:27 UTC (permalink / raw)
To: cte; +Cc: Dmitry Potapov, git
In-Reply-To: <ac9f0f090807310410u461f5584ved74769d8452c539@mail.gmail.com>
On Thu, Jul 31, 2008 at 13:10, cte <cestreich@gmail.com> wrote:
> I'm not worried about the interfaces changing; the gui is tied to a
> particular version of git, and I will update the code that calls into
> libgit I pull new changes from the mainline into my local clone.
You should be ;). Unless you are planning to learn a lot of C very
fast, you should be worried about the interfaces changing. That is, if
you want your GUI to be able to stay up to date with the current git
version.
> who's to say that the output of the various commands won't change
> formats with future releases of git?
Junio is to say. Plumbing output format is git's API.
> There is no correct solution if
> you are worried about forward compatibility, unless a well defined API
> is created (which would be sweet btw, but is probably not a priority).
There is, use the plumbing, forward compatibility is 95% assured. With
the exception of major releases, for which any plumbing
output/behavior changes will be announced in the changelog, usually
including an explanation on how to change your code to match.
In short, use the forc-... errr, plumbing ;).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* git-p4, msysgit, and strange behavior
From: Blum, Robert @ 2008-07-31 18:14 UTC (permalink / raw)
To: git@vger.kernel.org
Hi guys!
I've recently been evaluating DVCS's for work. (Actually, who am I kidding - I love working w/ DVCS and want to convince my bosses to move forward ;)
Since we're a Perforce & Windows shop, git-p4 and msysgit are mandatory. However, I've run into a strange bug. Running git-p4 submit, I always get the message '... - file(s) not in client view'. Yes, I've checked - the files are in the client view, the view is set up properly, talking to the correct server. This only occurs if I'm in any of the directories of the git repository. If I switch to the directories where the P4 data is synced to and use --git-origin, the submit works just fine.
After a bit of digging on the ML, I found http://marc.info/?l=git&m=120437559322494&w=3 and the thread related to it. And yes, indeed, changing all p4 calls like this:
system("p4 sync ...") --> system("p4 sync %s..." % self.clientPath)
makes the problem go away. I've spent some time debugging the issue, and as far as I can tell, the working dir is set correctly during system(), the p4 environment is set correctly - and yet p4 complains.
As far as I know, I've grabbed the latest git & git-p4 from repo.or.cz. Is this a known problem? Should I clean up & submit the patch, or has anybody investigated a bit more why this is failing? (I don't like the patch because I don't understand *why* p4 fails to behave properly)
Help appreciated,
- Robert
^ permalink raw reply
* Re: Git vs Monotone
From: Stephen R. van den Berg @ 2008-07-31 18:33 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Git Mailinglist
In-Reply-To: <bd6139dc0807311113n50dda9f0t1aab46b724510de2@mail.gmail.com>
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.
--
Sincerely,
Stephen R. van den Berg.
"There are three types of people in this world: those who make things happen,
those who watch things happen and those who wonder what happened."
^ permalink raw reply
* Re: linking libgit.a in C++ projects
From: Alex Riesen @ 2008-07-31 18:37 UTC (permalink / raw)
To: Boaz Harrosh; +Cc: cte, git
In-Reply-To: <4891B872.3040707@panasas.com>
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.
^ permalink raw reply
* Re: git-scm.com
From: Jon Loeliger @ 2008-07-31 18:39 UTC (permalink / raw)
To: Tom Werner; +Cc: git
In-Reply-To: <530345950807281112w45215c16k49ffe240d41c6a9e@mail.gmail.com>
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?
jdl
^ 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
* 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: 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: 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: 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-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
* [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 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
* 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: 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: 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: 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: [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
* 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: 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
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