* codeBeamer, Collaborative ALM Solution for Git and Android
From: Intland Software @ 2009-09-14 12:49 UTC (permalink / raw)
To: git
Intland Software announces the availability of codeBeamer 5.4, the
award winning Collaborative Application Lifecycle Management Solution
for distributed software development. Today's challenge is to tackle
*Android sized projects* with 2GB of code and hundreds of thousands of
change sets, and codeBeamer 5.4 is capable of processing these
repositories.
Version highlights:
* Issue escalation with hierarchic working calendars
* Calculated tracker fields with rich formula
* Wiki page editing directly in Microsoft Word
* Scalable version control management
* Major enhancements in supporting Git and Mercurial
* Revised search: more relevancy, richer query syntax, friendlier interface
Links
* Product homepage: http://www.intland.com/products/cb/overview.html
* FREE download (no expiration!):
http://www.intland.com/products/download.html#download
* FREE hosted version: http://www.intland.com/products/download.html#trial
^ permalink raw reply
* Re: [PATCH 2/2] remove NORETURN from function pointers
From: Jeff King @ 2009-09-14 12:44 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: git, Erik Faye-Lund
In-Reply-To: <40aa078e0909140532q693a7f9qc3d9b1d354cac356@mail.gmail.com>
On Mon, Sep 14, 2009 at 02:32:38PM +0200, Erik Faye-Lund wrote:
> Compiling the following code gives a warning about unreachable code,
> so it's clear that msvc doesn't simply ignore the directive. I'm not
> saying that anyone suggested otherwise, I just wanted to know for
> sure.
>
> #include <stdio.h>
> #include <stdlib.h>
> void (*exit_fun)(int) = exit;
> void __declspec(noreturn) die(void);
> void die(void) { exit_fun(1); }
> int main(void) { printf("hello!\n"); die(); printf("world!\n"); }
Right. What I'm guessing is that it sees the noreturn on die(), but then
doesn't actually look inside die to confirm that the noreturn is upheld.
You could test that with:
#include <stdlib.h>
void __declspec(noreturn) die(void);
void die(void) { }
int main(void) { die(); }
If it doesn't complain, then I am right. If it does, then it is
something magic with the function pointer (presumably it decides that
the function pointer could exit, so it stops the analysis and gives your
code the benefit of the doubt).
> First of all, MSVC is not the only compiler that behaves this way. In
> fact, GCC the only compiler I've found that behaves this way (but I
> must admit, I only tested 4 different compilers, one of which (Comeau)
> does not support noreturn at all AFAICT). That behavior might be
> crappy, but it's not "MSVC's crappy noreturn handling" - it's
> "non-GCC's crappy noreturn handling" :P
Well, OK, I'll accept that. ;)
> The arguments against each solution I see are these:
> - abort() gives a run-time error instead of a compile-time warning, so
> breakage is trickier to detect (on GCC, which seems to be the target
> compiler for the vast majority of git-developers).
> - NORETURN_PTR might be bit big of a hammer for a small problem, as it
> "pollutes" the whole git source-tree instead of just usage.c.
I don't know that NORETURN_PTR pollutes the whole source-tree. At least
no more than NORETURN does. The only functions that will need it are
these two function pointers.
But I think your analysis is generally correct. It's not going to make a
big difference which is chosen.
-Peff
^ permalink raw reply
* Re: [PATCH 2/2] remove NORETURN from function pointers
From: Erik Faye-Lund @ 2009-09-14 12:32 UTC (permalink / raw)
To: Jeff King; +Cc: git, Erik Faye-Lund
In-Reply-To: <20090914120311.GA17172@sigill.intra.peff.net>
Compiling the following code gives a warning about unreachable code,
so it's clear that msvc doesn't simply ignore the directive. I'm not
saying that anyone suggested otherwise, I just wanted to know for
sure.
#include <stdio.h>
#include <stdlib.h>
void (*exit_fun)(int) = exit;
void __declspec(noreturn) die(void);
void die(void) { exit_fun(1); }
int main(void) { printf("hello!\n"); die(); printf("world!\n"); }
On Mon, Sep 14, 2009 at 2:03 PM, Jeff King <peff@peff.net> wrote:
> I think I am fine doing it either way. The NORETURN_PTR thing is a bit
> more elegant to me, but that is maybe just my gcc snobiness. We
> shouldn't have to change our code to accomodate MSVC's crappy noreturn
> handling. ;)
First of all, MSVC is not the only compiler that behaves this way. In
fact, GCC the only compiler I've found that behaves this way (but I
must admit, I only tested 4 different compilers, one of which (Comeau)
does not support noreturn at all AFAICT). That behavior might be
crappy, but it's not "MSVC's crappy noreturn handling" - it's
"non-GCC's crappy noreturn handling" :P
The arguments against each solution I see are these:
- abort() gives a run-time error instead of a compile-time warning, so
breakage is trickier to detect (on GCC, which seems to be the target
compiler for the vast majority of git-developers).
- NORETURN_PTR might be bit big of a hammer for a small problem, as it
"pollutes" the whole git source-tree instead of just usage.c.
Anyway, I don't care much what solution we pick. Either should work,
and if someone has strong preference, I'm OK with it.
--
Erik "kusma" Faye-Lund
kusmabite@gmail.com
(+47) 986 59 656
^ permalink raw reply
* Re: [PATCH 2/2] remove NORETURN from function pointers
From: Jeff King @ 2009-09-14 12:04 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: git, Erik Faye-Lund
In-Reply-To: <40aa078e0909140456l47cfce92yc44262c96b59bf2d@mail.gmail.com>
On Mon, Sep 14, 2009 at 01:56:29PM +0200, Erik Faye-Lund wrote:
> > That's odd. It's listed in my git-folder on GMail as sent to the
> > mailing-list, but I can't find it in any of the list-archives. They
> > were both sent through the same instance of "git send-email". I guess
> > I'll just re-send it.
>
> OK, I think I figured out why: For some reason, the From-field of the
> mail had gotten changed from kus...e@gmail.com to
> kus...e@googlemail.com, and that's not the address I'm subsribed to
> this list as. I hope whoever manages the list is able to remove my
> duplicates from the moderation-queue or something ;)
I doubt that is it; you don't have to be subscribed to post.
-Peff
^ permalink raw reply
* Re: [PATCH 2/2] remove NORETURN from function pointers
From: Jeff King @ 2009-09-14 12:03 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: git, Erik Faye-Lund
In-Reply-To: <40aa078e0909140440x2e189957uf66f36ff29bef302@mail.gmail.com>
On Mon, Sep 14, 2009 at 01:40:02PM +0200, Erik Faye-Lund wrote:
> > I didn't see a patch 1/2, so maybe it impacts this in some way, but by
> > itself, I don't think this patch is a good idea. See below.
>
> That's odd. It's listed in my git-folder on GMail as sent to the
> mailing-list, but I can't find it in any of the list-archives. They
> were both sent through the same instance of "git send-email". I guess
> I'll just re-send it. It shouldn't affect this patch directly, though.
Possibly it got swallowed by vger's list filter. The taboo list is here:
http://vger.kernel.org/majordomo-taboos.txt
> > I think the right solution to turn on NORETURN for (2) is to split it
> > into two cases: NORETURN and NORETURN_PTR. Gcc platforms can define both
> > identically, platforms under (2) above can define NORETURN_PTR as empty,
> > and (3) will keep both off.
>
> Yeah, this could work. I initially suggested doing this, but Junio
> suggested removing NORETURN all together. I didn't think that was a
> good idea for die() etc, thus this patch.
Doing it this way would keep warnings on compilers that could use them.
I am generally of the opinion that since most development happens on
gcc, it is "good enough" to let gcc warnings help us find broken code,
and then those fixes will be available to users of less-capable
compilers. And we don't have to bend over backwards in the code with
little hacks to trick all compilers into not issuing a warning (like
calling abort() after something we already know is going to exit).
The downside of that attitude is that code that is not exercised by gcc
builds does not get the benefit. And in the case of MSVC, there is
probably quite a bit of code in #ifdef's that gcc will never even parse.
So maybe a hack like abort() is worthwhile in this case.
> > #include <stdlib.h>
> > void (*exit_fun)(int) = exit;
> > static void die(void) __attribute__((__noreturn__));
> > static void die(void) { exit_fun(1); }
> > int main(void) { die(); }
>
> Well, it fails to compile ;)
>
> If your change it around this way (which is basically what 1/2 + a
> separate patch that is cooking in msysgit for a litte while longer is
> supposed to do), it does compiles without warnings even on the highest
> warning level:
>
> -static void die(void) __attribute__((__noreturn__));
> +static void __declspec(noreturn) die(void);
Hmm. So either it doesn't bother checking that noreturn functions don't
return, or it assumes that a function pointer may exit. Interesting,
but I guess it doesn't change the main point too much: it's not as
strict as gcc's checking.
> Yeah. So we need a portable (enough) way of showing it that it does
> die. How about abort()?
>
> -static void die(void) { exit_fun(1); }
> +static void die(void) { exit_fun(1); abort(); }
>
> Adding abort() makes the warning go away here, at least. And reaching
> this point is an error anyway, it means that one of the functions
> passed to set_die_routine() does not hold up it's guarantees. Your
> suggestion (double defines) would make this a compile-time warning
> instead of a run-time error, which I find much more elegant. However,
> it's questionable how much this means in reality - there's only two
> call-sites for set_die_routine() ATM. Do we expect it to grow a lot?
No, I don't think we expect it to grow. Mostly this is about documenting
our assumptions so that gcc can do the right thing in making die() a
noreturn function, which is what we actually care about. We would notice
very quickly, I think, if a die() handler did not actually exit.
I think I am fine doing it either way. The NORETURN_PTR thing is a bit
more elegant to me, but that is maybe just my gcc snobiness. We
shouldn't have to change our code to accomodate MSVC's crappy noreturn
handling. ;)
-Peff
^ permalink raw reply
* Re: [PATCH 2/2] remove NORETURN from function pointers
From: Erik Faye-Lund @ 2009-09-14 11:56 UTC (permalink / raw)
To: Jeff King; +Cc: git, Erik Faye-Lund
In-Reply-To: <40aa078e0909140440x2e189957uf66f36ff29bef302@mail.gmail.com>
On Mon, Sep 14, 2009 at 1:40 PM, Erik Faye-Lund
<kusmabite@googlemail.com> wrote:
> On Mon, Sep 14, 2009 at 12:57 PM, Jeff King <peff@peff.net> wrote:
>>
>> I didn't see a patch 1/2, so maybe it impacts this in some way, but by
>> itself, I don't think this patch is a good idea. See below.
>
> That's odd. It's listed in my git-folder on GMail as sent to the
> mailing-list, but I can't find it in any of the list-archives. They
> were both sent through the same instance of "git send-email". I guess
> I'll just re-send it.
OK, I think I figured out why: For some reason, the From-field of the
mail had gotten changed from kus...e@gmail.com to
kus...e@googlemail.com, and that's not the address I'm subsribed to
this list as. I hope whoever manages the list is able to remove my
duplicates from the moderation-queue or something ;)
--
Erik "kusma" Faye-Lund
kusmabite@gmail.com
(+47) 986 59 656
^ permalink raw reply
* [PATCH 1/2] increase portability of NORETURN declarations
From: Erik Faye-Lund @ 2009-09-14 11:49 UTC (permalink / raw)
To: git; +Cc: Erik Faye-Lund
Some compilers (including at least MSVC) supports NORETURN
on function declarations, but only before the function-name.
This patch makes it possible to define NORETURN for those compilers.
Signed-off-by: Erik Faye-Lund <kusmab...@gmail.com>
---
This patch requires specifying "-C 2" to "git am" to apply to the
current maint(7fb6bcf), but I suspect that it's not really needed
there. Supporting new compilers is going to require additional
patching anyway.
git-compat-util.h | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/git-compat-util.h b/git-compat-util.h
index e5e9f39..5876d91 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -177,9 +177,9 @@ extern char *gitbasename(char *);
#include "compat/bswap.h"
/* General helper functions */
-extern void usage(const char *err) NORETURN;
-extern void die(const char *err, ...) NORETURN __attribute__((format (printf, 1, 2)));
-extern void die_errno(const char *err, ...) NORETURN __attribute__((format (printf, 1, 2)));
+extern NORETURN void usage(const char *err);
+extern NORETURN void die(const char *err, ...) __attribute__((format (printf, 1, 2)));
+extern NORETURN void die_errno(const char *err, ...) __attribute__((format (printf, 1, 2)));
extern int error(const char *err, ...) __attribute__((format (printf, 1, 2)));
extern void warning(const char *err, ...) __attribute__((format (printf, 1, 2)));
--
1.6.4.msysgit.0.16.gd92d4.dirty
^ permalink raw reply related
* Re: [PATCH 2/2] remove NORETURN from function pointers
From: Erik Faye-Lund @ 2009-09-14 11:40 UTC (permalink / raw)
To: Jeff King; +Cc: git, Erik Faye-Lund
In-Reply-To: <20090914105750.GB9216@sigill.intra.peff.net>
On Mon, Sep 14, 2009 at 12:57 PM, Jeff King <peff@peff.net> wrote:
>
> I didn't see a patch 1/2, so maybe it impacts this in some way, but by
> itself, I don't think this patch is a good idea. See below.
That's odd. It's listed in my git-folder on GMail as sent to the
mailing-list, but I can't find it in any of the list-archives. They
were both sent through the same instance of "git send-email". I guess
I'll just re-send it. It shouldn't affect this patch directly, though.
The patch basically moved the NORETURN before the function-name, as
this is a placement where more compilers supports
declaration-specifications.
>> ---
>>
>> __attribute__((noreturn)) is, according to the GCC documentation, about
>> two things: code generation (performance, really) and warnings.
>>
>> On the warnings-side, we need to keep the code warning-free for
>> compilers who doesn't support noreturn anyway, so hiding potential
>> warnings through this mechanism is probably not a good idea in the
>> first place.
>
> [Your justification text would almost certainly be useful as part of the
> commit message itself, and should go there.]
OK, I'll include it in the next round.
> Unfortunately, this patch _introduces_ warnings when running with gcc,
> as it now thinks those function pointers return (which means it thinks
> die() returns). So simply removing the NORETURN is not a good idea.
Yeah, this is unacceptable. I can't believe I missed this - sorry about that!
> If I understand you correctly, the problem is that there are actually
> three classes of compilers:
>
> 1. Ones which understand some NORETURN syntax for both functions and
> function pointers, and correctly trace returns through both (e.g.,
> gcc).
>
> 2. Ones which understand some NORETURN syntax for just functions, and
> complain about it on function pointers. We currently turn off
> NORETURN for these compilers (from your commit message, MSVC,
> for example).
>
> 3. Ones which have no concept of NORETURN at all.
>
> I think the right solution to turn on NORETURN for (2) is to split it
> into two cases: NORETURN and NORETURN_PTR. Gcc platforms can define both
> identically, platforms under (2) above can define NORETURN_PTR as empty,
> and (3) will keep both off.
Yeah, this could work. I initially suggested doing this, but Junio
suggested removing NORETURN all together. I didn't think that was a
good idea for die() etc, thus this patch.
> I do have to wonder, though. What do compilers that fall under (2) do
> with calls to function pointers from NORETURN functions? Do they assume
> they don't return, or that they do? Or do they not check that NORETURN
> functions actually don't return?
>
> I.e., what does this program do under MSVC:
>
> #include <stdlib.h>
> void (*exit_fun)(int) = exit;
> static void die(void) __attribute__((__noreturn__));
> static void die(void) { exit_fun(1); }
> int main(void) { die(); }
Well, it fails to compile ;)
If your change it around this way (which is basically what 1/2 + a
separate patch that is cooking in msysgit for a litte while longer is
supposed to do), it does compiles without warnings even on the highest
warning level:
-static void die(void) __attribute__((__noreturn__));
+static void __declspec(noreturn) die(void);
> In gcc, it rightly complains:
>
> foo.c: In function ‘die’:
> foo.c:4: warning: ‘noreturn’ function does return
Yeah. So we need a portable (enough) way of showing it that it does
die. How about abort()?
-static void die(void) { exit_fun(1); }
+static void die(void) { exit_fun(1); abort(); }
Adding abort() makes the warning go away here, at least. And reaching
this point is an error anyway, it means that one of the functions
passed to set_die_routine() does not hold up it's guarantees. Your
suggestion (double defines) would make this a compile-time warning
instead of a run-time error, which I find much more elegant. However,
it's questionable how much this means in reality - there's only two
call-sites for set_die_routine() ATM. Do we expect it to grow a lot?
--
Erik "kusma" Faye-Lund
kusmabite@gmail.com
(+47) 986 59 656
^ permalink raw reply
* Re: could not detach HEAD error didn't identify the cause of the issue
From: Jeff King @ 2009-09-14 11:22 UTC (permalink / raw)
To: Ben Bradshaw; +Cc: git
In-Reply-To: <4AAD8AE0.9070305@catalyst.net.nz>
On Mon, Sep 14, 2009 at 12:14:24PM +1200, Ben Bradshaw wrote:
> I was asked to post this issue to the list, I've just had git tell me it
> can't detach HEAD which left me scratching mine as to the cause and fix.
> Turns out if I have local untracked files that the remote branch also
> has then this error will trigger. I have included my shell backlog
> (client data removed). In this example the site_map folder was present
> on master and I had a local, untracked copy.
>
> git can obviosly detect this issue and stop my local copy getting in a
> bad state, but an error message such as "sites/all/modules/site_map/ is
> present in HEAD but is untracked locally, unable to apply changes" (or
> something to point the finger) would be much appreciated.
I couldn't reproduce it here; I get such a message.
# set up forked repo, "another" exists only on master
$ mkdir repo && cd repo
$ git init
$ echo content >file && git add file && git commit -m base
$ echo content >another && git add another && git commit -m another
$ git checkout -b other HEAD^
$ echo changes >file && git commit -a -m changes
# add untracked "another" here
$ echo untracked >another
# try rebase
$ git rebase master
First, rewinding head to replay your work on top of it...
error: Untracked working tree file 'another' would be overwritten by merge.
could not detach HEAD
# try git pull --rebase, in case it hides the message
$ git config branch.other.remote .
$ git config branch.other.merge refs/heads/master
$ git pull --rebase
From .
* branch master -> FETCH_HEAD
First, rewinding head to replay your work on top of it...
error: Untracked working tree file 'another' would be overwritten by merge.
could not detach HEAD
I'll admit the "could not detach HEAD" message would probably be better as:
rebase: unable to move HEAD to 'master', aborting rebase
or something similar.
What version of git are you using? What does my test case above produce
for you?
-Peff
^ permalink raw reply
* Re: Confusing git pull error message
From: Jeff King @ 2009-09-14 11:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: John Tapsell, Git List
In-Reply-To: <7v1vmar353.fsf@alter.siamese.dyndns.org>
On Sun, Sep 13, 2009 at 01:38:48PM -0700, Junio C Hamano wrote:
> I saw some discussion on improving the wording. Here is what I plan to
> commit.
>
> diff --git a/git-pull.sh b/git-pull.sh
> index 0bbd5bf..2c2fa79 100755
> --- a/git-pull.sh
> +++ b/git-pull.sh
> @@ -89,6 +89,8 @@ error_on_no_merge_candidates () {
> done
>
> curr_branch=${curr_branch#refs/heads/}
> + upstream=$(git config "branch.$curr_branch.merge" ||
> + git config "branch.$curr_branch.rebase")
Argh, I made a mistake in my original patch which was retained in your
version. For some reason I was thinking that "branch.*.rebase" was an
_alternative_ to branch.*.merge, but it is in fact a bool that modifies
how we interpret branch.*.merge (I think when the feature was originally
discussed, that was one such proposal, and as I am not a user of the
feature, I proceeded with a totally bogus mental model since then).
So this really should read simply:
upstream=$(git config "branch.$curr_branch.merge")
-Peff
^ permalink raw reply
* Re: [PATCH 2/2] remove NORETURN from function pointers
From: Jeff King @ 2009-09-14 10:57 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: git, Erik Faye-Lund
In-Reply-To: <1252923370-5768-2-git-send-email-kusmabite@gmail.com>
On Mon, Sep 14, 2009 at 12:16:10PM +0200, Erik Faye-Lund wrote:
> From: Erik Faye-Lund <kusmabite@googlemail.com>
>
> Some compilers (including at least MSVC and ARM RVDS) supports
> NORETURN on function declarations, but not on function pointers.
>
> This patch makes it possible to define NORETURN for these compilers.
>
> Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
I didn't see a patch 1/2, so maybe it impacts this in some way, but by
itself, I don't think this patch is a good idea. See below.
> ---
>
> __attribute__((noreturn)) is, according to the GCC documentation, about
> two things: code generation (performance, really) and warnings.
>
> On the warnings-side, we need to keep the code warning-free for
> compilers who doesn't support noreturn anyway, so hiding potential
> warnings through this mechanism is probably not a good idea in the
> first place.
[Your justification text would almost certainly be useful as part of the
commit message itself, and should go there.]
Unfortunately, this patch _introduces_ warnings when running with gcc,
as it now thinks those function pointers return (which means it thinks
die() returns). So simply removing the NORETURN is not a good idea.
If I understand you correctly, the problem is that there are actually
three classes of compilers:
1. Ones which understand some NORETURN syntax for both functions and
function pointers, and correctly trace returns through both (e.g.,
gcc).
2. Ones which understand some NORETURN syntax for just functions, and
complain about it on function pointers. We currently turn off
NORETURN for these compilers (from your commit message, MSVC,
for example).
3. Ones which have no concept of NORETURN at all.
I think the right solution to turn on NORETURN for (2) is to split it
into two cases: NORETURN and NORETURN_PTR. Gcc platforms can define both
identically, platforms under (2) above can define NORETURN_PTR as empty,
and (3) will keep both off.
I do have to wonder, though. What do compilers that fall under (2) do
with calls to function pointers from NORETURN functions? Do they assume
they don't return, or that they do? Or do they not check that NORETURN
functions actually don't return?
I.e., what does this program do under MSVC:
#include <stdlib.h>
void (*exit_fun)(int) = exit;
static void die(void) __attribute__((__noreturn__));
static void die(void) { exit_fun(1); }
int main(void) { die(); }
In gcc, it rightly complains:
foo.c: In function ‘die’:
foo.c:4: warning: ‘noreturn’ function does return
-Peff
^ permalink raw reply
* [PATCH 2/2] remove NORETURN from function pointers
From: Erik Faye-Lund @ 2009-09-14 10:16 UTC (permalink / raw)
To: git; +Cc: Erik Faye-Lund, Erik Faye-Lund
In-Reply-To: <1252923370-5768-1-git-send-email-kusmabite@gmail.com>
From: Erik Faye-Lund <kusmabite@googlemail.com>
Some compilers (including at least MSVC and ARM RVDS) supports
NORETURN on function declarations, but not on function pointers.
This patch makes it possible to define NORETURN for these compilers.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
__attribute__((noreturn)) is, according to the GCC documentation, about
two things: code generation (performance, really) and warnings.
On the warnings-side, we need to keep the code warning-free for
compilers who doesn't support noreturn anyway, so hiding potential
warnings through this mechanism is probably not a good idea in the
first place.
We still want the performance-side of it, though. However, the only
place this really makes a difference is to die and it's variants, since
they can potentially be called many times (or so it seems from the
compiler's point of view without a noreturn declaration).
The function pointers are only called once we're already exiting, and
they have only one potential call-site.
I hope this all makes sense ;)
git-compat-util.h | 2 +-
usage.c | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/git-compat-util.h b/git-compat-util.h
index 5876d91..15fe08e 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -183,7 +183,7 @@ extern NORETURN void die_errno(const char *err, ...) __attribute__((format (prin
extern int error(const char *err, ...) __attribute__((format (printf, 1, 2)));
extern void warning(const char *err, ...) __attribute__((format (printf, 1, 2)));
-extern void set_die_routine(void (*routine)(const char *err, va_list params) NORETURN);
+extern void set_die_routine(void (*routine)(const char *err, va_list params));
extern int prefixcmp(const char *str, const char *prefix);
extern time_t tm_to_time_t(const struct tm *tm);
diff --git a/usage.c b/usage.c
index b6aea45..18d7f43 100644
--- a/usage.c
+++ b/usage.c
@@ -36,12 +36,12 @@ static void warn_builtin(const char *warn, va_list params)
/* If we are in a dlopen()ed .so write to a global variable would segfault
* (ugh), so keep things static. */
-static void (*usage_routine)(const char *err) NORETURN = usage_builtin;
-static void (*die_routine)(const char *err, va_list params) NORETURN = die_builtin;
+static void (*usage_routine)(const char *err) = usage_builtin;
+static void (*die_routine)(const char *err, va_list params) = die_builtin;
static void (*error_routine)(const char *err, va_list params) = error_builtin;
static void (*warn_routine)(const char *err, va_list params) = warn_builtin;
-void set_die_routine(void (*routine)(const char *err, va_list params) NORETURN)
+void set_die_routine(void (*routine)(const char *err, va_list params))
{
die_routine = routine;
}
--
1.6.4.msysgit.0.16.gd92d4.dirty
^ permalink raw reply related
* [PATCH] web--browse: fix Mac OS X GUI detection for 10.6
From: Heiko Voigt @ 2009-09-14 8:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Since OS X 10.6 the variable $SECURITYSESSIONID does not exist anymore,
so lets look for the $TERM_PROGRAM variable as backup.
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
---
git-web--browse.sh | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/git-web--browse.sh b/git-web--browse.sh
index 4f5c740..a578c3a 100755
--- a/git-web--browse.sh
+++ b/git-web--browse.sh
@@ -111,7 +111,8 @@ if test -z "$browser" ; then
browser_candidates="w3m links lynx"
fi
# SECURITYSESSIONID indicates an OS X GUI login session
- if test -n "$SECURITYSESSIONID"; then
+ if test -n "$SECURITYSESSIONID" \
+ -o "$TERM_PROGRAM" = "Apple_Terminal" ; then
browser_candidates="open $browser_candidates"
fi
# /bin/start indicates MinGW
--
1.6.5.rc1.dirty
^ permalink raw reply related
* [PATCH] remove logical typo in documentation of sample update hook
From: Heiko Voigt @ 2009-09-14 8:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
---
Documentation/githooks.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt
index 79f633e..06e0f31 100644
--- a/Documentation/githooks.txt
+++ b/Documentation/githooks.txt
@@ -245,7 +245,7 @@ Both standard output and standard error output are forwarded to
for the user.
The default 'update' hook, when enabled--and with
-`hooks.allowunannotated` config option turned on--prevents
+`hooks.allowunannotated` config option unset or set to false--prevents
unannotated tags to be pushed.
[[post-receive]]
--
1.6.5.rc1.dirty
^ permalink raw reply related
* Re: Error with git svn show-ignore: forbidden access
From: Yann Simon @ 2009-09-14 7:30 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20090905055708.GA22272@dcvr.yhbt.net>
Hi Eric,
2009/9/5 Eric Wong <normalperson@yhbt.net>:
> Yann Simon <yann.simon.fr@gmail.com> wrote:
>> with git version 1.6.4:
>>
>> $ git svn show-ignore > .gitignore
>> RA layer request failed: Server sent unexpected return value (403
>> Forbidden) in response to PROPFIND request for
>> '/repos/XXX/YYY/ZZZ/trunk/aaa' at /usr/lib/git-core/git-svn line 2243
>>
>> Is git svn show-ignore making request to the svn server?
>
> Yes, git svn has to read the svn:ignore property remotely since it
> doesn't do anything with it when it fetches. Do you have read
> permissions to /repos/XXX/YYY/ZZZ/trunk/aaa on that repo?
No I do not have permissions to /repos/XXX/YYY/ZZZ/trunk/aaa.
I did some more tests and found out that git svn fetch could care with
this and checkout every folders in trunk except aaa.
Git svn fetch and git svn ignore do not have similar behavior?
> For everything besides initialization/clone, git svn reads the url in
> your $GIT_CONFIG. --minimize-url is only used for the initial setup.
>
> You can edit it to move the URL down/up a level if you edit your
> corresponding fetch/branches/tags lines:
> [...]
I tried that and it works. Tanks a lot!
It was easy in my case because there are only 2 folders in trunk, one
I can access, and one I cannot.
But let's suppose there are x folders in 'trunk', and only one of them
cannot be accessed.
In that case, the configuration could be very complex, is not it?
But that latter configuration is probably unlikely to be used. If
someone wants to restrict access, he/she would use one folder for
every one, and one folder for restricted access.
---
Yann
^ permalink raw reply
* Re: rename tracking and file-name swapping
From: Johannes Sixt @ 2009-09-14 6:44 UTC (permalink / raw)
To: Yuri D'Elia; +Cc: Junio C Hamano, git, Bernardo Innocenti
In-Reply-To: <1248088D-85CB-4335-AD8A-07DB5BAD1AAA@users.sf.net>
Yuri D'Elia schrieb:
> On 13 Sep 2009, at 20:14, Junio C Hamano wrote:
>> By default, if the pathname that was present in the old version still
>> appears in the new version, that path is not considered as a candiate
>> for rename detection. Only "X used to be there but is gone" and "Y did
>> not exist but appeared" are paired up and checked if they are similar.
>>
>> Give the command -B option, too, to break the filepair that does not
>> disappear.
>
> That does the trick. I'm curious, is there any other use for -B besides
> rename handling?
Yes: It can make patches easier to read (just like -M and -C do) if a file
was completely rewritten. For example, look at b9dfe51c with and without
-B, and also note the "dissimilarity index" in the diff header.
-- Hannes
^ permalink raw reply
* [PATCH] Nicolas Pitre has a new email address
From: Nicolas Pitre @ 2009-09-14 6:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3156 bytes --]
Due to problems at cam.org, my nico@cam.org email address is no longer
valid. FRom now on, nico@fluxnic.net should be used instead.
Signed-off-by: Nicolas Pitre <nico@fluxnic.net>
---
I was sticking with nico@cam.org since I've been using that address
for... hmm... something like 17 years now. A major screw up was needed
for me to move away from it.
diff --git a/.mailmap b/.mailmap
index 373476b..975e675 100644
--- a/.mailmap
+++ b/.mailmap
@@ -41,6 +41,7 @@ Michele Ballabio <barra_cuda@katamail.com>
Nanako Shiraishi <nanako3@bluebottle.com>
Nanako Shiraishi <nanako3@lavabit.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
+<nico@fluxnic.net> <nico@cam.org>
Philippe Bruhat <book@cpan.org>
Ramsay Allan Jones <ramsay@ramsay1.demon.co.uk>
René Scharfe <rene.scharfe@lsrfire.ath.cx>
diff --git a/diff-delta.c b/diff-delta.c
index a4e28df..464ac3f 100644
--- a/diff-delta.c
+++ b/diff-delta.c
@@ -4,7 +4,7 @@
* This code was greatly inspired by parts of LibXDiff from Davide Libenzi
* http://www.xmailserver.org/xdiff-lib.html
*
- * Rewritten for GIT by Nicolas Pitre <nico@cam.org>, (C) 2005-2007
+ * Rewritten for GIT by Nicolas Pitre <nico@fluxnic.net>, (C) 2005-2007
*
* This code is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
diff --git a/git.spec.in b/git.spec.in
index 4be0834..ab224f7 100644
--- a/git.spec.in
+++ b/git.spec.in
@@ -233,7 +233,7 @@ rm -rf $RPM_BUILD_ROOT
* Tue Mar 27 2007 Eygene Ryabinkin <rea-git@codelabs.ru>
- Added the git-p4 package: Perforce import stuff.
-* Mon Feb 13 2007 Nicolas Pitre <nico@cam.org>
+* Mon Feb 13 2007 Nicolas Pitre <nico@fluxnic.net>
- Update core package description (Git isn't as stupid as it used to be)
* Mon Feb 12 2007 Junio C Hamano <junkio@cox.net>
diff --git a/patch-delta.c b/patch-delta.c
index ef748ce..e02e13b 100644
--- a/patch-delta.c
+++ b/patch-delta.c
@@ -2,7 +2,7 @@
* patch-delta.c:
* recreate a buffer from a source and the delta produced by diff-delta.c
*
- * (C) 2005 Nicolas Pitre <nico@cam.org>
+ * (C) 2005 Nicolas Pitre <nico@fluxnic.net>
*
* This code is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
diff --git a/progress.c b/progress.c
index 621c34e..132ed95 100644
--- a/progress.c
+++ b/progress.c
@@ -1,7 +1,7 @@
/*
* Simple text-based progress display module for GIT
*
- * Copyright (c) 2007 by Nicolas Pitre <nico@cam.org>
+ * Copyright (c) 2007 by Nicolas Pitre <nico@fluxnic.net>
*
* This code is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
diff --git a/test-delta.c b/test-delta.c
index 3d885ff..af40a3c 100644
--- a/test-delta.c
+++ b/test-delta.c
@@ -1,7 +1,7 @@
/*
* test-delta.c: test code to exercise diff-delta.c and patch-delta.c
*
- * (C) 2005 Nicolas Pitre <nico@cam.org>
+ * (C) 2005 Nicolas Pitre <nico@fluxnic.net>
*
* This code is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
^ permalink raw reply related
* Re: Tracking remote branches
From: Nicolas Sebrecht @ 2009-09-14 5:01 UTC (permalink / raw)
To: Thiago Farina; +Cc: git
In-Reply-To: <a4c8a6d00909131737v35d7c63dsea669f47456f5acb@mail.gmail.com>
The 13/09/09, Thiago Farina wrote:
> Hi,
>
> I know that I could do simply, instead of above:
> $ git checkout --track -b maint origin/maint
Or
$ git checkout -t origin/maint
> OK, now I switched to maint branch. And then I did:
> $ git status
>
> # On branch maint
> # Changes to be committed
> # (use "git reset HEAD <file>..." to unstage)
> #
> # new file: git-remote-curl
> # new file: git-replace
> #
>
> What happened here? What I have to do now?
You've probably added these files to the index, mistakenly. If you don't
have uncommited changes, try :
git checkout -f master
git branch -D maint
git checkout -t origin/maint
git status
The files should now be shown as "Untracked files".
--
Nicolas Sebrecht
^ permalink raw reply
* Re: [PATCH] git-gui: suggest gc only when counting at least 2 objects
From: Shawn O. Pearce @ 2009-09-14 3:39 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: Jeff King, Junio C Hamano, git, msysgit
In-Reply-To: <20090913211916.GA5029@localhost>
Clemens Buchacher <drizzd@aon.at> wrote:
> On Sun, Sep 13, 2009 at 04:44:33PM -0400, Jeff King wrote:
> > On Sun, Sep 13, 2009 at 08:41:50PM +0200, Clemens Buchacher wrote:
> > > On Sun, Sep 13, 2009 at 10:58:45AM -0700, Junio C Hamano wrote:
> > > > Somebody cares to explain why this threashold number has to be different
> > > > per platform in the first place?
> > >
> > > I really don't know. I vaguely remember someone claim that performance on
> > > Windows suffered from many loose objects more than on other platforms. I
> > > can't find any discussion of it though.
> >
> > Maybe 8ff487c?
Yes, it was 8ff487c. Back then I was using Windows on a daily
basis and this was put into git-gui because Aunt Tillie couldn't
remember do run a git-gc every so often, and performance would just
drop in the bucket. It also quite a bit predates `git gc --auto`
being sprinkled throughout the code base on various operations.
As to why its been 200 as the loose count estimate, that was just
a WAG based on what I observed on my desktop. 2000 on UNIX is
usually fine, 2000 on Windows meant you waited an extra 30 seconds
to perform an operation.
> Ok. But it's been 2 years since then and if I'm not mistaken, there have
> been a number of performance improvements to msysgit. So maybe it's time to
> revisit that threshold.
msysgit may have improved, but at the time I was running Git on
Cygwin, and I doubt NTFS has really improved that much.
> If, on the other hand, requiring 2 objects really is too many, we should
> maybe check at least two or four directories, which would greatly improve
> the statistic.
I'm concerned about the FS cost of checking more directories, but
this is a one-time penalty on startup of git-gui so it might not
be too bad if it gets us a better estimate.
--
Shawn.
^ permalink raw reply
* Re: Patches for git-push --confirm and --show-subjects
From: Owen Taylor @ 2009-09-14 2:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpr9ugxn5.fsf@alter.siamese.dyndns.org>
On Sun, 2009-09-13 at 17:47 -0700, Junio C Hamano wrote:
> Without reading much of the code, my knee jerk reactions are:
>
> * This probably can (and from the longer term perspective, should) be
> done inside a pre-push hook that can decline pushing;
Certainly, within the logic of the operation, there's a potential hook.
(Much like pre-receive but on the client side.)
But even if this behavior was in pre-push.sample, it would not meet what
I'm looking for. Which is an easy-to-use behavior you can turn on, no
matter how many different repositories you work in.
Would it work to do it as a helper program? - if "advanced" options are
found it feeds the list of candidate ref updates through
git-push--helper or something?
> * I do not think it should use two separate push_refs call into transport
> (first with dry-run and second with real).
>
> Immediately after match_refs() call in transport_push(), you know if
> the push is a non-fast-forward (in which case you do not know what you
> will be losing anyway because you haven't seen what you are missing
> from the other end) or exactly what your fast-forward push will be
> sending, so between that call and the actual transport->push_refs()
> would be the ideal place to call the hook, with a list of "ref old
> new", without running a dry-run.
The reason I had to do two calls to transport->push_refs is not because
it actually pushes the refs twice. It's because the logic for
classifying the refs is in builtin-send-pack.c. When you pass in
args.dry_run=1 you get the classification logic without the network
traffic.
(There's a little messiness about whether it sends the "flush" 0000 or
not that I had to work around, but that's peripheral.)
The way to clean it up is pretty obvious:
- You add another vfunc to the transport - '->get_capabilities' or
something - that encapsulates server_supports("delete-refs").
- You split the classification logic out into a helper function
(maybe still in builtin-send-pack.c, maybe moved into some other
file... don't know what's appropriate.)
After all, if there was another push_refs backend, it shouldn't be
duplicating the classification logic...
- You pass pre-classified ref updates to ->push_refs
I don't know how that interacts with other planned changes to this code.
> for a few reasons.
>
> (1) When push.confirm is set, you do not want to interact with the user
> when the standard input is not a terminal. But an automated script
> that runs git-push can still use an appropriate pre-push hook to make
> the decision to intervene without human presense.
>
> (2) As your --show-subjects patch shows, the likes and dislikes of the
> output format for confirmation would be highly personal. A separate
> hook that is fed list of <ref, old, new> would make it easier to
> customize this to suite people's tastes.
The --show-subjects idea is equally useful for --dry-run. And even when
for successful/failed pushes when neither --confirm not --dry-run is
passed.
I'm not that convinced that there's that much scope for configurability
in this area. Clearly there's some arbitrary decisions I made - that
abbreviated hashes wouldn't be useful. That up to 8 commit subjects
should be shown. Etc.
But as yet, there's no data as to whether people would actually want to
make *different* arbitrary decisions.
Adding more configurability (formats, etc.) doesn't really bother me,
though it does seem like coding in advance of need. But what would
bother me is if the feature isn't useful without complex configuration
or installing custom scripts.
> (3) I do not trust the use of the fmt_merge_message() code in this
> codepath. That code, like all the major parts of git, relies on
> being able to use the object flag bits for its own purpose, and there
> is a chance that the way transports (present and future) optimizes
> (or may want to optimize in the future) the object transfer by
> implementing clever common ancestry discovery, similar to what is
> done for the fetch-pack side.
>
> If we force the actual confirmation process out to a separate process
> that runs a hook, I do not have to worry about that, which is a huge
> relief for maintainability of the system.
Well, I guess that's one way to look at the maintainability issues
involved...
I have to take your word as gospel on this ... I don't have a
comprehensive or even a non-comprehensive view of the use of flags.
Certainly almost same code could be put into a git-push--helper binary.
> (4) The same objects flag bits contamination issue makes me worried about
> your approach of running one transport_push() with dry-run and then
> another without.
With only one example of a transport that implements 'push_refs', it's a
little hard to say what a transport *might* do. But as described above,
this is just a code-structure issue.
- Owen
^ permalink raw reply
* Re: Patches for git-push --confirm and --show-subjects
From: Junio C Hamano @ 2009-09-14 0:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Owen Taylor, git
In-Reply-To: <7vpr9ugxn5.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Without reading much of the code, my knee jerk reactions are:
>
> * This probably can (and from the longer term perspective, should) be
> done inside a pre-push hook that can decline pushing;
>
> * I do not think it should use two separate push_refs call into transport
> (first with dry-run and second with real).
>
> Immediately after match_refs() call in transport_push(), you know if
> the push is a non-fast-forward (in which case you do not know what you
> will be losing anyway because you haven't seen what you are missing
> from the other end) or exactly what your fast-forward push will be
> sending, so between that call and the actual transport->push_refs()
> would be the ideal place to call the hook, with a list of "ref old
> new", without running a dry-run.
>
> for a few reasons.
>
> (1) When push.confirm is set, you do not want to interact with the user
> when the standard input is not a terminal. But an automated script
> that runs git-push can still use an appropriate pre-push hook to make
> the decision to intervene without human presense.
>
> (2) As your --show-subjects patch shows, the likes and dislikes of the
> output format for confirmation would be highly personal. A separate
> hook that is fed list of <ref, old, new> would make it easier to
> customize this to suite people's tastes.
>
> (3) I do not trust the use of the fmt_merge_message() code in this
> codepath. That code, like all the major parts of git, relies on
> being able to use the object flag bits for its own purpose, and there
> is a chance that the way transports (present and future) optimizes
> (or may want to optimize in the future) the object transfer by
> implementing clever common ancestry discovery, similar to what is
> done for the fetch-pack side.
Please add ", would be interfered with fmt_merge_message() code
contaminating the object flag bits." at the end of this sentence.
>
> If we force the actual confirmation process out to a separate process
> that runs a hook, I do not have to worry about that, which is a huge
> relief for maintainability of the system.
>
> (4) The same objects flag bits contamination issue makes me worried about
> your approach of running one transport_push() with dry-run and then
> another without.
^ permalink raw reply
* Re: Patches for git-push --confirm and --show-subjects
From: Junio C Hamano @ 2009-09-14 0:47 UTC (permalink / raw)
To: Owen Taylor; +Cc: git
In-Reply-To: <1252884685-9169-1-git-send-email-otaylor@redhat.com>
Without reading much of the code, my knee jerk reactions are:
* This probably can (and from the longer term perspective, should) be
done inside a pre-push hook that can decline pushing;
* I do not think it should use two separate push_refs call into transport
(first with dry-run and second with real).
Immediately after match_refs() call in transport_push(), you know if
the push is a non-fast-forward (in which case you do not know what you
will be losing anyway because you haven't seen what you are missing
from the other end) or exactly what your fast-forward push will be
sending, so between that call and the actual transport->push_refs()
would be the ideal place to call the hook, with a list of "ref old
new", without running a dry-run.
for a few reasons.
(1) When push.confirm is set, you do not want to interact with the user
when the standard input is not a terminal. But an automated script
that runs git-push can still use an appropriate pre-push hook to make
the decision to intervene without human presense.
(2) As your --show-subjects patch shows, the likes and dislikes of the
output format for confirmation would be highly personal. A separate
hook that is fed list of <ref, old, new> would make it easier to
customize this to suite people's tastes.
(3) I do not trust the use of the fmt_merge_message() code in this
codepath. That code, like all the major parts of git, relies on
being able to use the object flag bits for its own purpose, and there
is a chance that the way transports (present and future) optimizes
(or may want to optimize in the future) the object transfer by
implementing clever common ancestry discovery, similar to what is
done for the fetch-pack side.
If we force the actual confirmation process out to a separate process
that runs a hook, I do not have to worry about that, which is a huge
relief for maintainability of the system.
(4) The same objects flag bits contamination issue makes me worried about
your approach of running one transport_push() with dry-run and then
another without.
^ permalink raw reply
* Tracking remote branches
From: Thiago Farina @ 2009-09-14 0:37 UTC (permalink / raw)
To: git
Hi,
I'm not understanding what is happening here. I tried to track a
remote branch, origin/maint from git. So I did:
$ git branch --track maint origin/maint
$ git checkout maint
I know that I could do simply, instead of above:
$ git checkout --track -b maint origin/maint
OK, now I switched to maint branch. And then I did:
$ git status
# On branch maint
# Changes to be committed
# (use "git reset HEAD <file>..." to unstage)
#
# new file: git-remote-curl
# new file: git-replace
#
What happened here? What I have to do now?
^ permalink raw reply
* could not detach HEAD error didn't identify the cause of the issue
From: Ben Bradshaw @ 2009-09-14 0:14 UTC (permalink / raw)
To: git
Hi,
I was asked to post this issue to the list, I've just had git tell me it
can't detach HEAD which left me scratching mine as to the cause and fix.
Turns out if I have local untracked files that the remote branch also
has then this error will trigger. I have included my shell backlog
(client data removed). In this example the site_map folder was present
on master and I had a local, untracked copy.
git can obviosly detect this issue and stop my local copy getting in a
bad state, but an error message such as "sites/all/modules/site_map/ is
present in HEAD but is untracked locally, unable to apply changes" (or
something to point the finger) would be much appreciated.
ben@carbon:redacted/$ git pull --rebase
remote: Counting objects: 91, done.
remote: Compressing objects: 100% (72/72), done.
remote: Total 74 (delta 27), reused 0 (delta 0)
Unpacking objects: 100% (74/74), done.
From git+ssh://redacted
fb1a4c9..bf06bbd master -> origin/master
First, rewinding head to replay your work on top of it...
Fast-forwarded master to bf06bbd9e50a2732164fba9e60e65606ab1267ab.
ben@carbon:redacted/$ pwd
/home/ben/redacted
ben@carbon:redacted/$ git pull --rebase
First, rewinding head to replay your work on top of it...
could not detach HEAD
ben@carbon:redacted/$ git status
# On branch master
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# sites/all/modules/jquery.ui-1.6.zip
# sites/all/modules/jquery_ui-6.x-1.3.tar.gz
# sites/all/modules/jquery_ui/
# sites/all/modules/modalframe-6.x-1.3.tar.gz
# sites/all/modules/modalframe/
# sites/all/modules/nodereference_explorer-6.x-1.1-beta6.tar.gz
# sites/all/modules/nodereference_explorer/
# sites/all/modules/noderelationships-6.x-1.1.tar.gz
# sites/all/modules/noderelationships/
# sites/all/modules/site_map-6.x-1.1.tar.gz
# sites/all/modules/site_map/
nothing added to commit but untracked files present (use "git add" to track)
ben@carbon:redacted/$ rm -rf sites/all/modules/site_map/
ben@carbon:redacted/$ git status
# On branch master
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# sites/all/modules/jquery.ui-1.6.zip
# sites/all/modules/jquery_ui-6.x-1.3.tar.gz
# sites/all/modules/jquery_ui/
# sites/all/modules/modalframe-6.x-1.3.tar.gz
# sites/all/modules/modalframe/
# sites/all/modules/nodereference_explorer-6.x-1.1-beta6.tar.gz
# sites/all/modules/nodereference_explorer/
# sites/all/modules/noderelationships-6.x-1.1.tar.gz
# sites/all/modules/noderelationships/
# sites/all/modules/site_map-6.x-1.1.tar.gz
nothing added to commit but untracked files present (use "git add" to track)
ben@carbon:redacted/$ git pull --rebase
First, rewinding head to replay your work on top of it...
Fast-forwarded master to 527afccc7565929baf7890b42b1a34174014fee7.
Thanks for your time (and git)
Ben
^ permalink raw reply
* [PATCH 4/4] push: allow configuring default for --show-subjects
From: Owen Taylor @ 2009-09-13 23:31 UTC (permalink / raw)
To: git; +Cc: Owen W. Taylor
In-Reply-To: <1252884685-9169-4-git-send-email-otaylor@redhat.com>
From: Owen W. Taylor <otaylor@fishsoup.net>
A new configuration variable push.show-subjects sets the default
behavior for whether 'git push' should show a commit synopsis with
each updated ref.
Signed-off-by: Owen W. Taylor <otaylor@fishsoup.net>
---
Documentation/config.txt | 4 ++++
builtin-push.c | 2 ++
cache.h | 1 +
config.c | 4 ++++
environment.c | 1 +
5 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 3bb632f..83bc5a5 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1320,6 +1320,10 @@ push.default::
* `tracking` push the current branch to its upstream branch.
* `current` push the current branch to a branch of the same name.
+push.show-subjects::
+ If set to true, linkgit:git-push[1] will act as if the --show-subjects
+ option was passed, unless overriden with --no-show-subjects.
+
rebase.stat::
Whether to show a diffstat of what changed upstream since the last
rebase. False by default.
diff --git a/builtin-push.c b/builtin-push.c
index 7c9e394..e3dc579 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -197,6 +197,8 @@ int cmd_push(int argc, const char **argv, const char *prefix)
if (push_confirm)
flags |= TRANSPORT_PUSH_CONFIRM;
+ if (push_show_subjects)
+ flags |= TRANSPORT_PUSH_SHOW_SUBJECTS;
argc = parse_options(argc, argv, prefix, options, push_usage, 0);
diff --git a/cache.h b/cache.h
index ef8606d..9e6a1e6 100644
--- a/cache.h
+++ b/cache.h
@@ -559,6 +559,7 @@ extern enum branch_track git_branch_track;
extern enum rebase_setup_type autorebase;
extern enum push_default_type push_default;
extern int push_confirm;
+extern int push_show_subjects;
enum object_creation_mode {
OBJECT_CREATION_USES_HARDLINKS = 0,
diff --git a/config.c b/config.c
index 1bc8e6f..bc78876 100644
--- a/config.c
+++ b/config.c
@@ -597,6 +597,10 @@ static int git_default_push_config(const char *var, const char *value)
}
return 0;
}
+ if (!strcmp(var, "push.show-subjects")) {
+ push_show_subjects = git_config_bool(var, value);
+ return 0;
+ }
/* Add other config variables here and to Documentation/config.txt. */
return 0;
diff --git a/environment.c b/environment.c
index e1c82b9..303c54f 100644
--- a/environment.c
+++ b/environment.c
@@ -46,6 +46,7 @@ enum branch_track git_branch_track = BRANCH_TRACK_REMOTE;
enum rebase_setup_type autorebase = AUTOREBASE_NEVER;
int push_confirm;
enum push_default_type push_default = PUSH_DEFAULT_MATCHING;
+int push_show_subjects;
#ifndef OBJECT_CREATION_MODE
#define OBJECT_CREATION_MODE OBJECT_CREATION_USES_HARDLINKS
#endif
--
1.6.2.5
^ 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