* [PATCH] SubmittingPatches: mention older C compiler compatibility
From: Johannes Schindelin @ 2007-05-21 12:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Martin Waitz, Shawn O. Pearce, git
In-Reply-To: <7vabvyfw7n.fsf@assigned-by-dhcp.cox.net>
We do not appreciate C99 initializers, declarations after statements,
or "0" instead of "NULL".
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
On Mon, 21 May 2007, Junio C Hamano wrote:
> Portability rules:
>
> - We do not do C99 initializers;
> - We do not do decl-after-statement;
>
> Readability rules:
>
> - We always write NULL, not 0, for a NULL pointer.
>
> There may be a handful more unwritten rules we use.
... so let's start with these 3.
Documentation/SubmittingPatches | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 6a4da2d..cc74b4b 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -65,6 +65,19 @@ in templates/hooks--pre-commit. To help ensure this does not happen,
run git diff --check on your changes before you commit.
+(1a) Try to be nice to older C compilers
+
+We pride ourselves with the wide range of C compilers you can compile
+git with. That means that you should not use C99 initializers, even
+if a lot of compilers grok it.
+
+Also, variables have to be declared at the beginning of the block
+(you can check this with gcc, using the -Wdeclaration-after-statement
+option).
+
+Another thing: NULL pointers shall be written as NULL, not as 0.
+
+
(2) Generate your patch using git tools out of your commits.
git based diff tools (git, Cogito, and StGIT included) generate
^ permalink raw reply related
* Re: [PATCH] Teach mailsplit about Maildir's
From: Johannes Schindelin @ 2007-05-21 12:55 UTC (permalink / raw)
To: Fernando J. Pereda; +Cc: Johan Herland, git, Junio C Hamano
In-Reply-To: <20070520191821.GF13197@ferdyx.org>
Hi,
On Sun, 20 May 2007, Fernando J. Pereda wrote:
> On Sun, May 20, 2007 at 08:53:32PM +0200, Johan Herland wrote:
> >
> > Not sure how I feel about the usefulness of the patch if it requires
> > correct sorting, and most mail clients turn out to _not_ sort
> > correctly. Of course I have no idea what most mail clients do, but
> > KMail seems to get it about right, AFAICS (mail filename starts with
> > timestamp, so they're at least sorted roughly on (arrival) date).
>
> I discussed this with a pine user in #git and we concluded (looking at
> the respective code) that both Mutt and Pine generate correct filenames
> based on when that mail arrived to the Maildir.
FWIW this pine user was me. Yes, I finally bit the bullet and run pine
with the maildir patches.
I cannot think of another sane way for any MUA to sort Maildirs.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Teach mailsplit about Maildir's
From: Johannes Schindelin @ 2007-05-21 12:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Fernando J. Pereda, Git Mailing List
In-Reply-To: <7vd50uj29r.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sun, 20 May 2007, Junio C Hamano wrote:
> "Fernando J. Pereda" <ferdy@gentoo.org> writes:
>
> > - ret = split_mbox(argp, dir, allow_bare, nr_prec, nr);
> > + while (*argp) {
> > + const char *arg = *argp++;
> > + struct stat argstat;
> > +
> > + if (arg[0] == '-' && arg[1] == 0) {
> > + ret |= split_mbox(arg, dir, allow_bare, nr_prec, nr);
> > + continue;
> > + }
> > +
> > + if (stat(arg, &argstat) == -1) {
> > + error("cannot stat %s (%s)", arg, strerror(errno));
> > + return 1;
> > + }
> > +
> > + if (S_ISDIR(argstat.st_mode))
> > + ret |= split_maildir(arg, dir, nr_prec, nr);
> > + else
> > + ret |= split_mbox(arg, dir, allow_bare, nr_prec, nr);
> > + }
> > +
> > if (ret != -1)
> > printf("%d\n", ret);
> >
>
> No kidding. ret |= stuff and then printf("%d\n", ret) would not
> give us the number of commit e-mails on the standard output.
Should we not just stop when split_maildir() or split_mbox() returns -1?
And yes, we'd probably need a second variable to do take the return value.
Ciao,
Dscho
^ permalink raw reply
* Git string manipulation functions wrong?
From: Erik Mouw @ 2007-05-21 13:11 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 896 bytes --]
Hi,
I got this forwarded from a friend who is subscribed to the Dovecot
mailing lists (dovecot is a pop3/imap server).
http://www.dovecot.org/list/dovecot/2007-May/022853.html
http://www.dovecot.org/list/dovecot/2007-May/022856.html
The Dovecot author claims there are "basic string manipulation errors"
in the git code and that's a reason for him not to use git.
I can see his problem with *snprintf() functions in the case where the
amount of output is larger than the buffer size: *snprintf() will
return the number of characters written if there would have been enough
space to write them, which will lead to problems with code like "len +=
snprintf(buf, max, bla, ...)". I don't see his problems with strncpy(),
though.
Erik
--
They're all fools. Don't worry. Darwin may be slow, but he'll
eventually get them. -- Matthew Lammers in alt.sysadmin.recovery
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: problem with import-tars?
From: Johannes Schindelin @ 2007-05-21 13:43 UTC (permalink / raw)
To: Joshua N Pritikin; +Cc: git
In-Reply-To: <20070521084846.GN11652@always.joy.eth.net>
Hi,
On Mon, 21 May 2007, Joshua N Pritikin wrote:
> I ran the import-tars which comes with 1:1.5.1.1-1 (Debian). I checked
> out the import-tars branch but now I can't commit:
>
> [...]
I think that the bug you experienced is solved in 1.5.2. You can download
import-tars.perl separately, as it should work with the 1.5.1.1 plumbing:
http://repo.or.cz/w/git.git?a=blob;f=contrib/fast-import/import-tars.perl;h=23aeb257b9557cb146586868084ce1b20d7e7ac8;hb=HEAD
Hth,
Dscho
^ permalink raw reply
* Re: Git string manipulation functions wrong?
From: Petr Baudis @ 2007-05-21 14:36 UTC (permalink / raw)
To: Erik Mouw; +Cc: git
In-Reply-To: <20070521131103.GN8200@gateway.home>
On Mon, May 21, 2007 at 03:11:03PM CEST, Erik Mouw wrote:
> Hi,
>
> I got this forwarded from a friend who is subscribed to the Dovecot
> mailing lists (dovecot is a pop3/imap server).
>
> http://www.dovecot.org/list/dovecot/2007-May/022853.html
> http://www.dovecot.org/list/dovecot/2007-May/022856.html
>
> The Dovecot author claims there are "basic string manipulation errors"
> in the git code and that's a reason for him not to use git.
>
> I can see his problem with *snprintf() functions in the case where the
> amount of output is larger than the buffer size: *snprintf() will
> return the number of characters written if there would have been enough
> space to write them, which will lead to problems with code like "len +=
> snprintf(buf, max, bla, ...)". I don't see his problems with strncpy(),
> though.
It's the opposite for me - we don't properly set the NUL byte for smoe
of our strncpy() calls, but I don't really see his problem with
snprintf(), we seem to handle its return value correctly everywhere
(except diff.c, but there the buffer sizes should be designed in such a
way that an overflow should be impossible).
--
Petr "Pasky the Sleepy" Baudis
Stuff: http://pasky.or.cz/
Ever try. Ever fail. No matter. // Try again. Fail again. Fail better.
-- Samuel Beckett
^ permalink raw reply
* Re: Git string manipulation functions wrong?
From: Karl Hasselström @ 2007-05-21 14:59 UTC (permalink / raw)
To: Petr Baudis; +Cc: Erik Mouw, git
In-Reply-To: <20070521143616.GG4489@pasky.or.cz>
On 2007-05-21 16:36:16 +0200, Petr Baudis wrote:
> It's the opposite for me - we don't properly set the NUL byte for
> smoe of our strncpy() calls, but I don't really see his problem with
> snprintf(), we seem to handle its return value correctly everywhere
> (except diff.c, but there the buffer sizes should be designed in
> such a way that an overflow should be impossible).
I think this kind of detailed case-by-case analysis defeats Timo's
point, though: that the C library functions make it too easy to write
bugs. If it's necessary to do non-trivial bounds checking etc. at
every call site, it doesn't really matter if we currently do get them
all right; at some point, we _are_ going to miss one. Instead of using
our collective C-fu to get difficult calls right, we should be using
it to construct string routines that have low enough overhead that
it's lost in the noise, and are dead simple to use (and, of course,
that can be cleanly bypassed in the 1% of cases where it's necessary).
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH 1/2] Update the bash prompt from 'applied' instead of the obsolete 'current'
From: Catalin Marinas @ 2007-05-21 15:17 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Robin Rosenberg, ydirson, git
In-Reply-To: <20070521113915.GA3090@diana.vm.bytemark.co.uk>
On 21/05/07, Karl Hasselström <kha@treskal.com> wrote:
> On 2007-05-21 12:15:40 +0200, Karl Hasselström wrote:
>
> > We might consider having plumbing written in C or something, and
> > make sure that the plumbing can be called directly if there's need,
> > but it's going to complicate things greatly compared to pure Python.
Yes, it will complicate things. I think StGIT would have progressed at
a much slower pace if written in C :-).
> What I'm (foggily) envisioning here is to rewrite parts of StGIT (as
> little as possible) as a C library (libstgit.so?), and call the
> library both from the Python code, and from a "plumbing" C program
> (stgit-helper?). We should not try to make the library API stable,
> just like the current git library.
Apart from the start-up time, I don't see other major slowdowns caused
by Python. It would be useful to use a git library directly without
invoking external applications (I'm not sure what's the state of a
"libgit.a" or what improvement we would get).
As for the start-up time, unless you write most of the commands in C,
we would still have to load Python modules. If you run stg-prof
instead of stg for a simple command like 'top', you can see that the
main function takes about 60-70ms, the rest to 150ms reported by the
external 'time' is Python start-up and module loading.
I had a quick try at using "freeze.py" to generate a binary (well, it
includes python bytecodes but it might save time on module look-up)
but it got confused by my optimisation to only load module commands
based on the stg arguments. Maybe we should try this first.
> There are two kinds of things we'd want to have in the library: (1)
> things that are too slow to do in Python, and (2) things that need to
> be available from stgit-helper in order to avoid Python's startup
> cost, such as top/applied/unapplied for the bash completion and bash
> prompt.
As you probably guessed, I'm not really in favour of re-writing parts
of StGIT in C, at least not in the near future, though anyone can fork
and re-implement it :-).
--
Catalin
^ permalink raw reply
* Re: [PATCH v2] Submodule merge support
From: Alex Riesen @ 2007-05-21 15:42 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Martin Waitz, git
In-Reply-To: <20070521073758.GP3141@spearce.org>
On 5/21/07, Shawn O. Pearce <spearce@spearce.org> wrote:
> Its a very old Sun C compiler, and it doesn't like structs to be
> initialized that way. Yes, newer compilers are better, and gcc is
> also better, but I'm unable to get our UNIX admins to actually do
> their job and keep systems usable by the users.
>
> /me starts to wonder why he continues with this day-job thing...
Because the new job may involve windows
^ permalink raw reply
* Re: [PATCH 1/2] Update the bash prompt from 'applied' instead of the obsolete 'current'
From: Karl Hasselström @ 2007-05-21 15:39 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Robin Rosenberg, ydirson, git
In-Reply-To: <b0943d9e0705210817n35e50a6bgb519b693984b3a4b@mail.gmail.com>
On 2007-05-21 16:17:22 +0100, Catalin Marinas wrote:
> On 21/05/07, Karl Hasselström <kha@treskal.com> wrote:
>
> > On 2007-05-21 12:15:40 +0200, Karl Hasselström wrote:
> >
> > > We might consider having plumbing written in C or something, and
> > > make sure that the plumbing can be called directly if there's
> > > need, but it's going to complicate things greatly compared to
> > > pure Python.
>
> Yes, it will complicate things. I think StGIT would have progressed at
> a much slower pace if written in C :-).
I agree. C is not a good language to write a whole application in. But
for the hot spots, C is a reasonable choice.
> > What I'm (foggily) envisioning here is to rewrite parts of StGIT
> > (as little as possible) as a C library (libstgit.so?), and call
> > the library both from the Python code, and from a "plumbing" C
> > program (stgit-helper?). We should not try to make the library API
> > stable, just like the current git library.
>
> Apart from the start-up time, I don't see other major slowdowns
> caused by Python.
I haven't, either.
> It would be useful to use a git library directly without invoking
> external applications (I'm not sure what's the state of a "libgit.a"
> or what improvement we would get).
There is no usable git library yet. But once there is, I agree we
should use it.
> As for the start-up time, unless you write most of the commands in C,
> we would still have to load Python modules. If you run stg-prof
> instead of stg for a simple command like 'top', you can see that the
> main function takes about 60-70ms, the rest to 150ms reported by the
> external 'time' is Python start-up and module loading.
My suggestion was to have a small stand-alone C program that could do
some operations that need to be really fast, such as
top/applied/unapplied. It need not have a nice user interface since
it's only going to be called by scripts (bash-completion and the
like), and it should only handle those operations that _must- avoid
the Python startup penalty. And for sanity reasons, it should share
code with stgit.
> I had a quick try at using "freeze.py" to generate a binary (well,
> it includes python bytecodes but it might save time on module
> look-up) but it got confused by my optimisation to only load module
> commands based on the stg arguments. Maybe we should try this first.
I agree that we should try pure-Python optimizations first.
> > There are two kinds of things we'd want to have in the library:
> > (1) things that are too slow to do in Python, and (2) things that
> > need to be available from stgit-helper in order to avoid Python's
> > startup cost, such as top/applied/unapplied for the bash
> > completion and bash prompt.
>
> As you probably guessed, I'm not really in favour of re-writing
> parts of StGIT in C, at least not in the near future, though anyone
> can fork and re-implement it :-).
I wouldn't do it just for fun, either. But if it's a prerequisite to
get good enough performance for something we really want, and all else
has failed, I'd be willing to argue for the introduction of a C
library and helper application.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH 1/3] t9400: Add test cases for config file handling
From: Frank Lichtenheld @ 2007-05-21 16:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Martin Langhoff
In-Reply-To: <7vlkfjhu2w.fsf@assigned-by-dhcp.cox.net>
On Sun, May 20, 2007 at 05:57:27PM -0700, Junio C Hamano wrote:
> This part seems to fail for me and gets an "unexpected cvs success".
Note the note in the patch ;)
> diff --git a/git-cvsserver.perl b/git-cvsserver.perl
> index fcfb99d..1de5177 100755
> --- a/git-cvsserver.perl
> +++ b/git-cvsserver.perl
> @@ -192,11 +192,9 @@ sub req_Root
> }
> }
>
> - unless ( ($cfg->{gitcvs}{$state->{method}}{enabled}
> - and $cfg->{gitcvs}{$state->{method}}{enabled} =~ /^\s*(1|true|yes)\s*$/i)
> - or ($cfg->{gitcvs}{enabled}
> - and $cfg->{gitcvs}{enabled} =~ /^\s*(1|true|yes)\s*$/i) )
> - {
> + my $enabled = ($cfg->{gitcvs}{$state->{method}}{enabled}
> + || $cfg->{gitcvs}{enabled});
> + unless ($enabled && $enabled =~ /^\s*(1|true|yes)\s*$/i) {
> print "E GITCVS emulation needs to be enabled on this repo\n";
> print "E the repo config file needs a [gitcvs] section added, and the parameter 'enabled' set to 1\n";
> print "E \n";
Yeah, should probably have fixed that myself before sending, but the
other patches were already prepared ;)
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* Re: [PATCH 1/3] t9400: Add test cases for config file handling
From: Junio C Hamano @ 2007-05-21 16:38 UTC (permalink / raw)
To: Frank Lichtenheld; +Cc: Git Mailing List, Martin Langhoff
In-Reply-To: <20070521163145.GM4085@planck.djpig.de>
Frank Lichtenheld <frank@lichtenheld.de> writes:
> On Sun, May 20, 2007 at 05:57:27PM -0700, Junio C Hamano wrote:
>> This part seems to fail for me and gets an "unexpected cvs success".
>
> Note the note in the patch ;)
>
>> diff --git a/git-cvsserver.perl b/git-cvsserver.perl
>> index fcfb99d..1de5177 100755
>> --- a/git-cvsserver.perl
>> +++ b/git-cvsserver.perl
>> @@ -192,11 +192,9 @@ sub req_Root
>> }
>> }
>>
>> - unless ( ($cfg->{gitcvs}{$state->{method}}{enabled}
>> - and $cfg->{gitcvs}{$state->{method}}{enabled} =~ /^\s*(1|true|yes)\s*$/i)
>> - or ($cfg->{gitcvs}{enabled}
>> - and $cfg->{gitcvs}{enabled} =~ /^\s*(1|true|yes)\s*$/i) )
>> - {
>> + my $enabled = ($cfg->{gitcvs}{$state->{method}}{enabled}
>> + || $cfg->{gitcvs}{enabled});
>> + unless ($enabled && $enabled =~ /^\s*(1|true|yes)\s*$/i) {
>> print "E GITCVS emulation needs to be enabled on this repo\n";
>> print "E the repo config file needs a [gitcvs] section added, and the parameter 'enabled' set to 1\n";
>> print "E \n";
>
> Yeah, should probably have fixed that myself before sending, but the
> other patches were already prepared ;)
Ok, so that's an Ack?
^ permalink raw reply
* Re: [PATCH 1/6] Remove whitespace breakage from *.c files
From: Junio C Hamano @ 2007-05-21 16:39 UTC (permalink / raw)
To: Marco Costalba; +Cc: Git Mailing List
In-Reply-To: <e5bfff550705210454s6e89fb2frb8cb74ea97d7c2ca@mail.gmail.com>
"Marco Costalba" <mcostalba@gmail.com> writes:
> ... I
> understand that this kind of patches are mostly automatically created
> and also touch a lot of files so the manteiner has the best _timing_
> to create and apply them.
I was thinking about the same thing last night. The tips of
'master' branch and 'next' branch were identical after pushing
out the "first batch" I announced in the last "What's cooking"
message, and it was really a good time to do this kind of thing.
Will do, sometime soon.
^ permalink raw reply
* Re: [PATCH 07/16] git-read-tree: take --submodules option
From: Jan Hudec @ 2007-05-21 16:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: skimo, Alex Riesen, git
In-Reply-To: <7vbqgfmjki.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 6611 bytes --]
Hello,
I gave the problem some more thought, and though I follow up on my previous
comment below, I can now see this:
So far it was discussed what should happen in fetch (+ checkout). But I think
the following are the interesting cases. Please read ALL before responding,
they are in somewhat random order:
For following, assume there is a repo of project super has two branches,
master and next. The next branch adds subproject sublib. In that state, I fetch
refs/heads/*:refs/remotes/origin/* and check out master. So I have
a repository, that contains revision with submodule, but I did not check it
out yet.
- Some time later, *without* fetching again, I simply
git checkout --submodules -b feature1 remotes/origin/next
Obviously it needs to give me the module.
- Should that checkout work without network access?
- Ok, now I start hacking on feature1 and find a bug in sublib, that I need
to fix for it to work. Therefore I change something within sublib.
However few days later I am asked to fix a bug in stable release of super.
Therefore I: git checkout master Now, where does sublib go? It contains
precious data!
For the worst case situation assume, that the master branch also has
directory sublib, so it can't stay where it was as unversioned.
- The fix in master is done, back to our feature1, right? git checkout
--submodules feature1 Obviously re-fetching from upstram won't work. The
head feature1 now refers to a commit that I made and only exists localy.
- Now the maintainer of super wants to test the feature1. However sublib
upstream did not accept the bugfix yet (and is perhaps waiting for
confirmation, that the fixed version really works well for super, so we
have to test).
Therefore I push feature1 to my public repo, set up a public repo with my
fixes to sublib and configure my public super repo to know about it.
The maintainer already has a repo of super including sublib submodule. But
when he pulls from me, he does not have the repo with my fixes.
- The maintainer reviewed my feature1 and now needs to work on feature2.
That however requires new upstream version of super. Therefore he needs to
pull alternatively from both upstream and my repo with super, depending on
what he works on.
For the most complex case, assume here that I add more fixes to sublib
while author of feature2 uses more and more bleeding edge stuff, so the
maintainer really needs futher changes in sublib from both repos.
- Also git has to fail safe if I forget to push the sublib, so when the
maintainer tries to pull super, the refered revision of sublib simply
won't be found.
I am not sure how to handle these cases. But they are cases that can happen
in real life and should be handled somehow. Even if some of them just require
some manual configuration.
Here is one possible idea:
We could store the GIT_DIR of submodule within the GIT_DIR of the
superproject instead of the submodule directory itself. So instead of:
/
/.git
/subdir
/subdir/.git
There would be:
/
/.git
/subdir
/.git/submodules/submodule-name.git
This would require changes to the logic how git finds GIT_DIR (which would be
really deep change), but it would provide place to store the submodule data
while the submodule is not being checked out.
This does not address the last two cases above with mutliple sources, each
containing some revisions. There I see two options:
- The submodules are fetched during superproject fetch (based on them being
configured, even if they are not checked out) and the URL might depend on
url configured for superproject. That is:
git fetch --submodules foobar
would do roughty:
for GIT_DIR in $GIT_DIR/submodules/*.git; do
git fetch foobar || git fetch
done
So if you configured source of the same name for the subproject, it would
be pulled, otherwise the default one would.
Checkout would then be local-only operation, because subprojects are
up-to-date.
- The superproject checkout would try fetching all sources of the
subproject, until the requested revision is found.
This could be extended to normal checkout doing it as well --
"git checkout sha1" would try fetching all configured sources if the
revision was not found.
Perhaps we could actually do both. That is, "git fetch --subprojects" to
also fetch all of "$GIT_DIR/submodules/*.git" and checkout to try fetching if
it can't find the desired revision.
On Sun, May 20, 2007 at 11:33:17 -0700, Junio C Hamano wrote:
> Jan Hudec <bulb@ucw.cz> writes:
> > IMHO it makes more sense to fetch during fetch of superproject:
> >
> > - If you don't fetch the superproject, it won't start refering to
> > unavailable commit of subproject. So should only need to fetch subproject
> > after fetching superproject.
>
> Eh, I was suggesting that the subproject fetch would come after
> checkout in "fetch and then checkout" sequence of the
> superproject, and if you are arguing against it, you should
> justify why it should not happen before checkout, as we both
> agree it should come after fetch of superproject. Your argument
> is like saying you have to git-init before doing anything so
> you should fetch when you git-init. That's not a justification.
It definitely has to come after fetch on superproject. My original thought
was, that it would be weird if it was part of the checkout itself, meaning
even checkout that does not follow a fetch. However I thought about it some
more and that might conflict with other requirements.
> > - If you fetch from more than one location, you want to fetch subproject
> > from location corresponding to where you fetch superproject from.
>
> Not at all. There is no reason to believe that the case that
> superproject and subproject come from related URLs is more
> common. One of the reasons to do a separated project
I definitely don't think it's more common. But it's the harder case and it
might happen. Generally it will happen if some people work on both the
superproject and the subproject. Of course the argument is that than it
should not be separate projects, but maybe the teams just partly overlap.
Example of this situation is given above. IMHO it needs to be handled
somehow (probably git would have to check all potential sources whether they
have the revision in question).
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] git-pack-objects: cache small deltas between big objects
From: Martin Koegler @ 2007-05-21 17:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v646mixnm.fsf@assigned-by-dhcp.cox.net>
On Sun, May 20, 2007 at 09:54:53PM -0700, Junio C Hamano wrote:
> Martin Koegler <mkoegler@auto.tuwien.ac.at> writes:
> > diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
> > index d165f10..13429d0 100644
> > --- a/builtin-pack-objects.c
> > +++ b/builtin-pack-objects.c
> > ...
> > @@ -1294,10 +1302,17 @@ static int try_delta(struct unpacked *trg, struct unpacked *src,
> > if (!delta_buf)
> > return 0;
> >
> > + if (trg_entry->delta_data)
> > + free (trg_entry->delta_data);
> > + trg_entry->delta_data = 0;
> > trg_entry->delta = src_entry;
> > trg_entry->delta_size = delta_size;
> > trg_entry->depth = src_entry->depth + 1;
> > - free(delta_buf);
> > + /* cache delta, if objects are large enough compared to delta size */
> > + if ((src_size >> 20) + (trg_size >> 21) > (delta_size >> 10))
> > + trg_entry->delta_data = delta_buf;
> > + else
> > + free(delta_buf);
> > return 1;
> > }
>
> Care to justify this arithmetic? Why isn't it for example like
> this?
>
> ((src_size + trg_size) >> 10) > delta_size
I wanted to avoid a possible overflow in (src_size + trg_size), so
I shift both sides.
> I am puzzled by the shifts on both ends, and differences between
> 20 and 21.
I base the maximum allowed delta_size for caching on the required
memory for creating the delta. For the src entry, you need need a
delta index, which has (about) the same size of the src entry. So I
count the src entry double.
I divide the requried memory by 1024, so that the delta size is some
magnitudes smaller and will not cause a big increase of memory usage,
eg:
For two 100 MB (uncompressed) blobs, we need 300MB of memory to do the
delta (with the default window size of 10 up to 1900MB for all delta
indexes in the worst case). The patch will limit the delta size for
the target blob to 150kB.
The caching policy does only cache really small deltas for really big
objects, as I wanted to avoid out of memory situations. Futurer patch
should probably replace it with a better strategy.
mfg Martin Kögler
^ permalink raw reply
* Re: [PATCH 1/3] t9400: Add test cases for config file handling
From: Frank Lichtenheld @ 2007-05-21 17:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Martin Langhoff
In-Reply-To: <7vtzu6dtd2.fsf@assigned-by-dhcp.cox.net>
On Mon, May 21, 2007 at 09:38:49AM -0700, Junio C Hamano wrote:
> Frank Lichtenheld <frank@lichtenheld.de> writes:
> > Yeah, should probably have fixed that myself before sending, but the
> > other patches were already prepared ;)
>
> Ok, so that's an Ack?
Yes.
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* [PATCH] config: Add --quoted option to produce machine-parsable output
From: Frank Lichtenheld @ 2007-05-21 17:46 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano, Frank Lichtenheld
In-Reply-To: <20070520225953.GK4085@planck.djpig.de>
This option will enclose key names in quotes (") if they
contain a subsection and then escape " and \. It will also
escape line breaks in values. Together this should produce
an easily parsable output.
Affects --list and --get-*
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
---
builtin-config.c | 92 ++++++++++++++++++++++++++++++++++++++++++++++++-----
1 files changed, 83 insertions(+), 9 deletions(-)
Will add asciidoc documentation and test cases if people think that this is
a good idea.
I'm writing C about once a year, so I really don't mind being told if it's
crap ;)
diff --git a/builtin-config.c b/builtin-config.c
index b2515f7..454cf4e 100644
--- a/builtin-config.c
+++ b/builtin-config.c
@@ -2,7 +2,7 @@
#include "cache.h"
static const char git_config_set_usage[] =
-"git-config [ --global | --system ] [ --bool | --int ] [--get | --get-all | --get-regexp | --replace-all | --add | --unset | --unset-all] name [value [value_regex]] | --rename-section old_name new_name | --remove-section name | --list";
+"git-config [ --global | --system ] [ --bool | --int ] [--quoted] [--get | --get-all | --get-regexp | --replace-all | --add | --unset | --unset-all] name [value [value_regex]] | --rename-section old_name new_name | --remove-section name | --list";
static char *key;
static regex_t *key_regexp;
@@ -12,14 +12,73 @@ static int use_key_regexp;
static int do_all;
static int do_not_match;
static int seen;
+static int quoted;
static enum { T_RAW, T_INT, T_BOOL } type = T_RAW;
+static char* quote_key(const char *key_)
+{
+ char *pos1, *pos2;
+ char* key_quot;
+
+ pos1 = strchr(key_, '.');
+ pos2 = strrchr(key_, '.');
+ if (pos1 != pos2) { /* has subsection */
+ char* key;
+ key = xmalloc(strlen(key_)*2 + 1);
+ key_quot = key;
+ *key++ = '"';
+ while (*key_) {
+ if (*key_ == '"' || *key_ == '\\')
+ *key++ = '\\';
+ *key++ = *key_++;
+ }
+ *key++ = '"';
+ *key = 0;
+ } else {
+ key_quot = xstrdup(key_);
+ }
+ return key_quot;
+}
+
+static char* quote_value(const char* value_)
+{
+ char *val_quot, *val;
+ val = xmalloc(strlen(value_)*2 + 1);
+ val_quot = val;
+
+ while (*value_) {
+ if (*value_ == '\n') {
+ *val++ = '\\';
+ *val++ = 'n';
+ value_ += 2;
+ } else
+ *val++ = *value_++;
+ }
+ *val = 0;
+
+ return val_quot;
+}
+
static int show_all_config(const char *key_, const char *value_)
{
- if (value_)
- printf("%s=%s\n", key_, value_);
- else
- printf("%s\n", key_);
+ if (!quoted) {
+ if (value_)
+ printf("%s=%s\n", key_, value_);
+ else
+ printf("%s\n", key_);
+ } else {
+ char* key_quot = quote_key(key_);
+
+ if (value_) {
+ char* val_quot = quote_value(value_);
+ printf("%s=%s\n", key_quot, val_quot);
+ free(val_quot);
+ } else
+ printf("%s\n", key_quot);
+
+ free(key_quot);
+ }
+
return 0;
}
@@ -38,16 +97,26 @@ static int show_config(const char* key_, const char* value_)
regexec(regexp, (value_?value_:""), 0, NULL, 0)))
return 0;
- if (show_keys)
- printf("%s ", key_);
+ if (show_keys) {
+ if (quoted) {
+ char* key = quote_key(key_);
+ printf("%s ", key);
+ free(key);
+ } else
+ printf("%s ", key_);
+ }
if (seen && !do_all)
dup_error = 1;
if (type == T_INT)
sprintf(value, "%d", git_config_int(key_, value_?value_:""));
else if (type == T_BOOL)
vptr = git_config_bool(key_, value_) ? "true" : "false";
- else
- vptr = value_?value_:"";
+ else {
+ if (quoted)
+ vptr = value_?quote_value(value_):"";
+ else
+ vptr = value_?value_:"";
+ }
seen++;
if (dup_error) {
error("More than one value for the key %s: %s",
@@ -56,6 +125,9 @@ static int show_config(const char* key_, const char* value_)
else
printf("%s\n", vptr);
+ if (quoted && value_)
+ free((char *)vptr);
+
return 0;
}
@@ -141,6 +213,8 @@ int cmd_config(int argc, const char **argv, const char *prefix)
type = T_INT;
else if (!strcmp(argv[1], "--bool"))
type = T_BOOL;
+ else if (!strcmp(argv[1], "--quoted"))
+ quoted = 1;
else if (!strcmp(argv[1], "--list") || !strcmp(argv[1], "-l"))
return git_config(show_all_config);
else if (!strcmp(argv[1], "--global")) {
--
1.5.2-rc3.GIT
^ permalink raw reply related
* Re: [PATCH] git-pack-objects: cache small deltas between big objects
From: Martin Koegler @ 2007-05-21 17:59 UTC (permalink / raw)
To: Dana How; +Cc: git, Junio C Hamano
In-Reply-To: <56b7f5510705202135s8c9cd9qf4489b2b5bb2e264@mail.gmail.com>
On Sun, May 20, 2007 at 09:35:56PM -0700, Dana How wrote:
> On 5/20/07, Martin Koegler <mkoegler@auto.tuwien.ac.at> wrote:
> >Creating deltas between big blobs is a CPU and memory intensive task.
> >In the writing phase, all (not reused) deltas are redone.
>
> Actually, just the ones selected, which is approx 1/window.
> Do you have any numbers describing the effects on runtime
> and memory size for a known repo like linux-2.6?
Objects below 1 MB are not considered for caching.
The linux kernel has only such objects:
linux.git$ find -size +1000k |grep -v ".git"|wc
0 0 0
So no caching happens. The required memory is only increased by the
new pointer in object_entry.
At runtime, we have additional (#object)*(window size+1) null pointer
checks, (#objects)*(window size) pointer initialiations with zero and
check (#objects)*(window size) times the caching policy check: ((src_size
>> 20) + (trg_size >> 21) > (delta_size >> 10))
Writing a cached delta is faster, as we avoid creating a delta. Some
calls to free are delayed.
> >This patch adds support for caching deltas from the deltifing phase, so
> >that that the writing phase is faster.
> >
> >The caching is limited to small deltas to avoid increasing memory usage
> >very much.
> >The implemented limit is (memory needed to create the delta)/1024.
>
> Your limit is applied per-object, and there is no overall limit
> on the amount of memory not freed in the delta phase.
> I suspect this caching would be disastrous for the large repo
> with "megablobs" I'm trying to wrestle with at the moment.
http://www.spinics.net/lists/git/msg31241.html:
> At the moment I'm experimenting on a git repository with
> a 4.5GB checkout, and 18 months of history in 4K commits
> comprising 100GB (uncompressed) of blobs stored in
> 7 packfiles of 2GB or less. Hopefully I'll be able to say
> more about tweaking packing shortly.
I you have 100 GB of uncompressed data in your pack files, the cache
limit is between 100MB and 200MB with the current policy.
The aim of my patch is to speed up pack writing without increasing
memory usage very much, if you have blobs of some hundred MB size in
your repository.
The caching policy could be extended to speed more memory on caching
other deltas. Ideas on this topic are welcome.
mfg Martin Kögler
PS: If you are trying to optimize packing speed/size, you could test
the following patch: http://marc.info/?l=git&m=117908942525171&w=2
^ permalink raw reply
* Re: [PATCH] config: Add --quoted option to produce machine-parsable output
From: Junio C Hamano @ 2007-05-21 18:03 UTC (permalink / raw)
To: Frank Lichtenheld; +Cc: Git Mailing List
In-Reply-To: <11797696193384-git-send-email-frank@lichtenheld.de>
Frank Lichtenheld <frank@lichtenheld.de> writes:
> This option will enclose key names in quotes (") if they
> contain a subsection and then escape " and \. It will also
> escape line breaks in values. Together this should produce
> an easily parsable output.
>
> Affects --list and --get-*
>
> Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
> ---
> builtin-config.c | 92 ++++++++++++++++++++++++++++++++++++++++++++++++-----
> 1 files changed, 83 insertions(+), 9 deletions(-)
>
> Will add asciidoc documentation and test cases if people think that this is
> a good idea.
>
> I'm writing C about once a year, so I really don't mind being told if it's
> crap ;)
We probably would want to make this compatible with the quoting
rules various fo "host" language have. quote.c has host
language support to implement {perl,python,tcl}_quote_print()
for single string values or keys, so we should extend that idea.
In your application, what you are trying to do is to show a
"hash" (key => value) in a notation that is friendly to the host
language.
Git.pm could simply do:
my $eval = `git config --perl --get-regexp 'gitcvs\..*'`;
my $cfg = eval "$eval";
if you code your "perl" notation to produce:
+{
'gitcvs.ext.enabled' => 'false',
'gitcvs.logfile' => '/var/log/gitcvs.log',
}
in order to read things in.
Hmm?
^ permalink raw reply
* Re: [PATCH 07/16] git-read-tree: take --submodules option
From: Sven Verdoolaege @ 2007-05-21 18:05 UTC (permalink / raw)
To: Jan Hudec; +Cc: Junio C Hamano, Alex Riesen, git
In-Reply-To: <20070521165938.GA4118@efreet.light.src>
On Mon, May 21, 2007 at 06:59:38PM +0200, Jan Hudec wrote:
> We could store the GIT_DIR of submodule within the GIT_DIR of the
> superproject instead of the submodule directory itself. So instead of:
> /
> /.git
> /subdir
> /subdir/.git
>
> There would be:
> /
> /.git
> /subdir
> /.git/submodules/submodule-name.git
I have this already, except that I use /.git/submodules/submodule-name/.git
because I was too lazy to figure out how to get clone to use the above
without using --bare, because --bare disables separate-remotes.
Is there any good reason, btw for --bare not to do separate-remotes ?
We could throw out a lot of speical cases, especially the --bare http
fetch if we would simply always do a separate-remotes.
> This would require changes to the logic how git finds GIT_DIR (which would be
> really deep change),
Euhm.... I just add a symlink...
skimo
^ permalink raw reply
* Re: sbuild (or whatever) integration
From: Jan Hudec @ 2007-05-21 18:15 UTC (permalink / raw)
To: Florian Weimer; +Cc: git
In-Reply-To: <87sl9t6jhr.fsf@mid.deneb.enyo.de>
[-- Attachment #1: Type: text/plain, Size: 3338 bytes --]
On Sat, May 19, 2007 at 15:17:04 +0200, Florian Weimer wrote:
> I'd like to build something that integrates a Debian autobuilder
> (sbuilder probably) with GIT. The intent is to get rid of a
> designated integrator (our team is of a size where this seems a
> reasonable thing to do[1]) and ensure predictable builds, independent
> of what developers happen to have installed on their local
> workstations.
That's definitely a useful and reasonable thing to do.
> Basically, what I want to do is this:
>
> 1. Perform a checkout from a specific branch.
>
> 2. Synthesize a new version number that is bigger than the previous
> one. (This needs to keep a bit of extra-repository state. At
> this stage, it's probably a good idea to ensure that the previous
> commit built on this branch is an ancestor of the current HEAD.)
>
> 3. Generate a fake Debian changelog entry giving the HEAD commit and
> the branch name, using the generated version number.
>
> 4. Build the whole thing in a controlled environment.
>
> 5. Store the build log for later review.
>
> 6. If the build was successful, transfer the packages to some
> repository (based on the branch that was used).
I don't think there is actually too much code that would be common for
various git users. It has some code common for Debian developers, either
using Git or even other version control:
1. This is one or at most few commands in a script or makefile, so not much
room for generic stuff there.
2. This is something big conitnuous integration suites have complex system to
solve, just to hide the fact that it's worth few lines of perl. However:
- You might want to make up something Debian specific. Something like
looking at latest entry in debian/changelog (that would be the last
release) and adding an extra number to that.
- Alternatively you could use git describe to get the version number of
last release. Since it's fast-forward only, next build is always from
descendant of previous, so you might even use git-describe output
directly.
3. This is mostly Debian-specific. If you remember commit id of previous
build -- or leave the entries in debian/changelog around -- you can put
the short log in the entry, but that's single git command once you have
the respective version ids.
4. These are Debian-specific commands, but would be the same for every Debian
package.
5. This is mainly issue of sbuild setup, no?
6. Again, sbuild -- and therefore Debian -- specific (but reusable in
Debian).
IMHO generic tools won't help you much, because every other command is Debian
specific.
What *CAN* help you is the script in
/usr/share/doc/git-core/contrib/continuous
that will make sure the package is built whenever there are some new changes
on the branch while not doing unnecessary work.
There are actually even big projects with web interface and stuff to do this
kind of thing, but they don't actually cover your steps above except 1 and 2.
1 is trivial and for 2 you have to tell it how to create those numbers
anyway, so it won't buy you much. IMHO the git contrib/continuous scripts can
do the same for you with much less overhead.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Teach mailsplit about Maildir's
From: Fernando J. Pereda @ 2007-05-21 18:17 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0705211355181.6410@racer.site>
On Mon, May 21, 2007 at 01:56:31PM +0100, Johannes Schindelin wrote:
>
> Should we not just stop when split_maildir() or split_mbox() returns -1?
> And yes, we'd probably need a second variable to do take the return value.
>
Sure, I'll send a new patch with that.
- ferdy
--
Fernando J. Pereda Garcimartín
20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4
^ permalink raw reply
* Re: [PATCH] Teach mailsplit about Maildir's
From: Fernando J. Pereda @ 2007-05-21 18:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vd50uj29r.fsf@assigned-by-dhcp.cox.net>
Signed-off-by: Fernando J. Pereda <ferdy@gentoo.org>
---
Documentation/git-am.txt | 8 ++-
Documentation/git-mailsplit.txt | 13 +++-
builtin-mailsplit.c | 139 ++++++++++++++++++++++++++++++++-------
builtin.h | 2 +-
4 files changed, 132 insertions(+), 30 deletions(-)
diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt
index ba79773..25cf84a 100644
--- a/Documentation/git-am.txt
+++ b/Documentation/git-am.txt
@@ -12,7 +12,8 @@ SYNOPSIS
'git-am' [--signoff] [--dotest=<dir>] [--keep] [--utf8 | --no-utf8]
[--3way] [--interactive] [--binary]
[--whitespace=<option>] [-C<n>] [-p<n>]
- <mbox>...
+ <mbox>|<Maildir>...
+
'git-am' [--skip | --resolved]
DESCRIPTION
@@ -23,9 +24,10 @@ current branch.
OPTIONS
-------
-<mbox>...::
+<mbox>|<Maildir>...::
The list of mailbox files to read patches from. If you do not
- supply this argument, reads from the standard input.
+ supply this argument, reads from the standard input. If you supply
+ directories, they'll be treated as Maildirs.
-s, --signoff::
Add `Signed-off-by:` line to the commit message, using
diff --git a/Documentation/git-mailsplit.txt b/Documentation/git-mailsplit.txt
index c11d6a5..abb0903 100644
--- a/Documentation/git-mailsplit.txt
+++ b/Documentation/git-mailsplit.txt
@@ -7,12 +7,15 @@ git-mailsplit - Simple UNIX mbox splitter program
SYNOPSIS
--------
-'git-mailsplit' [-b] [-f<nn>] [-d<prec>] -o<directory> [--] [<mbox>...]
+'git-mailsplit' [-b] [-f<nn>] [-d<prec>] -o<directory> [--] [<mbox>|<Maildir>...]
DESCRIPTION
-----------
-Splits a mbox file into a list of files: "0001" "0002" .. in the specified
-directory so you can process them further from there.
+Splits a mbox file or a Maildir into a list of files: "0001" "0002" .. in the
+specified directory so you can process them further from there.
+
+IMPORTANT: Maildir splitting relies upon filenames being sorted to output
+patches in the correct order.
OPTIONS
-------
@@ -20,6 +23,10 @@ OPTIONS
Mbox file to split. If not given, the mbox is read from
the standard input.
+<Maildir>::
+ Root of the Maildir to split. This directory should contain the cur, tmp
+ and new subdirectories.
+
<directory>::
Directory in which to place the individual messages.
diff --git a/builtin-mailsplit.c b/builtin-mailsplit.c
index 3bca855..454f943 100644
--- a/builtin-mailsplit.c
+++ b/builtin-mailsplit.c
@@ -6,9 +6,10 @@
*/
#include "cache.h"
#include "builtin.h"
+#include "path-list.h"
static const char git_mailsplit_usage[] =
-"git-mailsplit [-d<prec>] [-f<n>] [-b] -o<directory> <mbox>...";
+"git-mailsplit [-d<prec>] [-f<n>] [-b] -o<directory> <mbox>|<Maildir>...";
static int is_from_line(const char *line, int len)
{
@@ -96,44 +97,106 @@ static int split_one(FILE *mbox, const char *name, int allow_bare)
exit(1);
}
-int split_mbox(const char **mbox, const char *dir, int allow_bare, int nr_prec, int skip)
+static int populate_maildir_list(struct path_list *list, const char *path)
{
- char *name = xmalloc(strlen(dir) + 2 + 3 * sizeof(skip));
+ DIR *dir;
+ struct dirent *dent;
+
+ if ((dir = opendir(path)) == NULL) {
+ error("cannot diropen %s (%s)", path, strerror(errno));
+ return -1;
+ }
+
+ while ((dent = readdir(dir)) != NULL) {
+ if (dent->d_name[0] == '.')
+ continue;
+ path_list_insert(dent->d_name, list);
+ }
+
+ closedir(dir);
+
+ return 1;
+}
+
+static int split_maildir(const char *maildir, const char *dir,
+ int nr_prec, int skip)
+{
+ char file[PATH_MAX];
+ char curdir[PATH_MAX];
+ char name[PATH_MAX];
int ret = -1;
+ struct path_list list = {NULL, 0, 0, 1};
- while (*mbox) {
- const char *file = *mbox++;
- FILE *f = !strcmp(file, "-") ? stdin : fopen(file, "r");
- int file_done = 0;
+ snprintf(curdir, sizeof(curdir), "%s/cur", maildir);
+ if (populate_maildir_list(&list, curdir) < 0)
+ goto out;
- if ( !f ) {
- error("cannot open mbox %s", file);
+ int i;
+ for (i = 0; i < list.nr; i++) {
+ snprintf(file, sizeof(file), "%s/%s", curdir, list.items[i].path);
+ FILE *f = fopen(file, "r");
+ if (!f) {
+ error("cannot open mail %s (%s)", file, strerror(errno));
goto out;
}
if (fgets(buf, sizeof(buf), f) == NULL) {
- if (f == stdin)
- break; /* empty stdin is OK */
- error("cannot read mbox %s", file);
+ error("cannot read mail %s (%s)", file, strerror(errno));
goto out;
}
- while (!file_done) {
- sprintf(name, "%s/%0*d", dir, nr_prec, ++skip);
- file_done = split_one(f, name, allow_bare);
+ sprintf(name, "%s/%0*d", dir, nr_prec, ++skip);
+ split_one(f, name, 1);
+
+ fclose(f);
+ }
+
+ path_list_clear(&list, 1);
+
+ ret = skip;
+out:
+ return ret;
+}
+
+int split_mbox(const char *file, const char *dir, int allow_bare,
+ int nr_prec, int skip)
+{
+ char name[PATH_MAX];
+ int ret = -1;
+
+ FILE *f = !strcmp(file, "-") ? stdin : fopen(file, "r");
+ int file_done = 0;
+
+ if (!f) {
+ error("cannot open mbox %s", file);
+ goto out;
+ }
+
+ if (fgets(buf, sizeof(buf), f) == NULL) {
+ /* empty stdin is OK */
+ if (f != stdin) {
+ error("cannot read mbox %s", file);
+ goto out;
}
+ file_done = 1;
+ }
- if (f != stdin)
- fclose(f);
+ while (!file_done) {
+ sprintf(name, "%s/%0*d", dir, nr_prec, ++skip);
+ file_done = split_one(f, name, allow_bare);
}
+
+ if (f != stdin)
+ fclose(f);
+
ret = skip;
out:
- free(name);
return ret;
}
+
int cmd_mailsplit(int argc, const char **argv, const char *prefix)
{
- int nr = 0, nr_prec = 4, ret;
+ int nr = 0, nr_prec = 4, num = 0;
int allow_bare = 0;
const char *dir = NULL;
const char **argp;
@@ -186,9 +249,39 @@ int cmd_mailsplit(int argc, const char **argv, const char *prefix)
argp = stdin_only;
}
- ret = split_mbox(argp, dir, allow_bare, nr_prec, nr);
- if (ret != -1)
- printf("%d\n", ret);
+ while (*argp) {
+ const char *arg = *argp++;
+ struct stat argstat;
+ int ret = 0;
+
+ if (arg[0] == '-' && arg[1] == 0) {
+ ret = split_mbox(arg, dir, allow_bare, nr_prec, nr);
+ if (ret < 0) {
+ error("cannot split patches from stdin");
+ return 1;
+ }
+ num += ret;
+ continue;
+ }
+
+ if (stat(arg, &argstat) == -1) {
+ error("cannot stat %s (%s)", arg, strerror(errno));
+ return 1;
+ }
+
+ if (S_ISDIR(argstat.st_mode))
+ ret = split_maildir(arg, dir, nr_prec, nr);
+ else
+ ret = split_mbox(arg, dir, allow_bare, nr_prec, nr);
+
+ if (ret < 0) {
+ error("cannot split patches from %s", arg);
+ return 1;
+ }
+ num += ret;
+ }
+
+ printf("%d\n", num);
- return ret == -1;
+ return 0;
}
diff --git a/builtin.h b/builtin.h
index d3f3a74..39290d1 100644
--- a/builtin.h
+++ b/builtin.h
@@ -8,7 +8,7 @@ extern const char git_usage_string[];
extern void help_unknown_cmd(const char *cmd);
extern int mailinfo(FILE *in, FILE *out, int ks, const char *encoding, const char *msg, const char *patch);
-extern int split_mbox(const char **mbox, const char *dir, int allow_bare, int nr_prec, int skip);
+extern int split_mbox(const char *file, const char *dir, int allow_bare, int nr_prec, int skip);
extern void stripspace(FILE *in, FILE *out);
extern int write_tree(unsigned char *sha1, int missing_ok, const char *prefix);
extern void prune_packed_objects(int);
--
1.5.2
^ permalink raw reply related
* Re: GIT on MinGW problem
From: Nguyen Thai Ngoc Duy @ 2007-05-21 18:22 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <464ABAAF.C6603C5@eudaptics.com>
On 5/16/07, Johannes Sixt <J.Sixt@eudaptics.com> wrote:
> Han-Wen Nienhuys wrote:
> >
> > I think it might be a bug. Patches are welcome.
> >
> > I suppose git-clone has a hardcoded path. Paths under windows should
> > be either taken from registry (yuck) or dynamically detected from
> > $PATH and argv[0].
> >
> > 2007/5/15, Aaron Gray <angray@beeb.net>:
> > > Han-Wen,
> > >
> > > Dont know whether you got the message or not so I'll try you again.
> > >
> > > On doing a git-clone I get the message :-
> > >
> > > warning: templates not found /usr/share/git-core/templates/
> > >
>
> This should have been fixed by 2d84ffaf (currently master~1 in
> git://repo.or.cz/git/mingw.git) and its parent. Can you make sure that
> your build picks up the new Makefile setting that these commits
> introduce?
That commit didn't work for me because template_dir was overridden by
config.mak.autogen
--
Duy
^ permalink raw reply
* Re: Using git to store /etc, redux
From: Jan Hudec @ 2007-05-21 18:32 UTC (permalink / raw)
To: David Härdeman; +Cc: git
In-Reply-To: <20070519174815.GA5124@hardeman.nu>
[-- Attachment #1: Type: text/plain, Size: 1420 bytes --]
On Sat, May 19, 2007 at 19:48:15 +0200, David Härdeman wrote:
> I recently had the idea to store and track /etc using git. When googling
> the topic I came across the "Using git to store /etc" thread from the
> end of last year which provided some interesting details on what would
> be necessary.
>
> It seems the file metadata (owner, group, mode, xattrs, etc) was the big
> stumbling point, so I wrote up a tool over the last few days which
> allows the metadata to be stored in a separate file which can be stored
> along with the rest of the data in the repo (or separately).
>
> This is also useful for tripwire type checks and for other types of
> storage which drops some of the metadata (tar comes to mind)...
>
> The tool (metastore) is available from:
> git://git.hardeman.nu/metastore.git
>
> Not completely cleaned up yet (it lacks a real README and some Makefile
> targets) but I hope it might be useful to others (it sure is to me).
>
> Please CC me on any replies.
Have you looked at IsiSetup (http://www.isisetup.ch/, linked from
http://git.or.cz/gitwiki/InterfacesFrontendsAndTools) yet? It's a front-end
to git specifically targeted for versioning configuration. From a quick
glance at it's web I don't see whether it already stores the metadata you
describe, but in either case it could be interesting for you.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ 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