* 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: 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: 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 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
* 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: 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
* 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
* 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: 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
* 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: 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: H.Merijn Brand @ 2008-07-31 15:01 UTC (permalink / raw)
To: Petr Baudis; +Cc: Brian Gernhardt, Git List, Lars Noschinski
In-Reply-To: <20080731130626.GQ32184@machine.or.cz>
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:
> > On Thu, 31 Jul 2008 09:21:04 +0200, "H.Merijn Brand"
> > <h.m.brand@xs4all.nl> wrote:
> >
> > > I will now be playing with the results a bit. I have attached the
> > > script, in case you might want to use it in documentation or examples.
> > > For now, all the mods are hardcoded. No arguments and so on.
> > >
> > > Again, Thanks!
> >
> > 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.
--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
done
echo Done
-->8---
--
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: Dmitry Potapov @ 2008-07-31 14:44 UTC (permalink / raw)
To: Boaz Harrosh; +Cc: cte, git
In-Reply-To: <4891B872.3040707@panasas.com>
On Thu, Jul 31, 2008 at 04:04:50PM +0300, Boaz Harrosh wrote:
>
> 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.
While the idea of creating of such a wrapper makes sense, it may not
easy to implement properly in all cases, because some git functions
do not free allocated memory as they rely on this memory being free
at exit. There is a problem with die() as it is not enough to longjmp
from it, you have to free all resources that were allocated (such as
open files, memory). Thus writing a full functional library, which
will not leak resources, is not an easy task. Of course, some of Git
function can be used easily without risk that your application will
leak resources.
Dmitry
^ permalink raw reply
* Re: markdown 2 man, was Re: Git Community Book
From: Abdelrazak Younes @ 2008-07-31 14:33 UTC (permalink / raw)
To: git; +Cc: git, Johannes Schindelin, Julian Phillips, Scott Chacon,
Petr Baudis
In-Reply-To: <20080731130101.GC18106@leksak.fem-net>
Stephan Beyer wrote:
> They're "lightweight" markup for documentation, very easy to read and somehow
> easy to write for non-developers.
> The user manual can give you an impression:
> http://repo.or.cz/w/git.git?a=blob;f=Documentation/user-manual.txt
>
> I think, this is easier than LyX for users and developers..
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).
Abdel.
^ permalink raw reply
* Re: markdown 2 man, was Re: Git Community Book
From: Abdelrazak Younes @ 2008-07-31 14:13 UTC (permalink / raw)
To: Stephan Beyer
Cc: git, Johannes Schindelin, Julian Phillips, Scott Chacon,
Petr Baudis
In-Reply-To: <20080731130101.GC18106@leksak.fem-net>
Stephan Beyer wrote:
> Hi,
>
> Abdelrazak Younes wrote:
>
>> Please ignore if this is not appropriate.
>>
>
> Well, so I should've ignored, but I think this is worth some correction.
>
Thanks for the corrections :-)
> They're "lightweight" markup for documentation, very easy to read and somehow
> easy to write for non-developers.
> The user manual can give you an impression:
> http://repo.or.cz/w/git.git?a=blob;f=Documentation/user-manual.txt
>
> I think, this is easier than LyX for users and developers..
>
Well, easier for short document writing maybe, better suited I don't
think so, at least if you want to keep track of contents, structure,
links, references, citations, etc. Bug again this is IMHO.
Abdel.
^ permalink raw reply
* [PATCH] git-name-rev: allow --name-only in combination with --stdin
From: Pieter de Bie @ 2008-07-31 13:20 UTC (permalink / raw)
To: Git Mailinglist, Johannes Schindelin; +Cc: Pieter de Bie
Signed-off-by: Pieter de Bie <pdebie@ai.rug.nl>
---
Or was there a specific reason not to allow this?
Documentation/git-name-rev.txt | 3 +--
builtin-name-rev.c | 10 ++++++++--
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-name-rev.txt b/Documentation/git-name-rev.txt
index 6e77ab1..c8a72dd 100644
--- a/Documentation/git-name-rev.txt
+++ b/Documentation/git-name-rev.txt
@@ -38,8 +38,7 @@ OPTIONS
Instead of printing both the SHA-1 and the name, print only
the name. If given with --tags the usual tag prefix of
"tags/" is also omitted from the name, matching the output
- of 'git-describe' more closely. This option
- cannot be combined with --stdin.
+ of 'git-describe' more closely.
--no-undefined::
Die with error code != 0 when a reference is undefined,
diff --git a/builtin-name-rev.c b/builtin-name-rev.c
index 85612c4..0536af4 100644
--- a/builtin-name-rev.c
+++ b/builtin-name-rev.c
@@ -266,8 +266,14 @@ int cmd_name_rev(int argc, const char **argv, const char *prefix)
if (!name)
continue;
- fwrite(p_start, p - p_start + 1, 1, stdout);
- printf(" (%s)", name);
+ if (data.name_only) {
+ fwrite(p_start, p - p_start + 1 - 40, 1, stdout);
+ printf(name);
+ }
+ else {
+ fwrite(p_start, p - p_start + 1, 1, stdout);
+ printf(" (%s)", name);
+ }
p_start = p + 1;
}
}
--
1.6.0.rc1.163.gc85c5.dirty
^ permalink raw reply related
* Re: Merging submodules
From: Santi Béjar @ 2008-07-31 13:17 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: Brian Gernhardt, Git List, Lars Noschinski
In-Reply-To: <20080731143955.034f0577@pc09.procura.nl>
On Thu, Jul 31, 2008 at 14:39, H.Merijn Brand <h.m.brand@xs4all.nl> 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?
If you want to have module_a/foo.pl in the old commits you will need
to rewrite the history, either with "git filter-branch" or
fast-export/import, or importing again.
For the new commits it depends on how you would do them. If you modify
and commit without these module subfolders (without the module_a/.git
as your git-merge-mods does) then the new commits will have
module_a/foo.pl. So at the end you will have a merge of all the mods
(using the subtree strategy), and after that you will have a single
project.
All depends in a few factors, if you have published the history (for
the rewriting), if you want to have the module_# as independent
projects (this way you can merge them in other projects),...
Santi
^ permalink raw reply
* Re: Merging submodules
From: Petr Baudis @ 2008-07-31 13:06 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: Brian Gernhardt, Git List, Lars Noschinski
In-Reply-To: <20080731143955.034f0577@pc09.procura.nl>
On Thu, Jul 31, 2008 at 02:39:55PM +0200, H.Merijn Brand wrote:
> On Thu, 31 Jul 2008 09:21:04 +0200, "H.Merijn Brand"
> <h.m.brand@xs4all.nl> wrote:
>
> > I will now be playing with the results a bit. I have attached the
> > script, in case you might want to use it in documentation or examples.
> > For now, all the mods are hardcoded. No arguments and so on.
> >
> > Again, Thanks!
>
> 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.
--
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: Boaz Harrosh @ 2008-07-31 13:04 UTC (permalink / raw)
To: cte; +Cc: git
In-Reply-To: <ac9f0f090807310253v1d97e2a1n4ddf34aa4fdc79f0@mail.gmail.com>
cte wrote:
> I'm writing a git gui for OS X using cocoa/Objective-C++, and rather
> than being lame and parsing the output the various git commands, I'm
> using libgit.a to provide all of the needed functionality for my app.
> However, the git source uses a few reserved C++ keywords; namely
> 'typename', and 'new'. So, I was wondering if it is worth submitting a
> patch to fix these issues... I'm asking because I'm new to the whole
> open source thing, and I don't want to get yelled at by the git
> maintainers for submitting stupid patches that no one in their right
> mind would accept :)
>
> Thanks!
> --
The practice of avoiding C++ keywords from public C headers is
very welcome. You should send a patch and try to push it.
That said the problem can be easily avoided.
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.
This could also solve the other problem of API changing, only
the git_api.c need change, your outer GUI code stays the same.
And if you do all that maybe you can submit it for inclusion
as a: somewhat stable high-level library, for developers.
Ala git-dev
Cheers
Boaz
^ permalink raw reply
* Re: markdown 2 man, was Re: Git Community Book
From: Stephan Beyer @ 2008-07-31 13:01 UTC (permalink / raw)
To: Abdelrazak Younes
Cc: git, Johannes Schindelin, Julian Phillips, Scott Chacon,
Petr Baudis
In-Reply-To: <4891A0D0.6060503@lyx.org>
Hi,
Abdelrazak Younes wrote:
> Please ignore if this is not appropriate.
Well, so I should've ignored, but I think this is worth some correction.
> Asciidoc or Markdown are tools that accommodate the _developer_, not the
> user. I understand that these markup language are ideally suited for in
> source documentation (thought I personally much prefer Doxygen).
http://www.methods.co.nz/asciidoc/ says
``AsciiDoc is a text document format for writing short documents,
articles, books and UNIX man pages. AsciiDoc files can be translated to
HTML and DocBook markups using the asciidoc(1) command.''
http://daringfireball.net/projects/markdown/ says
``Markdown is a text-to-HTML conversion tool for web writers. Markdown
allows you to write using an easy-to-read, easy-to-write plain text
format, then convert it to structurally valid XHTML (or HTML).''
So those are not suited for in-source documentation.
They're "lightweight" markup for documentation, very easy to read and somehow
easy to write for non-developers.
The user manual can give you an impression:
http://repo.or.cz/w/git.git?a=blob;f=Documentation/user-manual.txt
I think, this is easier than LyX for users and developers..
Regards,
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: [PATCH 2/5] Add git-sequencer documentation
From: Stephan Beyer @ 2008-07-31 12:53 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Christian Couder, Daniel Barkalow
In-Reply-To: <alpine.LSU.1.00.0807301556140.3486@wbgn129.biozentrum.uni-wuerzburg.de>
Hi,
Johannes Schindelin wrote:
> > > > +--onto=<base>::
> > > > + Checkout given commit or branch before sequencing.
> > > > + If you provide a branch, sequencer will make the provided
> > > > + changes on the branch, i.e. the branch will be changed.
> > >
> > > Whoa, does that mean that
> > >
> > > $ git checkout my-private-branch
> > > $ git sequencer --onto=master
> > >
> > > will change _master_?
> >
> > Exactly.
>
> /me does not like that. I could see a new porcelain doing that, but not
> the thing that will be called by rebase.
$ git sequencer --onto=master todofile
is equal to:
$ git checkout $(git rev-parse master) # detached HEAD
$ git sequencer todofile
And when successfully finished:
$ git update-ref refs/heads/master HEAD # reattach branch
Yet this seemed to be useful.
(But perhaps the name --onto is wrong...)
> > > > + --include-merges;;
> > > > + Sanity check does not fail if you have merges
> > > > + between HEAD and <mark>.
> > >
> > > It may be a commit, too, right? And why does it make sense to check that
> > > there are no merges? I mean, it is just as if I did two cherry-picks, the
> > > second with -n, and then commit --amend it. Can make tons of sense...
> >
> > I think I mean something different. With "merges" I am talking about
> > commits having more than one parent.
>
> Yes, I read "merges" the same way. My comment still stands.
If you really mean that it's the same as doing two cherry-picks and
squashing the second into the first, I don't get what your comment has
in common with merges.
If you mean squashing a merge and some cherry-picks on top of that merge
into one merge commit: that is possible. It's only checked that no merges
are *in between* currently.
In graphics: squashing
..--M--X--Y- ..-A--M--X--Y
/ /
..- ..-
is allowed is only allowed with
--include-merges
Regards.
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* [StGIT PATCH] Do not mess-up with commit message formatting when sending email
From: Samuel Tardieu @ 2008-07-31 12:50 UTC (permalink / raw)
To: git; +Cc: Catalin Marinas
The short description, which will be used as the email subject,
gets its leading and trailing whitespaces removed.
The long description only gets its trailing whitespaces removed
to preserve commit message formatting, e.g. in the case of a
ChangeLog-style commit message, as well as empty leading lines.
Signed-off-by: Samuel Tardieu <sam@rfc1149.net>
---
stgit/commands/mail.py | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/stgit/commands/mail.py b/stgit/commands/mail.py
index a833efc..bdc3fcc 100644
--- a/stgit/commands/mail.py
+++ b/stgit/commands/mail.py
@@ -401,8 +401,8 @@ def __build_message(tmpl, patch, patch_nr, total_nr, msg_id, ref_id, options):
options.edit_patches = True
descr_lines = descr.split('\n')
- short_descr = descr_lines[0].rstrip()
- long_descr = '\n'.join(descr_lines[1:]).lstrip()
+ short_descr = descr_lines[0].strip()
+ long_descr = '\n'.join([l.rstrip() for l in descr_lines[1:]]).lstrip('\n')
authname = p.get_authname();
authemail = p.get_authemail();
^ permalink raw reply related
* [StGIT PATCH] Do not insert an empty line before the diffstat info
From: Samuel Tardieu @ 2008-07-31 12:50 UTC (permalink / raw)
To: git; +Cc: Catalin Marinas
To make the format of stg output closer to the plain git one, do
not insert an empty line between the "---" separator and the
diffstat information.
Signed-off-by: Samuel Tardieu <sam@rfc1149.net>
---
templates/mailattch.tmpl | 1 -
templates/patchexport.tmpl | 1 -
templates/patchmail.tmpl | 1 -
3 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/templates/mailattch.tmpl b/templates/mailattch.tmpl
index 430b341..70d2df0 100644
--- a/templates/mailattch.tmpl
+++ b/templates/mailattch.tmpl
@@ -11,7 +11,6 @@ Content-Disposition: inline
%(fromauth)s%(longdescr)s
---
-
%(diffstat)s
--MIMEBOUNDARY
Content-Type: text/plain; name=%(patch)s.patch
diff --git a/templates/patchexport.tmpl b/templates/patchexport.tmpl
index e7f3481..11f2075 100644
--- a/templates/patchexport.tmpl
+++ b/templates/patchexport.tmpl
@@ -4,6 +4,5 @@ From: %(authname)s <%(authemail)s>
%(longdescr)s
---
-
%(diffstat)s
diff --git a/templates/patchmail.tmpl b/templates/patchmail.tmpl
index f5c35c2..7d4022a 100644
--- a/templates/patchmail.tmpl
+++ b/templates/patchmail.tmpl
@@ -3,6 +3,5 @@ Subject: [%(prefix)sPATCH%(version)s%(number)s] %(shortdescr)s
%(fromauth)s%(longdescr)s
---
-
%(diffstat)s
%(diff)s
^ permalink raw reply related
* Re: [RFC] Git User's Survey 2008
From: Jakub Narebski @ 2008-07-31 12:48 UTC (permalink / raw)
To: git
In-Reply-To: <200807230325.04184.jnareb@gmail.com>
I will be AFK for about a week, so I don't think I'd have Git User's
Survey 2008 ready for 1.6.0 (August 10).
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH (GITK) 5/6] gitk: Fixed automatic row selection during load.
From: Alexander Gavrilov @ 2008-07-31 12:41 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <18577.41259.758690.635991@cargo.ozlabs.ibm.com>
On Thu, Jul 31, 2008 at 3:25 PM, Paul Mackerras <paulus@samba.org> wrote:
> Alexander Gavrilov writes:
>
>> - Switching views now actually preserves the selected commit.
>> - Reloading (also Edit View) preserves the currently selected commit.
>> - Initial selection does not produce weird scrolling.
>>
>> Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
>
> I need a more detailed explanation of the rationale for the specific
> changes you have made in the changelog.
The rationale is that preserving the currently selected commit is more
intelligent behavior than always resetting to a preset position, and
it makes the UI feel more smooth. Also, although it is possible to
restore selection by clicking the 'back' button, it is not immediately
obvious; in fact I realized it only after reading the code.
Gitk already tried to preserve the commit in many cases, but failed
because of a conflicting change that made it select the head. Such
behavior is clearly a bug.
The Reload case is arguable, but I think that Edit View should
preserve the selection, and it uses Reload internally. It can be
resolved by adding a parameter to the function implementing Reload.
> As for the patch, it mostly looks good, but I have a few comments
> below.
>
>> +proc getcommits {selid} {
>> global canv curview need_redisplay viewactive
>>
>> initlayout
>> if {[start_rev_list $curview]} {
>> + reset_pending_select $selid
>
> Is there any significance to having the call to reset_pending_select
> after the start_rev_list call (other than not setting pending_select
> if start_rev_list fails)? I couldn't see any. If there is then it
> should be noted in a comment and/or the patch description.
It simply tries to preserve the original behavior.
>> @@ -503,7 +511,7 @@ proc updatecommits {} {
>> filerun $fd [list getcommitlines $fd $i $view 1]
>> incr viewactive($view)
>> set viewcomplete($view) 0
>> - set pending_select $mainheadid
>> + reset_pending_select {}
>
> This doesn't actually change anything, right? If so then I'd prefer
> the simple, direct assignment to calling a procedure that does the
> assignment.
I have a patch WIP that allows specifying a commit on the command line
to select instead of the head (I need it to enhance the git gui blame
UI). It makes the function somewhat more intelligent. I'll submit it
as soon as this series is sorted out.
>> @@ -4036,6 +4042,7 @@ proc layoutmore {} {
>> }
>> if {[info exists pending_select] &&
>> [commitinview $pending_select $curview]} {
>> + update
>> selectline [rowofcommit $pending_select] 1
>
> What does that update do? Would update idletasks be better?
That update forces Tk to recompute the widget dimensions. Otherwise
selectline sometimes gets all zeroes from yview, which makes it
compute really weird scrolling settings. Git-gui always does an update
before scrolling computations.
Alexander
^ 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