* [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: [RFC] Third round of support for cloning submodules
From: Sven Verdoolaege @ 2007-05-21 12:19 UTC (permalink / raw)
To: Martin Waitz; +Cc: git, Junio C Hamano
In-Reply-To: <20070521113415.GY5412@admingilde.org>
On Mon, May 21, 2007 at 01:34:15PM +0200, Martin Waitz wrote:
> hoi :)
>
> On Mon, May 21, 2007 at 12:14:55PM +0200, Sven Verdoolaege wrote:
> > How? AFAICS, it's upload-pack of the *clonee* that determines
> > where the actual git dir is. The cloner has no clue.
>
> we can just store the link to the workdir-or-gitdir and then try
> it out every time we access it. When clone stores the location
> of the parent repository it doesn't know what it points to, but
> fetch works, too.
clone is just init + fetch (well, almost).
The comment above applies to fetching as well.
skimo
^ permalink raw reply
* Re: Commit ID in exported Tar Ball
From: Petr Baudis @ 2007-05-21 12:09 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: René Scharfe, git, Junio C Hamano, Frank Lichtenheld,
Johan Herland, Thomas Glanzmann, Michael Gernoth
In-Reply-To: <20070521060231.GI3141@spearce.org>
On Mon, May 21, 2007 at 08:02:32AM CEST, Shawn O. Pearce wrote:
> Ren?? Scharfe <rene.scharfe@lsrfire.ath.cx> wrote:
> > Shawn O. Pearce schrieb:
> > >
> > > git-describe is more human-friendly than a SHA-1...
> >
> > Yes, and the Makefile does even more than that: it adds a version file,
> > a spec file and another version file for git-gui.
> >
> > The first two are probably useful for most projects that actually do
> > versioned releases. We could have a simple parser that reads a
> > template, replaces @@VERSION@@ with a git-describe output string and
> > adds the result as a synthetic file to the archive. It's not exactly
> > trivial -- e.g., how to specify git-describe options, template file and
> > synthetic name, all in one command line parameter? -- but it's doable.
>
> Maybe something just as simple as allowing the user to specify a
> shell script in-tree that we unpack and run for them? That script
> prints to stdout the content of the file to include.
Specify how? At the point of git-archive execution? At that point you
usually can append the file to the archive as well.
And if you make it somehow a "project default", that becomes a huge
security risk, since anyone who clones the project and runs git-archive
will execute aribtrary code on his account.
Besides, the original motivation for this were snapshots from gitweb.
Gitweb frequently does not run with the uid of the project owner, so
this becomes a security problem as well.
Maybe some kind of format-string in .git/config...
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Ever try. Ever fail. No matter. // Try again. Fail again. Fail better.
-- Samuel Beckett
^ permalink raw reply
* Re: [PATCH 1/6] Remove whitespace breakage from *.c files
From: Marco Costalba @ 2007-05-21 11:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vfy5rjhyq.fsf@assigned-by-dhcp.cox.net>
On 5/20/07, Junio C Hamano <junkio@cox.net> wrote:
> Your MUA seem to have munged all your patches in this series;
> and the breakage seems also to be in the "let apply eat the new
> trailing blank lines" patch.
>
I'm very sorry about this. I have set maximum length to 120 chars in
Thunderbird, but probably there's something more to tweak.
I can resend all the patches next week-end if you want. But please
feel free to create and apply the patches yourself when you prefer. 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.
Marco
^ permalink raw reply
* Re: [RFC] Third round of support for cloning submodules
From: Martin Waitz @ 2007-05-21 11:41 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: skimo, Alex Riesen, Junio C Hamano, git
In-Reply-To: <200705211244.16374.Josef.Weidendorfer@gmx.de>
[-- Attachment #1: Type: text/plain, Size: 1116 bytes --]
hoi :)
On Mon, May 21, 2007 at 12:44:16PM +0200, Josef Weidendorfer wrote:
> There should be a way for a superproject to specify useful sets of
> subprojects for different developer roles, and these sets should be
> versioned. It is also useful for a superproject to be able to say
> "for this subproject to work, that other subprojects needs to be
> checked out".
What subprojects to use is the responsibility of the build system and
we should not step on its shoes too much.
We should provide a simple way to populate a submodule, but all the
dependency handling should really be done in the build system /
package handling system on top of git, IMHO.
Perhaps we can simply provide "cd $subproject && git clone" to
automatically fetch all needed stuff from a default location and
checkout that subproject.
Then we can integrate that command in bitbake and whatnot or start
a new configuration management system on top of git which uses
dependencies from Makefiles etc. to automatically check out the
right set of subprojects. But that should really be on top of git.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ 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 11:39 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Robin Rosenberg, ydirson, git
In-Reply-To: <20070521101540.GB32510@diana.vm.bytemark.co.uk>
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.
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.
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.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [RFC] Third round of support for cloning submodules
From: Martin Waitz @ 2007-05-21 11:34 UTC (permalink / raw)
To: skimo; +Cc: git, Junio C Hamano
In-Reply-To: <20070521101455.GK942MdfPADPa@greensroom.kotnet.org>
[-- Attachment #1: Type: text/plain, Size: 438 bytes --]
hoi :)
On Mon, May 21, 2007 at 12:14:55PM +0200, Sven Verdoolaege wrote:
> How? AFAICS, it's upload-pack of the *clonee* that determines
> where the actual git dir is. The cloner has no clue.
we can just store the link to the workdir-or-gitdir and then try
it out every time we access it. When clone stores the location
of the parent repository it doesn't know what it points to, but
fetch works, too.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Teach 'git-apply --whitespace=strip' to remove empty lines at the end of file
From: Marco Costalba @ 2007-05-21 11:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vmyzyhdfh.fsf@assigned-by-dhcp.cox.net>
On 5/21/07, Junio C Hamano <junkio@cox.net> wrote:
> Junio C Hamano <junkio@cox.net> writes:
>
>
> We somehow end up removing one LF too many, like this:
>
> diff --git a/contrib/emacs/.gitignore b/contrib/emacs/.gitignore
> index c531d98..016d3b1 100644
> --- a/contrib/emacs/.gitignore
> +++ b/contrib/emacs/.gitignore
> @@ -1 +1 @@
> -*.elc
> +*.elc
> \ No newline at end of file
>
I also had that, but after adding
+
+ if (empty < trailing_added_lines)
+ empty--;
+
everything worked correctly. I made again the same test myself without problems.
I really don't understand how could be broken.
For me it's OK if you don't like my patch, but I would really
understand why that very strange error.
Thanks
Marco
^ permalink raw reply
* Re: [RFC] Third round of support for cloning submodules
From: Josef Weidendorfer @ 2007-05-21 10:44 UTC (permalink / raw)
To: skimo; +Cc: Alex Riesen, Junio C Hamano, git
In-Reply-To: <20070521095749.GI942MdfPADPa@greensroom.kotnet.org>
On Monday 21 May 2007, Sven Verdoolaege wrote:
> On Mon, May 21, 2007 at 12:26:21AM +0200, Alex Riesen wrote:
> > Sven Verdoolaege, Sun, May 20, 2007 23:47:32 +0200:
> > >
> > > How would _you_ specify which subprojects to checkout ?
> > >
> >
> > Aren't the ones which already have .git in them are kind of specified?
> >
>
> Would you always recurse into these submodules, regardless of
> any option?
> Or would you want two options, one for handling the submodules
> you have explicitly marked someway and one for getting all submodules?
There should be a way for a superproject to specify useful sets of
subprojects for different developer roles, and these sets should be
versioned. It is also useful for a superproject to be able to say
"for this subproject to work, that other subprojects needs to be
checked out".
Both issues could be supported with a "dependson" setting in .gitmodules
(or better call this file ".gitprojects"?)
[subproject "german-translation"]
path = lang/german
dependson = docbuilds
[subproject "all-translations"]
dependson = german-translation france-translation japanese-translation
The syntax here only is RFC, including the fact that this example
puts the subproject identifier into the key, and the path as config.
If we do not go the .gitattributes way, IMHO this is more logical.
When cloning, one should be allowed to specify the subprojects one wants
to track, e.g.
git-clone --subproject=all-translations ...
Josef
^ 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 10:15 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Robin Rosenberg, ydirson, git
In-Reply-To: <b0943d9e0705210231j75ef2e57o922f7899f4b5814b@mail.gmail.com>
On 2007-05-21 10:31:09 +0100, Catalin Marinas wrote:
> My plan is to release a 0.13 version pretty soon but without the DAG
> patches as we might have to test them a bit more.
That's reasonable.
> The release after 0.13 I'd like to be a 1.0-rc1 (including the DAG
> patches) unless we have some other major changes pending.
It'd be great to do away with the need to "stg init", but that
shouldn't really be a major change (but I haven't started looking at
it yet). It would be nice if 1.0 had documentation that didn't have to
mention "stg init".
> I don't think we can get much slower than this.
Oh yes we can ... :-)
> I modified stg to only load the modules needed for a given command
> but it still takes around 150ms for a command like 'top'. I don't
> know any other python tricks to make it start faster.
I don't either. 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.
> BTW, any of you would like to get added as a member to
> gna.org/projects/stgit (there are no advantages, only e-mail updates
> for filed bug reports)?
Free bug reports? Sure, I'm in! (I just created a Gna! account: kha)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [RFC] Third round of support for cloning submodules
From: Sven Verdoolaege @ 2007-05-21 10:14 UTC (permalink / raw)
To: Martin Waitz; +Cc: git, Junio C Hamano
In-Reply-To: <20070521100716.GX5412@admingilde.org>
On Mon, May 21, 2007 at 12:07:16PM +0200, Martin Waitz wrote:
> > The problem with relative paths is that you don't know if the
> > URL the user gave you points to the working directory or the
> > git directory of the project, but I guess I can let dump-config
> > tell you where it found the config file.
>
> We have already solved that in clone & fetch so I don't think this is a
> real problem.
How? AFAICS, it's upload-pack of the *clonee* that determines
where the actual git dir is. The cloner has no clue.
skimo
^ permalink raw reply
* Re: [RFC] Third round of support for cloning submodules
From: Martin Waitz @ 2007-05-21 10:07 UTC (permalink / raw)
To: skimo; +Cc: git, Junio C Hamano
In-Reply-To: <20070521085419.GG942MdfPADPa@greensroom.kotnet.org>
[-- Attachment #1: Type: text/plain, Size: 1711 bytes --]
hoi :)
On Mon, May 21, 2007 at 10:54:19AM +0200, Sven Verdoolaege wrote:
> On Mon, May 21, 2007 at 12:52:53AM +0200, Martin Waitz wrote:
> > That leads to submodules which store their objects within the
> > supermodule .git directory,
>
> My code clones submodules in .git/submodules/<submodule>, so
> that could be a good default.
good.
> > which would automatically obsolete the
> > need to specify explicit submodule URLs.
>
> Absolutely not. The subproject will likely have a life of its own.
> If you export it on the same machine, then why would you have two
> different URLs for the same project?
> Also, the subproject will typically not even be on the same site,
> so you _have_ to be able to specify a submodule URL.
> (I noticed that I forgot the "git://" protocol; I'll add that in
> the next round.)
Typically, you have to keep it on the same site because you have
some local adaptions which are only ment to be included within the
superproject. Think about distributions which seldomly use upstream
software completely unmodified.
Being able to configure it for other URLs is nice but by default it
should work without.
> > So back to your code: I don't like absolute URLs in the cloneable part
> > of the repository. We should try to stay with relative ones which
> > can stay the same everywhere.
>
> The problem with relative paths is that you don't know if the
> URL the user gave you points to the working directory or the
> git directory of the project, but I guess I can let dump-config
> tell you where it found the config file.
We have already solved that in clone & fetch so I don't think this is a
real problem.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC] Third round of support for cloning submodules
From: Sven Verdoolaege @ 2007-05-21 10:01 UTC (permalink / raw)
To: Steven Grimm; +Cc: Junio C Hamano, git
In-Reply-To: <4650EA2E.7070204@midwinter.com>
On Sun, May 20, 2007 at 05:39:10PM -0700, Steven Grimm wrote:
> Sven Verdoolaege wrote:
> >It's pretty easy to add a "submodule.*.skip" or "submodule.*.ignore".
> >Since the subcloning only happens at checkout, you could set these
> >before doing a checkout.
> >
>
> Can I take this to mean that you intend the default behavior to be to
> check out all subprojects, with individual ones suppressed via
> configuration as needed?
Or we could have a tri-state variable, with "yes" meaning handle
the submodule, "no" don't, and undefined meaning do whatever is
specified by the global submodules option.
Explicitly checking out a submodule could then set the variable to "yes".
skimo
^ permalink raw reply
* Re: [RFC] Third round of support for cloning submodules
From: Sven Verdoolaege @ 2007-05-21 9:57 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, git
In-Reply-To: <20070520222621.GG25462@steel.home>
On Mon, May 21, 2007 at 12:26:21AM +0200, Alex Riesen wrote:
> Sven Verdoolaege, Sun, May 20, 2007 23:47:32 +0200:
> >
> > How would _you_ specify which subprojects to checkout ?
> >
>
> Aren't the ones which already have .git in them are kind of specified?
>
Would you always recurse into these submodules, regardless of
any option?
Or would you want two options, one for handling the submodules
you have explicitly marked someway and one for getting all submodules?
skimo
^ permalink raw reply
* Re: [PATCH 1/2] Update the bash prompt from 'applied' instead of the obsolete 'current'
From: Catalin Marinas @ 2007-05-21 9:31 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Robin Rosenberg, ydirson, git
In-Reply-To: <20070521074838.GA32510@diana.vm.bytemark.co.uk>
On 21/05/07, Karl Hasselström <kha@treskal.com> wrote:
> On 2007-05-20 23:22:00 +0200, Robin Rosenberg wrote:
> > Calling stg is too slow to be be used here. I that command in my
> > first draft for this function and people complained (see the thread
> > named "Bash snippet to show branch and patch in bash prompt"). It
> > takes ~ 0.15s on here which is very noticable, barely below my pain
> > threshold.
> >
> > We'll update the prompt when and if Karl breaks this.
>
> Yes, I can confirm that I'm hard at work breaking this. :-) I'm trying
> out a way to get around the performance bug Catalin found, but I
> didn't have time to finish it yesterday.
My plan is to release a 0.13 version pretty soon but without the DAG
patches as we might have to test them a bit more. The release after
0.13 I'd like to be a 1.0-rc1 (including the DAG patches) unless we
have some other major changes pending.
> But it sucks that stg starts so slowly. It has gotten better, I
> believe (I think Catalin did some work here?), but 150 ms doesn't
> really qualify as "instantaneous".
I don't think we can get much slower than this. I modified stg to only
load the modules needed for a given command but it still takes around
150ms for a command like 'top'. I don't know any other python tricks
to make it start faster.
BTW, any of you would like to get added as a member to
gna.org/projects/stgit (there are no advantages, only e-mail updates
for filed bug reports)?
Regards.
--
Catalin
^ permalink raw reply
* problem with import-tars?
From: Joshua N Pritikin @ 2007-05-21 8:48 UTC (permalink / raw)
To: git
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:
joshua@emit:~/ev$ git commit
error: unable to read tree object HEAD
# On branch import-tars
error: unable to read tree object HEAD
[...snip...]
joshua@emit:~/ev$ git fsck-objects --full
warning in tree 05c3fd86565c57f128495d420565f813ba4b2535: contains empty
pathname
warning in tree 16f235c9367ca15e3a3a6709547e235f701a1ee5: contains empty
pathname
warning in tree 30f1e3c3926c52094bf6bb182906feed0cad2da1: contains empty
pathname
warning in tree 528e0a55edc527f8f8a14d33057a6003ec87071d: contains empty
pathname
warning in tree 5818056708134bbd4217195b32c65feed0527547: contains empty
pathname
warning in tree 75382de0c9f403cb2c72e56b255a617c43bcd679: contains empty
pathname
warning in tree a66bbc0c86757d18f187079d1f25bbaea19fc29c: contains empty
pathname
warning in tree aa17744c47e7b8898e956b8d8e246f8b0b9860d8: contains empty
pathname
warning in tree b120f845d24d7736aab58f04745c03a54366d68f: contains empty
pathname
warning in tree eb650564f413d4a3fb67ca5f0c4e8dac08262f52: contains empty
pathname
How do I proceed? I upgraded to 1:1.5.1.4-2 but the problem persists.
--
Make April 15 just another day, visit http://fairtax.org
^ permalink raw reply
* Re: Fwd: Problem: git doesn't update working dir (always) when checkout'ing other branch
From: Andy Parkins @ 2007-05-21 9:16 UTC (permalink / raw)
To: git; +Cc: Stian Haklev
In-Reply-To: <566574ef0705210159m69d4e32cjd4bc5db66c1677b1@mail.gmail.com>
On Monday 2007 May 21, Stian Haklev wrote:
What does "git --version" say?
> ~wiki/> git checkout trying-new-feature
> checked out
> ~wiki/> git status
> no files updated
> ~wiki/> git checkout master
> checked out
> ~wiki/> git status
> it then puts me directly into commit mode, with every file having a
> ton of differences - because the files are still from
> trying-new-feature and the index is pointing at master.
Something has gone very wrong here. You are right to be confused, that is not
what one would expect from git. After a git-checkout you should expect that
the index is clean.
Did you get any error messages during any of those operations?
Are you sure you aren't doing something like
git checkout trying-new-feature -- list of files
As that would update the working tree but not the current HEAD, and would
therefore appear as changes to master.
When you do the final git-status, are the files being listed in the "Changed
but not updated" section or the "Changes to be committed" section?
Can you make a minimal test case? e.g.
mkdir testing-git; cd testing-git
git init
date > file1
git add file1
git commit -a -m "step1"
date >> file1
git commit -a -m "step2"
git checkout -b newbranch HEAD^
date >> file1
git commit -a -m "step3"
git checkout master
git checkout newbranch
git status
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: just fetching HEAD of repository
From: Matthieu Moy @ 2007-05-21 9:08 UTC (permalink / raw)
To: Stian Haklev; +Cc: git
In-Reply-To: <566574ef0705210201wc5c0adbmaa22d197b16bf72d@mail.gmail.com>
"Stian Haklev" <shaklev@gmail.com> writes:
> After checking all the docs, I am still wondering if there is a way to
> get only the last commit from a given git repository. Sometimes I
> really just want the latest code so I can compile it - and let's say
> they are not running gitweb, or it is not convenient to go to gitweb
> and ask for a tar package to be made? This is especially relevant in
> countries with slow internet connection - here in Indonesia it takes
> me an hour to clone the git repository for example, never mind let's
> say the Linux kernel.
You'll probably pay the price for not downloading the full history
later, but yes, what you're looking for is called "shallow clone", and
it's possible with the --depth option of git-clone (I personnally
never tried it, though).
Side question: once you have a shallow clone, is it possible to
"unshallow" it, that is, fetch the missing revisions?
--
Matthieu
^ permalink raw reply
* just fetching HEAD of repository
From: Stian Haklev @ 2007-05-21 9:01 UTC (permalink / raw)
To: git
After checking all the docs, I am still wondering if there is a way to
get only the last commit from a given git repository. Sometimes I
really just want the latest code so I can compile it - and let's say
they are not running gitweb, or it is not convenient to go to gitweb
and ask for a tar package to be made? This is especially relevant in
countries with slow internet connection - here in Indonesia it takes
me an hour to clone the git repository for example, never mind let's
say the Linux kernel.
Thank you
Stian
^ permalink raw reply
* Re: [PATCH] Teach 'git-apply --whitespace=strip' to remove empty lines at the end of file
From: Josef Weidendorfer @ 2007-05-21 8:59 UTC (permalink / raw)
To: Marco Costalba; +Cc: Frank Lichtenheld, Junio C Hamano, Git Mailing List
In-Reply-To: <e5bfff550705201344r274ac9f4g9ca5e1fefe7c12cd@mail.gmail.com>
On Sunday 20 May 2007, Marco Costalba wrote:
> On 5/20/07, Frank Lichtenheld <frank@lichtenheld.de> wrote:
> > > >
> > > >But we have kept our sources -Wdeclaration-after-statement
> > > >clean so far
> > >
> > > ??????
> > >
> > > Wie bitte?
> >
> > man gcc:
> >
> > -Wdeclaration-after-statement (C only)
> > Warn when a declaration is found after a statement in a block.
> >
>
> Just for my personal knowledge, what's the meaning of this apparently
> non-sense kind of warning?
man gcc:
-Wdeclaration-after-statement (C only)
Warn when a declaration is found after a statement in a block. This con-
struct, known from C++, was introduced with ISO C99 and is by default allowed
in GCC. It is not supported by ISO C90 and was not supported by GCC versions
before GCC 3.0.
There are some C compilers out there which break out with an error when
using declaration after a statement; however, we want git code to compile
even using these compilers.
Josef
>
> Thanks
> Marco
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Fwd: Problem: git doesn't update working dir (always) when checkout'ing other branch
From: Stian Haklev @ 2007-05-21 8:59 UTC (permalink / raw)
To: git
In-Reply-To: <566574ef0705210157j14cb7c56h62392c6193472a98@mail.gmail.com>
Newbie to git, but I've been reading up on the docs and I really love
both the theory and what it let's you do (still confused by some
issues like rebasing and stuff). For now I mostly use it on my own
small projects (where I frequently make branches, merge, cherry-pick
etc), and also push it to repo.or.cz.
One confusing thing to me is that if I am in a clean state (no updated
files in working dir), and I checkout another branch (or another
treeish), sometimes git doesn't update the working dir, and sometimes
it does. So for example in my own repo I do
~wiki/> git status
no files updated
~wiki/> git checkout trying-new-feature
checked out
~wiki/> git status
no files updated
(this is how it should be obviously - the working dir reflects the
index which is now pointing at trying-new-feature, but then...)
~wiki/> git checkout master
checked out
~wiki/> git status
it then puts me directly into commit mode, with every file having a
ton of differences - because the files are still from
trying-new-feature and the index is pointing at master.
It also seems to do inconsistent things with files that exist in only
one of the branches - ie if switching back the file remains in the
directory but is now an "untracked" file, etc.
Maybe I am completely misunderstanding and there is something I should
do differently. It works out if I do git reset --hard, but it just
seems so uneccessary. (As I said, in all cases the working dir is
completely clean before doing the checkout).
thank you
Stian
^ permalink raw reply
* Re: [RFC] Third round of support for cloning submodules
From: Sven Verdoolaege @ 2007-05-21 8:54 UTC (permalink / raw)
To: Martin Waitz; +Cc: git, Junio C Hamano
In-Reply-To: <20070520225252.GO5412@admingilde.org>
On Mon, May 21, 2007 at 12:52:53AM +0200, Martin Waitz wrote:
> That leads to submodules which store their objects within the
> supermodule .git directory,
My code clones submodules in .git/submodules/<submodule>, so
that could be a good default.
> which would automatically obsolete the
> need to specify explicit submodule URLs.
Absolutely not. The subproject will likely have a life of its own.
If you export it on the same machine, then why would you have two
different URLs for the same project?
Also, the subproject will typically not even be on the same site,
so you _have_ to be able to specify a submodule URL.
(I noticed that I forgot the "git://" protocol; I'll add that in
the next round.)
> So back to your code: I don't like absolute URLs in the cloneable part
> of the repository. We should try to stay with relative ones which
> can stay the same everywhere.
The problem with relative paths is that you don't know if the
URL the user gave you points to the working directory or the
git directory of the project, but I guess I can let dump-config
tell you where it found the config file.
skimo
^ permalink raw reply
* Re: Git branching & pulling
From: Josef Weidendorfer @ 2007-05-20 20:30 UTC (permalink / raw)
To: Wink Saville; +Cc: Junio C Hamano, Steven Grimm, git
In-Reply-To: <d4cf37a60705190931rca1187ap9b98becb6c7c3b2a@mail.gmail.com>
On Saturday 19 May 2007, Wink Saville wrote:
> wink@ic2d1:~/testgit-clone$ git-checkout -b test master
> Switched to a new branch "test"
> wink@ic2d1:~/testgit-clone$ git-pull .
> Already up-to-date.
> wink@ic2d1:~/testgit-clone$ git-pull . master
> Already up-to-date.
> wink@ic2d1:~/testgit-clone$ git-pull
> Warning: No merge candidate found because value of config option
> "branch.test.merge" does not match any remote branch fetched.
> No changes.
> wink@ic2d1:~/testgit-clone$
>
> Why did last git-pull generate the warning, this seems wrong?
Because git does not know what to merge; there is no config entry
for "branch.test.merge", as the warning says. How would you reword
this warning to make it easier to understand?
But from your question, I assume that you expected git to have a
"branch.test.merge" setting.
What do you expect it to do? And why?
Is my assumption correct that you want the last command to be equivalent
to "git-pull . master"? And my further assumption, that you want this
because you expect "git pull" to default to merging changes from its
upstream (also when the upstream is local)?
Creation of a branch from another local one never has created
"branch.x.remote" or "branch.x.merge" entries. I am not even sure
that setting "branch.x.remote" to "." is working in the current version.
BTW: There was some old behavior of "git pull" to always pull the master
branch from remote "origin" without any further parameters. I suppose that
you did not want this to happen in your example above ?!
Josef
^ permalink raw reply
* Re: [PATCH] Cross-reference the manpages for git-name-rev and git-describe
From: Matthieu Moy @ 2007-05-21 8:01 UTC (permalink / raw)
To: Junio C Hamano
Cc: Shawn O. Pearce, Brian Gernhardt, Anand Kumria, git,
Johannes Schindelin
In-Reply-To: <7viramfwkq.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
>> Junio C Hamano <junkio@cox.net> wrote:
>>> wouldn't this be useful?
>>>
>>> $ git-describe --contains --tags 1b600e659
>>> v1.5.0-rc3~34
[ I didn't receive this message, and gmane doesn't seem to have it.
Strange ]
>> Like this? ;-)
>
> Yeah, something like that.
>
> Now we need to make sure that the name of the option --contains
> is sane, I guess.
It seems OK to me. Perhaps --forward (optionally with a --backward
overriding it) could do too.
--
Matthieu
^ permalink raw reply
* [PATCH] git-daemon: don't ignore pid-file write failure
From: Jim Meyering @ 2007-05-21 7:58 UTC (permalink / raw)
To: git
Note: since the consequence of failure is to call die,
I don't bother to close "f".
Signed-off-by: Jim Meyering <jim@meyering.net>
---
daemon.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/daemon.c b/daemon.c
index e74ecac..674e30d 100644
--- a/daemon.c
+++ b/daemon.c
@@ -970,8 +970,8 @@ static void store_pid(const char *path)
FILE *f = fopen(path, "w");
if (!f)
die("cannot open pid file %s: %s", path, strerror(errno));
- fprintf(f, "%d\n", getpid());
- fclose(f);
+ if (fprintf(f, "%d\n", getpid()) < 0 || fclose(f) != 0)
+ die("failed to write pid file %s: %s", path, strerror(errno));
}
static int serve(char *listen_addr, int listen_port, struct passwd *pass, gid_t gid)
--
1.5.2
^ permalink raw reply related
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