* Re: file names
From: Junio C Hamano @ 2010-12-09 17:51 UTC (permalink / raw)
To: Thiago Farina; +Cc: Git Mailing List
In-Reply-To: <AANLkTikeAFj68Rr35gcf4dxXXHU+au9wA7wd+-WB3BSS@mail.gmail.com>
Thiago Farina <tfransosi@gmail.com> writes:
> So it seems from this data, there is a preference for naming files
> using dash over underline.
Yes.
> So the question is, should the files using underline be converted to
> use dash instead?
If this were before v1.0.0, it might have made some sense, but not at this
moment. So the answer to "should?" (or "could?") is a firm "no", which is
always different from the answer to "wouldn't it have been nicer if they
were named differently?"
Or just after a large version bump (say 1.8.0), perhaps.
^ permalink raw reply
* Re: [PATCH] Corrected return values in prep_for_email;
From: Junio C Hamano @ 2010-12-09 17:38 UTC (permalink / raw)
To: Alan Raison; +Cc: 'Kevin P. Fleming', git
In-Reply-To: <004301cb97ba$90772630$b1657290$@me.uk>
"Alan Raison" <alan@theraisons.me.uk> writes:
> Function was returning 0 for failure and 1 for success which was breaking
> the logic in the main loop.
>
> Corrected to return 0 for success, 1 for failure. Function now also returns
> in all cases, rather than exiting.
Thanks, will apply.
> Acked-By: Kevin P. Fleming <kpfleming@digium.com>
> Signed-Off-By: Alan Raison <alan@theraisons.me.uk>
Just for reference---the order of events is that you signed-off first and
then Kevin acked the result, so the above is backwards.
Also your patch was linewrapped, but I can fix it up---no need to resend,
but please tell your MUA not to corrupt patches next time.
^ permalink raw reply
* Re: What's cooking in git.git (Dec 2010, #01; Sat, 4)
From: Jeff King @ 2010-12-09 17:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Aleksi Aalto, git
In-Reply-To: <7v8w04vvvr.fsf@alter.siamese.dyndns.org>
On Sun, Dec 05, 2010 at 11:54:00AM -0800, Junio C Hamano wrote:
> >> * aa/status-hilite-branch (2010-11-18) 1 commit
> >> - status: show branchname with a configurable color
> [...]
> > I am not particularly interested, either, but FWIW, the gitcommit syntax
> > highlighting that ships with vim does highlight this, so there are at
> > least other people who think this is a good idea.
>
> As you already know, when I say "'Meh' personally", I am not saying "I
> want to forbid others to want it".
>
> How does vim highlight the other parts of that particular line? Does it
> keep them intact, or paint them in some other color?
It colors everything marked with a "#" as blue (which is also how I have
my color.status.header configured).
> > However, I'm not sure about the default. The original patch defaulted to
> > magenta. Your fixup defaults to "plain", but that is a regression
> > (albeit a minor one) for people who have status.header set.
>
> This patch is a regression for them either way, isn't it? Except for
> those who chose to use magenta to paint status.header, that is.
Yes, I should have been more clear. _Both_ cases can be a regression,
depending on the user's config; the only way to avoid a regression is to
default to "same as color.status.header".
> I had this suspicion that the class of people who choose a non default
> status.header color and the class of people who choose plain there (or
> have been happy with the default) expect different things. The former
> prefer louder output, different pieces of information painted in different
> colors to help them chromatically distinguish them. The latter (including
> myself) favor subdued output, without too many colors distacting them
> while reading the output.
>
> This suspicion further led me to think that the former would want this new
> feature to paint the branch name in a color different from status.header
> color, while the latter would want it in plain. So the default of "plain"
> would be a win for both audiences.
I see your reasoning, but as someone in the "former" group of your
description, I consider the default of "plain" worse than not
highlighting it at all. Mostly because the _rest_ of my terminal output
tends to be plain, so rather than appearing highlighted, the branch name
appears to be connected to that output. It's hard to describe in words
how ugly it is, but try:
mkdir foo && cd foo && git init
git config color.status.header blue
git status
Maybe we should put this on top?
-- >8 --
Subject: [PATCH] default color.status.branch to "same as header"
This gives it the same behavior as we had prior to 1d28232
(status: show branchname with a configurable color).
To do this we need the concept of a "NIL" color, which is
provided by color.[ch]. The implementation is very simple;
in particular, there are no precautions taken against code
accidentally printing the NIL. This should be fine in
practice because:
1. You can't input a NIL color in the config, so it must
come from the in-code defaults. Which means it is up
the client code to handle the NILs it defines.
2. If we do ever print a NIL, it will be obvious what the
problem is, and the bug can be fixed.
Signed-off-by: Jeff King <peff@peff.net>
---
I resisted the urge to make a generic "same as $X" token, which would
allow users to do something like:
[color "status"]
branch = from:color.status.header
if they really wanted. But that would be a lot more code, and I'm not
sure it would be all that useful (it would be if people did stuff like
theming git colors like they do window managers, but I don't think we
are at quite that level).
This is simple, solves the current regression, and provides an easy
blueprint for handling the case in the future.
color.c | 5 +++++
color.h | 5 +++++
wt-status.c | 7 +++++--
3 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/color.c b/color.c
index 1b00554..6a5a54e 100644
--- a/color.c
+++ b/color.c
@@ -211,3 +211,8 @@ int color_fprintf_ln(FILE *fp, const char *color, const char *fmt, ...)
va_end(args);
return r;
}
+
+int color_is_nil(const char *c)
+{
+ return !strcmp(c, "NIL");
+}
diff --git a/color.h b/color.h
index 03ca064..170ff40 100644
--- a/color.h
+++ b/color.h
@@ -43,6 +43,9 @@
#define GIT_COLOR_BG_MAGENTA "\033[45m"
#define GIT_COLOR_BG_CYAN "\033[46m"
+/* A special value meaning "no color selected" */
+#define GIT_COLOR_NIL "NIL"
+
/*
* This variable stores the value of color.ui
*/
@@ -62,4 +65,6 @@ int color_fprintf(FILE *fp, const char *color, const char *fmt, ...);
__attribute__((format (printf, 3, 4)))
int color_fprintf_ln(FILE *fp, const char *color, const char *fmt, ...);
+int color_is_nil(const char *color);
+
#endif /* COLOR_H */
diff --git a/wt-status.c b/wt-status.c
index e62388c..123582b 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -21,12 +21,15 @@ static char default_wt_status_colors[][COLOR_MAXLEN] = {
GIT_COLOR_RED, /* WT_STATUS_UNMERGED */
GIT_COLOR_GREEN, /* WT_STATUS_LOCAL_BRANCH */
GIT_COLOR_RED, /* WT_STATUS_REMOTE_BRANCH */
- GIT_COLOR_NORMAL, /* WT_STATUS_ONBRANCH */
+ GIT_COLOR_NIL, /* WT_STATUS_ONBRANCH */
};
static const char *color(int slot, struct wt_status *s)
{
- return s->use_color > 0 ? s->color_palette[slot] : "";
+ const char *c = s->use_color > 0 ? s->color_palette[slot] : "";
+ if (slot == WT_STATUS_ONBRANCH && color_is_nil(c))
+ c = s->color_palette[WT_STATUS_HEADER];
+ return c;
}
void wt_status_prepare(struct wt_status *s)
--
1.7.3.3.713.gb2a8.dirty
^ permalink raw reply related
* file names
From: Thiago Farina @ 2010-12-09 17:05 UTC (permalink / raw)
To: Git Mailing List
Hi, I was was looking into the file names and noticed that they are
not consistent.
Some files are named like:
foo-bar.[c/h]
Others are:
foo_bar.[c/h]
On top of the git directory:
# With dash
$ lc *.c | grep - | wc -l
72
$ lc *.h | grep - | wc -l
25
# With underline
$ ls *.c | grep _ | wc -l
5
$ ls *.h | grep _ | wc -l
1
So it seems from this data, there is a preference for naming files
using dash over underline.
So the question is, should the files using underline be converted to
use dash instead? And should this be documented somewhere? Maybe in
CodingGuidelines?
Thanks in advance.
^ permalink raw reply
* Re: [PATCH 2/3] config: add git_config_from_sha1() to read from a blob
From: Jonathan Nieder @ 2010-12-09 17:02 UTC (permalink / raw)
To: Thiago Farina; +Cc: Nguyễn Thái Ngọc Duy, git
In-Reply-To: <AANLkTi=qt-uwXdUquRAv_1VpMUQuUR+aNMuxSHdpMhXd@mail.gmail.com>
Thiago Farina wrote:
> 2010/12/9 Nguyễn Thái Ngọc Duy <pclouds@gmail.com>:
>> +static int git_config_from_sha1(config_fn_t fn, const char *sha1_name, void *data)
>> +{
>
> Is worth documenting the return value of this function and what it
> does? It returns 0 on success otherwise returns -1.
If that is the return value, then no. It is the usual in git (and
other C programs that follow libc conventions).
^ permalink raw reply
* Re: [PATCH] git-send-email: Accept -n as a synonym for --dry-run
From: "Alejandro R. Sedeño" @ 2010-12-09 16:21 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <201012091435.02669.trast@student.ethz.ch>
On 12/09/2010 08:35 AM, Thomas Rast wrote:
> Alejandro R. Sedeño wrote:
>> diff --git a/git-send-email.perl b/git-send-email.perl
>> index 76565de..7e3df9a 100755
>> --- a/git-send-email.perl
>> +++ b/git-send-email.perl
>> @@ -85,7 +85,7 @@ git send-email [options] <file | directory | rev-list options >
>> --confirm <str> * Confirm recipients before sending;
>> auto, cc, compose, always, or never.
>> --quiet * Output one line of info per email.
>> - --dry-run * Don't actually send the emails.
>> + -n, --dry-run * Don't actually send the emails.
>> --[no-]validate * Perform patch sanity checks. Default on.
>> --[no-]format-patch * understand any non optional arguments as
>> `git format-patch` ones.
>
> Good change by itself, but this is the first short option for
> git-send-email. Maybe --force should also get its analogous -f alias?
> Any others?
Sounds good to me, though I notice that --force isn't in git-send-email's
documentation at all.
If we're expanding this patch[set] to include other short options, -q for
--quiet makes sense to me as well.
Other suggestions?
-Alejandro
^ permalink raw reply
* [PATCH] Corrected return values in prep_for_email;
From: Alan Raison @ 2010-12-09 16:03 UTC (permalink / raw)
To: 'Kevin P. Fleming', 'Junio C Hamano'; +Cc: git
In-Reply-To: <4CFE8E97.4020508@digium.com>
Function was returning 0 for failure and 1 for success which was breaking
the logic in the main loop.
Corrected to return 0 for success, 1 for failure. Function now also returns
in all cases, rather than exiting.
Acked-By: Kevin P. Fleming <kpfleming@digium.com>
Signed-Off-By: Alan Raison <alan@theraisons.me.uk>
---
contrib/hooks/post-receive-email | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/contrib/hooks/post-receive-email
b/contrib/hooks/post-receive-email
index 85724bf..f99ea95 100755
--- a/contrib/hooks/post-receive-email
+++ b/contrib/hooks/post-receive-email
@@ -144,13 +144,13 @@ prep_for_email()
short_refname=${refname##refs/remotes/}
echo >&2 "*** Push-update of tracking branch,
$refname"
echo >&2 "*** - no email generated."
- exit 0
+ return 1
;;
*)
# Anything else (is there anything else?)
echo >&2 "*** Unknown type of update to $refname
($rev_type)"
echo >&2 "*** - no email generated"
- return 0
+ return 1
;;
esac
@@ -166,10 +166,10 @@ prep_for_email()
esac
echo >&2 "*** $config_name is not set so no email will be
sent"
echo >&2 "*** for $refname update $oldrev->$newrev"
- return 0
+ return 1
fi
- return 1
+ return 0
}
#
--
1.7.3.1.msysgit.0
^ permalink raw reply related
* Re: [PATCH 3/3] config: add core.sharedconfig
From: Thiago Farina @ 2010-12-09 16:00 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1291907388-9068-4-git-send-email-pclouds@gmail.com>
2010/12/9 Nguyễn Thái Ngọc Duy <pclouds@gmail.com>:
> core.sharedconfig can take anything that resolves to a blob.
> $GIT_DIR/config will override the shared config. Nested shared
> config is not allowed.
>
> No protection is provided. It's up to the project to maintain good
> config. The config could be in a separate branch that only a few
> people are allowed to push, for example. To be safest, just put SHA-1
> there.
>
> git-fsck and git-prune should learn about this key and protect it from
> being pruned.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
> Hopefully nobody sets core.sharedconfig = :path/to/config or similar
>
> And I should not open $GIT_DIR/config twice. Well, it does not hurt
> much.
>
> cache.h | 1 +
> config.c | 14 ++++++++++++++
> environment.c | 1 +
> 3 files changed, 16 insertions(+), 0 deletions(-)
>
> diff --git a/cache.h b/cache.h
> index e83bc2d..e91ce35 100644
> --- a/cache.h
> +++ b/cache.h
> @@ -559,6 +559,7 @@ extern int read_replace_refs;
> extern int fsync_object_files;
> extern int core_preload_index;
> extern int core_apply_sparse_checkout;
> +extern const char *core_shared_config;
>
Why you need to export this string? Isn't it used only in config.c?
^ permalink raw reply
* Re: [PATCH 2/3] config: add git_config_from_sha1() to read from a blob
From: Thiago Farina @ 2010-12-09 15:58 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1291907388-9068-3-git-send-email-pclouds@gmail.com>
2010/12/9 Nguyễn Thái Ngọc Duy <pclouds@gmail.com>:
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
> config.c | 34 ++++++++++++++++++++++++++++++++++
> 1 files changed, 34 insertions(+), 0 deletions(-)
>
> diff --git a/config.c b/config.c
> index c8bf46f..e7a9ff4 100644
> --- a/config.c
> +++ b/config.c
> @@ -809,6 +809,40 @@ int git_config_from_file(config_fn_t fn, const char *filename, void *data)
> return ret;
> }
>
> +static int git_config_from_sha1(config_fn_t fn, const char *sha1_name, void *data)
> +{
Is worth documenting the return value of this function and what it
does? It returns 0 on success otherwise returns -1.
> + unsigned char sha1[20];
> + enum object_type type;
> + unsigned long size;
> + int ret;
> +
> + if (get_sha1(sha1_name, sha1)) {
> + error("bad shared config reference '%s'", sha1_name);
> + return -1;
> + }
> +
> + config_file = read_sha1_file(sha1, &type, &size);
> + if (!config_file) {
> + error("bad shared config '%s'", sha1_name);
> + return -1;
> + }
> + if (type == OBJ_BLOB) {
> + config_file_pos = 0;
> + config_file_size = size;
> + config_file_name = sha1_name;
> + config_linenr = 1;
> + config_file_eof = 0;
> + ret = git_parse_file(fn, data);
> + }
> + else {
style nit: Shouldn't this else be on the end of the previous line?
^ permalink raw reply
* Re: [PATCH] Corrected return values in prep_for_email;
From: Kevin P. Fleming @ 2010-12-09 15:19 UTC (permalink / raw)
To: Alan Raison; +Cc: 'Junio C Hamano', git
In-Reply-To: <004201cb97a4$6127cc60$23776520$@me.uk>
On 12/09/2010 07:24 AM, Alan Raison wrote:
> From ebe98d1c682f268b39a7eaf3ef529accbf0ac61c Mon Sep 17 00:00:00 2001
> From: Alan Raison<alan@theraisons.me.uk>
> Date: Mon, 6 Dec 2010 15:49:21 +0000
> Subject: [PATCH] Corrected return values in prep_for_email;
>
> Function was returning 0 for failure and 1 for success which was breaking
> the logic in the main loop.
>
> Corrected to return 0 for success, 1 for failure. Function now also returns
> in all cases, rather than exiting.
Your commit message will need a Signed-Off-By line, but...
Acked-By: Kevin P. Fleming <kpfleming@digium.com>
> ---
> contrib/hooks/post-receive-email | 8 ++++----
> 1 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/contrib/hooks/post-receive-email
> b/contrib/hooks/post-receive-email
> index 85724bf..f99ea95 100755
> --- a/contrib/hooks/post-receive-email
> +++ b/contrib/hooks/post-receive-email
> @@ -144,13 +144,13 @@ prep_for_email()
> short_refname=${refname##refs/remotes/}
> echo>&2 "*** Push-update of tracking branch,
> $refname"
> echo>&2 "*** - no email generated."
> - exit 0
> + return 1
> ;;
> *)
> # Anything else (is there anything else?)
> echo>&2 "*** Unknown type of update to $refname
> ($rev_type)"
> echo>&2 "*** - no email generated"
> - return 0
> + return 1
> ;;
> esac
>
> @@ -166,10 +166,10 @@ prep_for_email()
> esac
> echo>&2 "*** $config_name is not set so no email will be
> sent"
> echo>&2 "*** for $refname update $oldrev->$newrev"
> - return 0
> + return 1
> fi
>
> - return 1
> + return 0
> }
>
> #
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kfleming@digium.com
Check us out at www.digium.com & www.asterisk.org
^ permalink raw reply
* [PATCH 3/3] config: add core.sharedconfig
From: Nguyễn Thái Ngọc Duy @ 2010-12-09 15:09 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy
In-Reply-To: <1291907388-9068-1-git-send-email-pclouds@gmail.com>
core.sharedconfig can take anything that resolves to a blob.
$GIT_DIR/config will override the shared config. Nested shared
config is not allowed.
No protection is provided. It's up to the project to maintain good
config. The config could be in a separate branch that only a few
people are allowed to push, for example. To be safest, just put SHA-1
there.
git-fsck and git-prune should learn about this key and protect it from
being pruned.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
Hopefully nobody sets core.sharedconfig = :path/to/config or similar
And I should not open $GIT_DIR/config twice. Well, it does not hurt
much.
cache.h | 1 +
config.c | 14 ++++++++++++++
environment.c | 1 +
3 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/cache.h b/cache.h
index e83bc2d..e91ce35 100644
--- a/cache.h
+++ b/cache.h
@@ -559,6 +559,7 @@ extern int read_replace_refs;
extern int fsync_object_files;
extern int core_preload_index;
extern int core_apply_sparse_checkout;
+extern const char *core_shared_config;
enum safe_crlf {
SAFE_CRLF_FALSE = 0,
diff --git a/config.c b/config.c
index e7a9ff4..735b3f4 100644
--- a/config.c
+++ b/config.c
@@ -883,6 +883,14 @@ int git_config_from_parameters(config_fn_t fn, void *data)
return 0;
}
+static int get_shared_config(const char *var, const char *value, void *dummy)
+{
+ if (!strcmp(var, "core.sharedconfig"))
+ return git_config_string(&core_shared_config, var, value);
+
+ return 0;
+}
+
int git_config(config_fn_t fn, void *data)
{
int ret = 0, found = 0;
@@ -910,6 +918,12 @@ int git_config(config_fn_t fn, void *data)
repo_config = git_pathdup("config");
if (!access(repo_config, R_OK)) {
+ git_config_from_file(get_shared_config, repo_config, NULL);
+ if (core_shared_config) {
+ ret += git_config_from_sha1(fn, core_shared_config, data);
+ found += 1;
+ }
+
ret += git_config_from_file(fn, repo_config, data);
found += 1;
}
diff --git a/environment.c b/environment.c
index 913b058..8bfb548 100644
--- a/environment.c
+++ b/environment.c
@@ -55,6 +55,7 @@ enum object_creation_mode object_creation_mode = OBJECT_CREATION_MODE;
char *notes_ref_name;
int grafts_replace_parents = 1;
int core_apply_sparse_checkout;
+const char *core_shared_config;
struct startup_info *startup_info;
/* Parallel index stat data preload? */
--
1.7.3.3.476.g893a9
^ permalink raw reply related
* [PATCH 2/3] config: add git_config_from_sha1() to read from a blob
From: Nguyễn Thái Ngọc Duy @ 2010-12-09 15:09 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy
In-Reply-To: <1291907388-9068-1-git-send-email-pclouds@gmail.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
config.c | 34 ++++++++++++++++++++++++++++++++++
1 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/config.c b/config.c
index c8bf46f..e7a9ff4 100644
--- a/config.c
+++ b/config.c
@@ -809,6 +809,40 @@ int git_config_from_file(config_fn_t fn, const char *filename, void *data)
return ret;
}
+static int git_config_from_sha1(config_fn_t fn, const char *sha1_name, void *data)
+{
+ unsigned char sha1[20];
+ enum object_type type;
+ unsigned long size;
+ int ret;
+
+ if (get_sha1(sha1_name, sha1)) {
+ error("bad shared config reference '%s'", sha1_name);
+ return -1;
+ }
+
+ config_file = read_sha1_file(sha1, &type, &size);
+ if (!config_file) {
+ error("bad shared config '%s'", sha1_name);
+ return -1;
+ }
+ if (type == OBJ_BLOB) {
+ config_file_pos = 0;
+ config_file_size = size;
+ config_file_name = sha1_name;
+ config_linenr = 1;
+ config_file_eof = 0;
+ ret = git_parse_file(fn, data);
+ }
+ else {
+ error("shared config '%s' is not a blob", sha1_name);
+ return -1;
+ }
+ free(config_file);
+ config_file_name = NULL;
+ return ret;
+}
+
const char *git_etc_gitconfig(void)
{
static const char *system_wide;
--
1.7.3.3.476.g893a9
^ permalink raw reply related
* [PATCH 1/3] config: read full file content before parsing
From: Nguyễn Thái Ngọc Duy @ 2010-12-09 15:09 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy
In-Reply-To: <1291907388-9068-1-git-send-email-pclouds@gmail.com>
config files are usually short enough that we can read in full. This
allows the parser to parse in-memory config, for example from a blob.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
config.c | 62 +++++++++++++++++++++++++++++++++++---------------------------
1 files changed, 35 insertions(+), 27 deletions(-)
diff --git a/config.c b/config.c
index f138c34..c8bf46f 100644
--- a/config.c
+++ b/config.c
@@ -12,7 +12,8 @@
#define MAXNAME (256)
-static FILE *config_file;
+static char *config_file;
+static size_t config_file_size, config_file_pos;
static const char *config_file_name;
static int config_linenr;
static int config_file_eof;
@@ -108,28 +109,26 @@ int git_config_parse_environment(void) {
static int get_next_char(void)
{
- int c;
- FILE *f;
+ size_t unread = config_file_size - config_file_pos;
+
+ if (config_file == NULL)
+ return '\n';
- c = '\n';
- if ((f = config_file) != NULL) {
- c = fgetc(f);
+ if (unread) {
+ char c = config_file[config_file_pos++];
if (c == '\r') {
/* DOS like systems */
- c = fgetc(f);
- if (c != '\n') {
- ungetc(c, f);
- c = '\r';
- }
+ if (unread > 1 &&
+ config_file[config_file_pos] == '\n')
+ c = config_file[config_file_pos++];
}
if (c == '\n')
config_linenr++;
- if (c == EOF) {
- config_file_eof = 1;
- c = '\n';
- }
+ return c;
}
- return c;
+
+ config_file_eof = 1;
+ return '\n';
}
static char *parse_value(void)
@@ -786,19 +785,27 @@ int git_default_config(const char *var, const char *value, void *dummy)
int git_config_from_file(config_fn_t fn, const char *filename, void *data)
{
- int ret;
- FILE *f = fopen(filename, "r");
+ struct stat st;
+ int ret = -1, fd;
+
+ if (lstat(filename, &st))
+ return -1;
+ fd = open(filename, O_RDONLY);
+ if (fd == -1)
+ return -1;
- ret = -1;
- if (f) {
- config_file = f;
+ config_file = xmalloc(st.st_size);
+ if (read_in_full(fd, config_file, st.st_size) == st.st_size) {
+ config_file_pos = 0;
+ config_file_size = st.st_size;
config_file_name = filename;
config_linenr = 1;
config_file_eof = 0;
ret = git_parse_file(fn, data);
- fclose(f);
- config_file_name = NULL;
}
+ close(fd);
+ free(config_file);
+ config_file_name = NULL;
return ret;
}
@@ -921,7 +928,7 @@ static int store_aux(const char *key, const char *value, void *cb)
return 1;
}
- store.offset[store.seen] = ftell(config_file);
+ store.offset[store.seen] = config_file_pos;
store.seen++;
}
break;
@@ -948,19 +955,19 @@ static int store_aux(const char *key, const char *value, void *cb)
* Do not increment matches: this is no match, but we
* just made sure we are in the desired section.
*/
- store.offset[store.seen] = ftell(config_file);
+ store.offset[store.seen] = config_file_pos;
/* fallthru */
case SECTION_END_SEEN:
case START:
if (matches(key, value)) {
- store.offset[store.seen] = ftell(config_file);
+ store.offset[store.seen] = config_file_pos;
store.state = KEY_SEEN;
store.seen++;
} else {
if (strrchr(key, '.') - key == store.baselen &&
!strncmp(key, store.key, store.baselen)) {
store.state = SECTION_SEEN;
- store.offset[store.seen] = ftell(config_file);
+ store.offset[store.seen] = config_file_pos;
}
}
}
@@ -1380,6 +1387,7 @@ int git_config_rename_section(const char *old_name, const char *new_name)
{
int ret = 0, remove = 0;
char *config_filename;
+ FILE *config_file;
struct lock_file *lock = xcalloc(sizeof(struct lock_file), 1);
int out_fd;
char buf[1024];
--
1.7.3.3.476.g893a9
^ permalink raw reply related
* [RFC/WIP 0/3] Shared config
From: Nguyễn Thái Ngọc Duy @ 2010-12-09 15:09 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy
Another approach is [1]. I think this one is somewhat simpler and
exposes less risk by putting the shared config under version control.
This is not complete (for example, git-prune should learn about this),
but is there any serious flaw that I missed?
One thing that I haven't thought of is the shared config between
subprojects. Maybe there's a better approach for subprojects.
(The resistance to nd/struct-pathspec seems great. This is the second
time I come to address it and end up with something else)
[1] http://thread.gmane.org/gmane.comp.version-control.git/162309
Nguyễn Thái Ngọc Duy (3):
config: read full file content before parsing
config: add git_config_from_sha1() to read from a blob
config: add core.sharedconfig
cache.h | 1 +
config.c | 110 +++++++++++++++++++++++++++++++++++++++++++--------------
environment.c | 1 +
3 files changed, 85 insertions(+), 27 deletions(-)
--
1.7.3.3.476.g893a9
^ permalink raw reply
* Re: git fetch vs push, git am questions
From: Konstantin Khomoutov @ 2010-12-09 13:57 UTC (permalink / raw)
To: Konstantin Kivi; +Cc: git
In-Reply-To: <60371291725083@web106.yandex.ru>
On Tue, 07 Dec 2010 15:31:23 +0300
Konstantin Kivi <kkivi@yandex.ru> wrote:
>> `git pull` does exactly that: fetch + merge (which should result in
>> fast-forward in your case).
> pull does not work on bare repos.
Then the only way to update any branch after fetching I can think of
is using `git update-ref` and the information from FETCH_HEAD.
>>> I also found that there is a notions of current branch in bare
>>> repository
>>> How can I change current branch in bare repositry?
> I think I will understand things better if I get what is 'current
> branch' for bare repository and how to change it
>> By re-writing the HEAD ref (this behaviour is documented in the
>> man page of the `git clone` command, see the "--branch" option for
>> instance).
> The repository already exists, so git-clone will not help
I did not propose to use git-clone, I just stated which section of
which manual page hints at what is considered to be the current branch
in a bare repository when Git clones it.
>> You can use the `git symbolic-ref` to update the HEAD ref.
> Do you mean something like
> git symbolic-ref master origin/master ?
Something like
git symbolic-ref HEAD refs/heads/master
P.S.
I also wonder how did you manage to get origin/master in a bare
repository. When I `git clone --bare` an existing Git repository,
I get one branch named "master" (or whatever branch was current in the
source repository), and in the `git clone` manual page we see:
--bare
Make a bare GIT repository. That is, instead of creating
<directory> and placing the administrative files in <directory>/.git,
make the <directory> itself the $GIT_DIR. This obviously implies the -n
because there is nowhere to check out the working tree. Also the branch
heads at the remote are copied directly to corresponding local branch
heads, without mapping them to refs/remotes/origin/. When this option
is used, neither remote-tracking branches nor the related configuration
variables are created.
Which describes the behaviour I see. So it seems you have somehow
botched setup. Like you took a non-bare repository and just copied its
".git" subdirectory somewhere pretending it's now a bare repo.
^ permalink raw reply
* Re: blame formatting bug
From: Thomas Rast @ 2010-12-09 13:55 UTC (permalink / raw)
To: Vitali; +Cc: git
In-Reply-To: <4D008F3A.7080205@gmx.com>
Vitali wrote:
> df9c37ec jquery/jquery.js (John Resig 2006-07-09 20:49:40 +0000 578)
> extend: function(obj,prop) {
> if ( !prop ) {
> prop = obj;
> obj = this;
> }
>
> for ( var i in prop )
> obj[i] = prop[i];
>
> return obj;
> }
>
> Looks like bug.
My 'less' shows that these lines are "terminated" with CRs. Git's
diff engine does not treat CRs as line endings, so neither does blame.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: Push to all repositories
From: Martin von Zweigbergk @ 2010-12-09 13:36 UTC (permalink / raw)
To: Kevin Sheedy; +Cc: git
In-Reply-To: <1291898174244-5818757.post@n2.nabble.com>
On Thu, Dec 9, 2010 at 7:36 AM, Kevin Sheedy <kevinsheedy@gmail.com> wrote:
>
> In summary, I think it would be cool if there was a programmatic way of
> saying:
> "Hey everybody, I've changed some code on branch x and I think you should
> have it"
>
> Everyone else would then have the choices:
> 1) Always accept, I trust you (but don't blow away my current work,
> obviously)
I think the closest thing would be a cron job that runs "git pull"
every minute or so. A difference from dynamic views is that it would
no longer update your work tree once your changes start conflicting
with the upstream changes (in dynamic views, all unmodified files
would be updated).
However, rather than trying to make Git behave just like ClearCase
dynamic views (there are many other things to consider than automatic
updates), I think you would be better off if you actually use
ClearCase dynamic views instead.
> 2) Always ignore, I'll get it when I'm good and ready
This is of course the easy case; just run "git pull" manually.
/Martin
^ permalink raw reply
* Re: [PATCH] git-send-email: Accept -n as a synonym for --dry-run
From: Thomas Rast @ 2010-12-09 13:35 UTC (permalink / raw)
To: Alejandro R. Sedeño; +Cc: git
In-Reply-To: <1291869878-19645-1-git-send-email-asedeno@mit.edu>
Alejandro R. Sedeño wrote:
> diff --git a/git-send-email.perl b/git-send-email.perl
> index 76565de..7e3df9a 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -85,7 +85,7 @@ git send-email [options] <file | directory | rev-list options >
> --confirm <str> * Confirm recipients before sending;
> auto, cc, compose, always, or never.
> --quiet * Output one line of info per email.
> - --dry-run * Don't actually send the emails.
> + -n, --dry-run * Don't actually send the emails.
> --[no-]validate * Perform patch sanity checks. Default on.
> --[no-]format-patch * understand any non optional arguments as
> `git format-patch` ones.
Good change by itself, but this is the first short option for
git-send-email. Maybe --force should also get its analogous -f alias?
Any others?
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* [PATCH] Corrected return values in prep_for_email;
From: Alan Raison @ 2010-12-09 13:24 UTC (permalink / raw)
To: 'Kevin P. Fleming', 'Junio C Hamano'; +Cc: git
In-Reply-To: <4CFE8E97.4020508@digium.com>
>From ebe98d1c682f268b39a7eaf3ef529accbf0ac61c Mon Sep 17 00:00:00 2001
From: Alan Raison <alan@theraisons.me.uk>
Date: Mon, 6 Dec 2010 15:49:21 +0000
Subject: [PATCH] Corrected return values in prep_for_email;
Function was returning 0 for failure and 1 for success which was breaking
the logic in the main loop.
Corrected to return 0 for success, 1 for failure. Function now also returns
in all cases, rather than exiting.
---
contrib/hooks/post-receive-email | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/contrib/hooks/post-receive-email
b/contrib/hooks/post-receive-email
index 85724bf..f99ea95 100755
--- a/contrib/hooks/post-receive-email
+++ b/contrib/hooks/post-receive-email
@@ -144,13 +144,13 @@ prep_for_email()
short_refname=${refname##refs/remotes/}
echo >&2 "*** Push-update of tracking branch,
$refname"
echo >&2 "*** - no email generated."
- exit 0
+ return 1
;;
*)
# Anything else (is there anything else?)
echo >&2 "*** Unknown type of update to $refname
($rev_type)"
echo >&2 "*** - no email generated"
- return 0
+ return 1
;;
esac
@@ -166,10 +166,10 @@ prep_for_email()
esac
echo >&2 "*** $config_name is not set so no email will be
sent"
echo >&2 "*** for $refname update $oldrev->$newrev"
- return 0
+ return 1
fi
- return 1
+ return 0
}
#
--
1.7.3.1.msysgit.0
^ permalink raw reply related
* Re: Push to all repositories
From: Nguyen Thai Ngoc Duy @ 2010-12-09 12:47 UTC (permalink / raw)
To: Kevin Sheedy; +Cc: git
In-Reply-To: <1291898174244-5818757.post@n2.nabble.com>
On Thu, Dec 9, 2010 at 7:36 PM, Kevin Sheedy <kevinsheedy@gmail.com> wrote:
>
> In summary, I think it would be cool if there was a programmatic way of
> saying:
> "Hey everybody, I've changed some code on branch x and I think you should
> have it"
See "update" hook in githooks man page. Add "pushall" alias for "for
repo in..." from Jonathan's mail.
--
Duy
^ permalink raw reply
* Re: Push to all repositories
From: Kevin Sheedy @ 2010-12-09 12:36 UTC (permalink / raw)
To: git
In-Reply-To: <1291849156593-5817177.post@n2.nabble.com>
In summary, I think it would be cool if there was a programmatic way of
saying:
"Hey everybody, I've changed some code on branch x and I think you should
have it"
Everyone else would then have the choices:
1) Always accept, I trust you (but don't blow away my current work,
obviously)
2) Always ignore, I'll get it when I'm good and ready
Kev
--
View this message in context: http://git.661346.n2.nabble.com/Push-to-all-repositories-tp5816069p5818757.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH 0/2] [RFD] Using gitrevisions :/search style with other operators
From: Nguyen Thai Ngoc Duy @ 2010-12-09 11:53 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Junio C Hamano, Kevin Ballard, Yann Dirson, Jeff King
In-Reply-To: <201012091243.44824.jnareb@gmail.com>
On Thu, Dec 9, 2010 at 6:43 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Thu, 9 Dec 2010, Nguyen Thai Ngoc Duy wrote:
>> On Thu, Dec 9, 2010 at 7:44 AM, Jakub Narebski <jnareb@gmail.com> wrote:
>>> On Thu, 9 Dec 2010, Nguyen Thai Ngoc Duy wrote:
>>>> 2010/12/9 Jakub Narebski <jnareb@gmail.com>:
>>>
>>>>> I wonder if it would be possible to make :/<regex> (which looks a bit
>>>>> like searching the index) to be an alias to --all^{/<regex>}...
>>>>
>>>> It looks a bit strange to my eyes to merge normal option name with
>>>> revision syntax. But I think it's possible. Do we allow branch/tag
>>>> name with leading '-'?
>>>
>>> Well, with below proposal it would simply be
>>>
>>> --all ^{/<regexp>}
>>
>> This hardly works with range and may conflict with "--all" being
>> already used by some commands.
>
> It is '--all' like in "git log --all".
>
> The proposed semantics for ^{/foo} (i.e. not attached to revision)
> would be that it acts on all positive revs on the left of it, replacing
> them. But that might be not easy to do, and it feels a bit
> overengineered.
Yes, maybe.
>> I think we can move '/' out of {}, the space between '/' and '{' can
>> be used for optional parameters: ^/{foo}.
>
> Do you mean using e.g. ^/:i{foo} for :ignorecase, instead of ^{:i/foo}
> or ^{i/foo}?
Yes. I find "^/" easier to read than "^{/". But "^{/" is more
consistent to the rest.
--
Duy
^ permalink raw reply
* Re: [PATCH 0/2] [RFD] Using gitrevisions :/search style with other operators
From: Jakub Narebski @ 2010-12-09 11:43 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: git, Junio C Hamano, Kevin Ballard, Yann Dirson, Jeff King
In-Reply-To: <AANLkTin1SjEzBnLd-HK9fANShLezAKHAOai9MyF-cuoT@mail.gmail.com>
On Thu, 9 Dec 2010, Nguyen Thai Ngoc Duy wrote:
> On Thu, Dec 9, 2010 at 7:44 AM, Jakub Narebski <jnareb@gmail.com> wrote:
>> On Thu, 9 Dec 2010, Nguyen Thai Ngoc Duy wrote:
>>> 2010/12/9 Jakub Narebski <jnareb@gmail.com>:
>>
>>>> I wonder if it would be possible to make :/<regex> (which looks a bit
>>>> like searching the index) to be an alias to --all^{/<regex>}...
>>>
>>> It looks a bit strange to my eyes to merge normal option name with
>>> revision syntax. But I think it's possible. Do we allow branch/tag
>>> name with leading '-'?
>>
>> Well, with below proposal it would simply be
>>
>> --all ^{/<regexp>}
>
> This hardly works with range and may conflict with "--all" being
> already used by some commands.
It is '--all' like in "git log --all".
The proposed semantics for ^{/foo} (i.e. not attached to revision)
would be that it acts on all positive revs on the left of it, replacing
them. But that might be not easy to do, and it feels a bit
overengineered.
> I think we can move '/' out of {}, the space between '/' and '{' can
> be used for optional parameters: ^/{foo}.
Do you mean using e.g. ^/:i{foo} for :ignorecase, instead of ^{:i/foo}
or ^{i/foo}?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH 0/2] [RFD] Using gitrevisions :/search style with other operators
From: Jakub Narebski @ 2010-12-09 11:38 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jonathan Nieder, Nguyen Thai Ngoc Duy, git, Kevin Ballard,
Yann Dirson, Jeff King
In-Reply-To: <7vsjy7h3db.fsf@alter.siamese.dyndns.org>
On Thu, 9 Dec 2010, Junio C Hamano wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>> Jakub Narebski wrote:
>>
>>> You would need HEAD{^{/foo}^@}x3, or use special rule that HEAD^{/foo}x2
>>> means really HEAD^{/foo}^@^{/foo}, with ^@ used to join them.
>>
>> That said, does ^2x500 really do something meaningful that a person
>> would ever need? I like the
>>
>> ^{:nth(3)/foo}
>>
>> syntax because perl6 supports m:nth(3)/foo/, suggesting a menu of
>> already-defined modifiers to implement when they prove useful,...
>
> Can you explain what the colon in "$commit^{:nth(3)/foo}" is doing?
>
> Are we declaring anything that begins with ':' is a magic inside ^{...}
> construct?
The idea is to follow Perl 6 rule of combining modifiers "Every modifier
must start with its own colon."
http://perlcabal.org/syn/S05.html#Modifiers
This allow for easy combining modifiers without introducing special rules,
for example ^{:g:i/foo} would return all matches (:g == :global) instead
of only the first, ignoring case (:i == :ignorecase).
> I do not think nth($n) without specifying where to start (iow, what the
> current ":/foo" implementation does but with "three levels deep") makes
> any sense, but because the main point of your argument is that we can have
> modifies other than nth($n) that may make sense in such a context, I would
> want to make sure anything we come up with is extensible to that syntax.
Hmmm... I haven't thought about it. I guess that ^{:nth(N)/foo} should
return Nth element in the list that ^{:g/foo} / --grep=foo would return.
This way one could use
$ git log pu@{1}..pu --merges --grep="Merge branch 'nd/"
to find all new Nguyen contributions in 'pu', and
$ git log pu..pu^{:2nd/Merge branch 'nd/}^2
to view 2nd (2nd == nth(2)) such branch on the list.
>
> On the "starting from any ref" front, I think "!" (as in ":/!some magic")
> was the introducer we reserved for such a magic some time ago, so perhaps
> on the "starting from this commit" side, "^{!magic/foo}" may be more
> appropriate?
I'd like to deprecate ":/foo" in favor of "--all ^{/foo}", or even special
case it to "^{/foo}" (if not attached to ref, ^{(:<modifier>)*/<regexp>}
acts on positive revs replacing them).
But ^{/foo} might be overengineered...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] t9010 fails when no svn is available
From: Ramkumar Ramachandra @ 2010-12-09 8:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmxofh1x4.fsf@alter.siamese.dyndns.org>
Junio C Hamano writes:
> Running test t9010 without svn currently errors out for no good reason.
>
> The test uses "svnadmin" without checking if svn is available. This was a
> regression introduced by b0ad24b (t9010 (svn-fe): Eliminate dependency on
> svn perl bindings, 2010-10-10) when it stopped including ./lib-git-svn.sh
> that had the safety.
>
> This should fix it.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Right. Thanks for catching this.
-- Ram
^ 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