* Re: [PATCH] Colourise git-branch output
From: Sean @ 2006-12-12 0:38 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200612112210.08327.andyparkins@gmail.com>
On Mon, 11 Dec 2006 22:10:08 +0000
Andy Parkins <andyparkins@gmail.com> wrote:
> +int git_branch_config(const char *var, const char *value)
> +{
> + if (!strcmp(var, "branch.color")) {
> + branch_use_color = git_config_colorbool(var, value);
> + return 0;
> + }
> + return git_default_config(var, value);
> +}
As Junio already highlighted, the "branch.*" namespace is for actual
branch names. This config option should go into "color.branch" or some
other spot.
^ permalink raw reply
* Re: [PATCH] Colourise git-branch output
From: Junio C Hamano @ 2006-12-12 1:11 UTC (permalink / raw)
To: Sean; +Cc: git
In-Reply-To: <BAYC1-PASMTP114CF00792AB16B95C1597AED70@CEZ.ICE>
Sean <seanlkml@sympatico.ca> writes:
> On Mon, 11 Dec 2006 22:10:08 +0000
> Andy Parkins <andyparkins@gmail.com> wrote:
>
>> +int git_branch_config(const char *var, const char *value)
>> +{
>> + if (!strcmp(var, "branch.color")) {
>> + branch_use_color = git_config_colorbool(var, value);
>> + return 0;
>> + }
>> + return git_default_config(var, value);
>> +}
>
> As Junio already highlighted, the "branch.*" namespace is for actual
> branch names. This config option should go into "color.branch" or some
> other spot.
I didn't. And "branch.color = auto" is actually fine.
The problematic case is "branch.color.remote = purple".
^ permalink raw reply
* Re: [PATCH] Add verbose comments to split_msg()
From: Junio C Hamano @ 2006-12-12 1:15 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200612112212.51533.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> writes:
> I was going to fix a bug in imap-send that was making it include the "From "
> line from git-format-patch in the message sent to the IMAP server. So I
> commented up what split_msg already does.
>
> It turns out the bug was fixed in commit
> e0b0830726286287744cc9e1a629a534bbe75452. So comments only, no fix needed.
> (cherry picked from 3d5b1768f15b5cd430b869f416e72f4f3afe3d4a commit)
>
> Signed-off-by: Andy Parkins <andyparkins@gmail.com>
3d5b1768 is not a public commit and is not useful information
other than your self. Please omit the last line.
Linus and everybody was right and I was wrong to leave this
message default in git-cherry-pick for a long time.
> ---
> imap-send.c | 13 +++++++++++++
> 1 files changed, 13 insertions(+), 0 deletions(-)
>
> diff --git a/imap-send.c b/imap-send.c
> index a6a6568..110bd54 100644
> --- a/imap-send.c
> +++ b/imap-send.c
> @@ -1216,35 +1216,48 @@ split_msg( msg_data_t *all_msgs, msg_data_t *msg, int *ofs )
> {
> char *p, *data;
>
> + /* Clear this message's slot */
> memset( msg, 0, sizeof *msg );
> + /* If we've run out of data, stop*/
"..., stop */"
> if (*ofs >= all_msgs->len)
> return 0;
>
> + /* Point at the next message chunk */
> data = &all_msgs->data[ *ofs ];
> + /* This message length is at most, the length of all messages
> + * minus our current position */
Style?
/*
* This message ...
* ... position.
*/
> msg->len = all_msgs->len - *ofs;
>
> + /* If there isn't enough data remaining for a whole message or there
> + * is no , give up */
"there is no , "???
^ permalink raw reply
* [PATCH] mailinfo: hack to accept in-line annotations in patches.
From: Junio C Hamano @ 2006-12-12 1:15 UTC (permalink / raw)
To: git
Long before git-apply, when I wanted to talk about rationale of
individual changes, I used to add annotation between hunks
(delimited @@ -n,m, +l,k @@) as unindented plain text and rely
on GNU patch to discard them as garbage. Because git-apply is
much less forgiving than GNU patch, this is not possible.
This patch teaches mailinfo that lines that begin with a '|' would
never appear in the patch text and can be discarded safely.
Which means that we can generate a patch as usual using format-patch,
and add annotations inline, prefixed with '|'.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* I am not seriously suggesting this for inclusion but people
might find this handy -- see the first edition of my
git-commit documentation patch for an example (although I
seem to have botched the hand-munge of that message).
builtin-mailinfo.c | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
index b8d7dbc..7819be1 100644
--- a/builtin-mailinfo.c
+++ b/builtin-mailinfo.c
@@ -710,8 +710,11 @@ static void handle_patch(void)
* here; we are dealing with the user payload.
*/
decode_transfer_encoding(line);
- fputs(line, patchfile);
- patch_lines++;
+
+ if (line[0] != '|') {
+ fputs(line, patchfile);
+ patch_lines++;
+ }
} while (fgets(line, sizeof(line), fin) != NULL);
}
--
1.4.4.2.g7d2d-dirty
^ permalink raw reply related
* Re: [PATCH] Make cvsexportcommit work with filenames with spaces and non-ascii characters.
From: Junio C Hamano @ 2006-12-12 1:15 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <200612110048.47435.robin.rosenberg@dewire.com>
Robin Rosenberg <robin.rosenberg@dewire.com> writes:
> söndag 10 december 2006 22:27 skrev Junio C Hamano:
>> Maybe I am missing something. It tells you about added or
>> removed files (either binary or non-binary).
>
> no, I was missing --summary. I thought --numstat did that (man page
> says "similar to stat".
Ah, figures.
Your patch removes more lines than it adds, which is quite nice.
^ permalink raw reply
* Re: [PATCH] no need to install manpages as executable
From: Junio C Hamano @ 2006-12-12 1:15 UTC (permalink / raw)
To: Chris Wright; +Cc: git
In-Reply-To: <20061211073932.GA12555@sequoia.sous-sol.org>
Chris Wright <chrisw@sous-sol.org> writes:
> No need to install manpages as executable. Noticed by Ville Skyttä.
Thanks. I agree there is no need but I wonder why we even need
to specify that explicitly. Well, I guess I did not know that
install(1) was that stupid.
^ permalink raw reply
* Re: [PATCH] Colourise git-branch output
From: Sean @ 2006-12-12 1:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7iwx2a0z.fsf@assigned-by-dhcp.cox.net>
On Mon, 11 Dec 2006 17:11:24 -0800
Junio C Hamano <junkio@cox.net> wrote:
> > As Junio already highlighted, the "branch.*" namespace is for actual
> > branch names. This config option should go into "color.branch" or some
> > other spot.
>
> I didn't. And "branch.color = auto" is actually fine.
>
> The problematic case is "branch.color.remote = purple".
Technically it is workable.. but why even start down the road of having
anything but branch names after a "branch."? There has to be a better
spot for this variable, and it makes it more future proof, as you
highlighted.
^ permalink raw reply
* Re: [PATCH] Colourise git-branch output
From: Linus Torvalds @ 2006-12-12 3:39 UTC (permalink / raw)
To: Sean; +Cc: Junio C Hamano, git
In-Reply-To: <BAYC1-PASMTP092A9E80667F373BF69AA6AED70@CEZ.ICE>
On Mon, 11 Dec 2006, Sean wrote:
>
> Technically it is workable.. but why even start down the road of having
> anything but branch names after a "branch."? There has to be a better
> spot for this variable, and it makes it more future proof, as you
> highlighted.
I do agree with Sean, both for the stability reason, but perhaps even more
because I personally think it would just be better to have a separate
"[color]" subsection.
In fact, I'd almost prefer to see
[color]
diff = auto
over
[diff]
color = auto
exactly because once we have different things that take colorization
arguments, it's just nicer to have them all together (and we already have
"status", and now we're getting "branch" too.
^ permalink raw reply
* Re: Using GIT to store /etc (Or: How to make GIT store all file permission bits)
From: Daniel Barkalow @ 2006-12-12 3:45 UTC (permalink / raw)
To: Kyle Moffett; +Cc: git
In-Reply-To: <787BE48C-1808-4A33-A368-5E8A3F00C787@mac.com>
On Sun, 10 Dec 2006, Kyle Moffett wrote:
> I've recently become somewhat interested in the idea of using GIT to store the
> contents of various folders in /etc. However after a bit of playing with
> this, I discovered that GIT doesn't actually preserve all permission bits
> since that would cause problems with the more traditional software development
> model. I'm curious if anyone has done this before; and if so, how they went
> about handling the permissions and ownership issues.
>
> I spent a little time looking over how GIT stores and compares permission
> bits; trying to figure out if it's possible to patch in a new configuration
> variable or two; say "preserve_all_perms" and "preserve_owner", or maybe even
> "save_acls". It looks like standard permission preservation is fairly basic;
> you would just need to patch a few routines which alter the permissions read
> in from disk or compare them with ones from the database. On the other hand,
> it would appear that preserving ownership or full POSIX ACLs might be a bit of
> a challenge.
The first thing you'd want to do is correct the fact that the index
doesn't keep full permissions. We decided long ago that we don't want to
track more than 0100, but we're discarding the rest between the filesystem
and the index, rather than between the index and the tree. (This is weird
of us, since we keep gid and uid in the index, as changedness heuristics,
but don't keep permissions; of course, we'd have to apply umask to the
index when we check it out to sync what we expect to be there with what
has actually been created.)
I think that would be the only change needed to the index and
index/working directory connection, although it might be necessary to
support longer values for uid/gid/etc, since they'd be important data now.
Note that git only stores content, not incidental information. But a lot
of information which is incidental in a source tree is content in /etc.
This implies that /etc and working/linux-2.6 are fundamentally different
sorts of things, because different aspects of them are content.
I'd suggest a new object type for a directory with permissions, ACLs, and
so forth. It should probably use symbolic owner and group, too. My guess
is that you'll want to use "commit"s, the new object type, and "blob"s.
Everything that uses trees would need to have a version that uses the new
type. But I think that you generally want different behavior anyway, so
that's not a major issue.
-Daniel
^ permalink raw reply
* Re: Problems with git-svn authors file
From: Eric Wong @ 2006-12-12 4:25 UTC (permalink / raw)
To: Nicolas Vilz; +Cc: Junio C Hamano, git
In-Reply-To: <20061210172604.GA18385@hermes.lan.home.vilz.de>
Nicolas Vilz <niv@iaglans.de> wrote:
> hello,
>
> i tried to use git-svn with author-files and got stuck with following
> error message:
>
> Use of uninitialized value in hash element at /usr/bin/git-svn line
> 2952.
> Use of uninitialized value in concatenation (.) or string at
> /usr/bin/git-svn line 2953.
> Author: not defined in .git/info/svn-authors file
> 512 at /usr/bin/git-svn line 457
> main::fetch_lib() called at /usr/bin/git-svn line 328
> main::fetch() called at /usr/bin/git-svn line 187
> Am i doing something wrong?
No, this is just a bug in git-svn.
After the following patch, you should be able to use
--------------------------------------------
(no author) = real-name <email address>
--------------------------------------------
in your authors file.
--
Eric Wong
From b40e14605809b0b1501002a333fbd680913f127f Mon Sep 17 00:00:00 2001
From: Eric Wong <normalperson@yhbt.net>
Date: Mon, 11 Dec 2006 20:22:29 -0800
Subject: [PATCH] git-svn: correctly handle "(no author)" when using an authors file
The low-level parts of the SVN library return NULL/undef for
author-less revisions, whereas "(no author)" is a (svn) client
convention.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-svn.perl | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 1f8a3b0..17ebb77 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -2948,7 +2948,8 @@ sub libsvn_log_entry {
my ($Y,$m,$d,$H,$M,$S) = ($date =~ /^(\d{4})\-(\d\d)\-(\d\d)T
(\d\d)\:(\d\d)\:(\d\d).\d+Z$/x)
or die "Unable to parse date: $date\n";
- if (defined $_authors && ! defined $users{$author}) {
+ if (defined $author && length $author > 0 &&
+ defined $_authors && ! defined $users{$author}) {
die "Author: $author not defined in $_authors file\n";
}
$msg = '' if ($rev == 0 && !defined $msg);
--
^ permalink raw reply related
* Using git-bisect to find more than one breakage
From: n0dalus @ 2006-12-12 4:34 UTC (permalink / raw)
To: git
Hi,
I am trying to find commits in the 2.6.18 linux tree that
cause/trigger problems for a program I use. I found the first commit
by using git-bisect. However, somewhere between that commit and master
there is at least one more commit that breaks things. I'm sure there
must be a way to find this, but the method I'm using doesn't seem to
work (I'm new to git).
This is what I tried to do:
- Make a branch ("working") at the bad commit
- Commit a patch to undo the bug-causing change from that commit
- Make a copy of the master branch
- git-rebase working
- (Then if that worked, use git-bisect to find the next breakage)
I expected git-rebase to just apply all the commits from the master
onto my working branch, possibly stopping in the case of a conflict to
the file I patched. Instead, it produces large conflicts with
unrelated files, on the very first commit it tries to apply. I even
get the conflicts if the commit I make before using git-rebase changes
no files at all (just adding an empty file 'test').
Is there something wrong with my method here? Is there another way to do this?
I am thinking for now I will just use git-bisect between the bad
commit and master, and apply my changes to every bisection.
Any help greatly appreciated,
^ permalink raw reply
* Re: [PATCH] Colourise git-branch output
From: Junio C Hamano @ 2006-12-12 5:07 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Sean, git
In-Reply-To: <Pine.LNX.4.64.0612111936240.6452@woody.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Mon, 11 Dec 2006, Sean wrote:
>>
>> Technically it is workable.. but why even start down the road of having
>> anything but branch names after a "branch."? There has to be a better
>> spot for this variable, and it makes it more future proof, as you
>> highlighted.
>
> I do agree with Sean, both for the stability reason, but perhaps even more
> because I personally think it would just be better to have a separate
> "[color]" subsection.
>
> In fact, I'd almost prefer to see
>
> [color]
> diff = auto
>
> over
>
> [diff]
> color = auto
>
> exactly because once we have different things that take colorization
> arguments, it's just nicer to have them all together (and we already have
> "status", and now we're getting "branch" too.
I tend to agree. We probably should start deprecating
diff.color and diff.color.<stuff> and swap them around,
like this:
[color]
diff = auto
branch = auto
# it begs "* = auto" entry perhaps...
[color.diff]
old = red
new = green
[color.branch]
remote = purple
^ permalink raw reply
* git-svn breakage
From: Dongsheng Song @ 2006-12-12 5:23 UTC (permalink / raw)
To: n0dalus; +Cc: git
Hi,
I am trying to use git-svn synchronize git with svn.
When git-fetch failed midway, and resumed later.The git-svn log output
fine, but git-log output only before resumed.
How can I fix it ?
Any help greatly appreciated,
^ permalink raw reply
* Re: [PATCH] Colourise git-branch output
From: Linus Torvalds @ 2006-12-12 5:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sean, git
In-Reply-To: <7vejr5zoqe.fsf@assigned-by-dhcp.cox.net>
On Mon, 11 Dec 2006, Junio C Hamano wrote:
>
> [color]
> diff = auto
> branch = auto
> # it begs "* = auto" entry perhaps...
> [color.diff]
> old = red
> new = green
> [color.branch]
> remote = purple
I wish you'd learn to use the proper syntax ;)
It would be
[color "diff"]
old = red
new = green
and what's nice about it is that you can also do
[color "diff"]
auto
old = red
new = green
and the config file rules for booleans are such that a config variable
without the "= val" part parses the same as "= true", so you can now do
git repo-config --bool color.diff.auto
and it will say "true".
Now, I just think that would be a nice syntax.
Of course, for legacy reasons, and for people who rather than keeping the
_color_ information together want to keep the _diff_ information together,
we can/probably-should support both color.diff.* and diff.color.* formats.
^ permalink raw reply
* [PATCH] Colourise git-branch output
From: Andy Parkins @ 2006-12-12 6:41 UTC (permalink / raw)
To: git
I wanted to have a visual indication of which branches are local and
which are remote in git-branch -a output; however Junio was concerned
that someone might be using the output in a script. This patch
addresses the problem by colouring the git-branch output - which in
"auto" mode won't be activated.
I've based it off the colouring code for builtin-diff.c; which means
there is a branch color configuration variable that needs setting to
something before the color will appear.
The colour parameter is "color.branch" rather than "branch.color" to
avoid clashing with the default namespace for default branch merge
definitions.
This patch chooses green for local, red for remote and bold green for
current.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
builtin-branch.c | 92 +++++++++++++++++++++++++++++++++++++++++++++++++++---
1 files changed, 87 insertions(+), 5 deletions(-)
diff --git a/builtin-branch.c b/builtin-branch.c
index 3d5cb0e..7c87b8d 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -5,6 +5,7 @@
* Based on git-branch.sh by Junio C Hamano.
*/
+#include "color.h"
#include "cache.h"
#include "refs.h"
#include "commit.h"
@@ -17,6 +18,58 @@ static const char builtin_branch_usage[] =
static const char *head;
static unsigned char head_sha1[20];
+static int branch_use_color;
+static char branch_colors[][COLOR_MAXLEN] = {
+ "\033[m", /* reset */
+ "", /* PLAIN (normal) */
+ "\033[31m", /* REMOTE (red) */
+ "\033[32m", /* LOCAL (green) */
+ "\033[1;32m", /* CURRENT (boldgreen) */
+};
+enum color_branch {
+ COLOR_BRANCH_RESET = 0,
+ COLOR_BRANCH_PLAIN = 1,
+ COLOR_BRANCH_REMOTE = 2,
+ COLOR_BRANCH_LOCAL = 3,
+ COLOR_BRANCH_CURRENT = 4,
+};
+
+static int parse_branch_color_slot(const char *var, int ofs)
+{
+ if (!strcasecmp(var+ofs, "plain"))
+ return COLOR_BRANCH_PLAIN;
+ if (!strcasecmp(var+ofs, "reset"))
+ return COLOR_BRANCH_RESET;
+ if (!strcasecmp(var+ofs, "remote"))
+ return COLOR_BRANCH_REMOTE;
+ if (!strcasecmp(var+ofs, "local"))
+ return COLOR_BRANCH_LOCAL;
+ if (!strcasecmp(var+ofs, "current"))
+ return COLOR_BRANCH_CURRENT;
+ die("bad config variable '%s'", var);
+}
+
+int git_branch_config(const char *var, const char *value)
+{
+ if (!strcmp(var, "color.branch")) {
+ branch_use_color = git_config_colorbool(var, value);
+ return 0;
+ }
+ if (!strncmp(var, "color.branch.", 13)) {
+ int slot = parse_branch_color_slot(var, 13);
+ color_parse(value, var, branch_colors[slot]);
+ return 0;
+ }
+ return git_default_config(var, value);
+}
+
+const char *branch_get_color(enum color_branch ix)
+{
+ if (branch_use_color)
+ return branch_colors[ix];
+ return "";
+}
+
static int in_merge_bases(const unsigned char *sha1,
struct commit *rev1,
struct commit *rev2)
@@ -183,6 +236,7 @@ static void print_ref_list(int kinds, int verbose, int abbrev)
int i;
char c;
struct ref_list ref_list;
+ int color;
memset(&ref_list, 0, sizeof(ref_list));
ref_list.kinds = kinds;
@@ -191,18 +245,38 @@ static void print_ref_list(int kinds, int verbose, int abbrev)
qsort(ref_list.list, ref_list.index, sizeof(struct ref_item), ref_cmp);
for (i = 0; i < ref_list.index; i++) {
+ switch( ref_list.list[i].kind ) {
+ case REF_LOCAL_BRANCH:
+ color = COLOR_BRANCH_LOCAL;
+ break;
+ case REF_REMOTE_BRANCH:
+ color = COLOR_BRANCH_REMOTE;
+ break;
+ default:
+ color = COLOR_BRANCH_PLAIN;
+ break;
+ }
+
c = ' ';
if (ref_list.list[i].kind == REF_LOCAL_BRANCH &&
- !strcmp(ref_list.list[i].name, head))
+ !strcmp(ref_list.list[i].name, head)) {
c = '*';
+ color = COLOR_BRANCH_CURRENT;
+ }
if (verbose) {
- printf("%c %-*s", c, ref_list.maxwidth,
- ref_list.list[i].name);
+ printf("%c %s%-*s%s", c,
+ branch_get_color(color),
+ ref_list.maxwidth,
+ ref_list.list[i].name,
+ branch_get_color(COLOR_BRANCH_RESET));
print_ref_info(ref_list.list[i].sha1, abbrev);
}
else
- printf("%c %s\n", c, ref_list.list[i].name);
+ printf("%c %s%s%s\n", c,
+ branch_get_color(color),
+ ref_list.list[i].name,
+ branch_get_color(COLOR_BRANCH_RESET));
}
free_ref_list(&ref_list);
@@ -253,7 +327,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
int kinds = REF_LOCAL_BRANCH;
int i;
- git_config(git_default_config);
+ git_config(git_branch_config);
for (i = 1; i < argc; i++) {
const char *arg = argv[i];
@@ -297,6 +371,14 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
verbose = 1;
continue;
}
+ if (!strcmp(arg, "--color")) {
+ branch_use_color = 1;
+ continue;
+ }
+ if (!strcmp(arg, "--no-color")) {
+ branch_use_color = 0;
+ continue;
+ }
usage(builtin_branch_usage);
}
--
1.4.4.1.geeee8
^ permalink raw reply related
* Re: [PATCH] Colourise git-branch output
From: Junio C Hamano @ 2006-12-12 7:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0612112135360.6452@woody.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> I wish you'd learn to use the proper syntax ;)
Ok, ok, I'm an old timer. But [color.diff] syntax is also
accepted and I have it in my ~/.gitconfig:
$ cat ~/.gitconfig
[diff.color]
old = red reverse
$ git repo-config --global diff.color.old
red reverse
$ exit
> ... what's nice about it is that you can also do
>
> [color "diff"]
> auto
> old = red
> new = green
>
> and the config file rules for booleans are such that a config variable
> without the "= val" part parses the same as "= true", so you can now do
>
> git repo-config --bool color.diff.auto
>
> and it will say "true".
I find that your version of "auto" above to be utterly
confusing.
The existing configuration variable diff.color as an extended
boolean takes true, false or "auto".
I do agree this is a nice way to say that I pretend to be color
blind to git repo-config:
$ git repo-config --global --bool color.diff false
$ cat ~/.gitconfig
[color]
diff = false
and it is also nice to be able to say my preference is "auto"
with (you can have --bool with this example and still use
"auto", by the way, when setting):
$ git repo-config --global color.diff auto
$ cat ~/.gitconfig
[color]
diff = auto
I also agree it is nice that the "boolean magic" kicks in when
we hand-craft it:
$ cat ~/.gitconfig
[color]
diff
$ git repo-config --global --bool color.diff
true
But your handcrafted
[color "diff"]
auto
simply feels a very confusing syntax. How would you even
express my preference is always-color (that is, "true")?
If we are changing color.diff to color.diff.usecolor which is
bool + auto, then I would understand it.
[color "diff"]
usecolor
# usecolor = auto
# usecolor = no
but that would not let you query with --bool ("auto" would
barf).
I guess we should at least extend --bool so that scripts can
easily query extended bools; if the value looks like a bool (or
there is no value), it would return it normalized to "true" or
"false" so they do not have to say:
case `repo-config --bool the.variable` in
true | yes | on | 1)
echo ah you mean yes ;;
esac
but if the value is not either boolean true or false, then
return the string as is (such as "auto"). I am inclined to just
extend --bool itself to do so (which means we would lose the
error checking form the script for truly boolean fields) rather
than adding a new --bool-or-string option.
In any case,
[color]
diff
# diff = auto
# diff = no
would work already if we only talk about built-in accesses. We
would need to extend repo-config --bool to make it easier for
scripts to work with this extended bool, but that is a minor
detail.
So it seems to me that the only reason to have
color.diff.usecolor is so that we can have "diff" related color
settings in one place. Which is fine.
You could do the same thing with your "auto"
[color "diff"]
auto
# auto = always
# auto = no
but what that means is that color.diff.auto _is_ the extended
boolean that tells us to:
* use color on terminal when set to true
* use color unconditionally when set to a non-bool 'always'
* never use color when set to false
which sounds rather, eh, unusual.
^ permalink raw reply
* Re: [PATCH] Add verbose comments to split_msg()
From: Andreas Ericsson @ 2006-12-12 8:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andy Parkins, git
In-Reply-To: <7vzm9tzzgt.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Andy Parkins <andyparkins@gmail.com> writes:
>
>>
>> + /* If there isn't enough data remaining for a whole message or there
>> + * is no , give up */
>
> "there is no , "???
>
spoon
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: trouble with git cvsimport
From: Andreas Ericsson @ 2006-12-12 8:25 UTC (permalink / raw)
To: Ian Molton; +Cc: git
In-Reply-To: <457DE980.50605@f2s.com>
Ian Molton wrote:
> Hi.
>
> I imported a CVS repo with git cvsimport, which went well enough,
> however subsequent repeats of the same command arent updating the git
> repo. whats up?
>
> command Im using is:
>
> git-cvsimport -d:local:/home/ian/projects/hh.org_cvs/cvs/ -k -m -p x -o
> hh.org_cvs linux/kernel26
Does linux/kernel26/.git/.git exists? I managed to get something similar
once and it had me confused a loong time.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Andreas Ericsson @ 2006-12-12 8:32 UTC (permalink / raw)
To: Jon Loeliger; +Cc: Linus Torvalds, sf, Git List, Martin Waitz
In-Reply-To: <1165602554.19135.309.camel@cashmere.sps.mot.com>
Jon Loeliger wrote:
> On Fri, 2006-12-01 at 14:13, Linus Torvalds wrote:
>
>> So this is why it's really important that the submodule really is a git
>> repository in its own right, and why committing stuff in the supermodule
>> NEVER affect the submodule itself directly (it might _cause_ you to also
>> do a commit in the submodule indirectly, but the submodule commit MUST be
>> totally independent, and stand on its own).
>
> An implication of this is that the entire administrative
> responsibility for having some super-sub module interaction
> lies entirely with the supermodule.
>
That's a good thing. I wouldn't want the openssl maintainers to have to
bother with every project that uses their code, and I'm fairly certain
they feel the same.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: [PATCH] Colourise git-branch output
From: Johannes Sixt @ 2006-12-12 8:46 UTC (permalink / raw)
To: git
In-Reply-To: <200612120641.52556.andyparkins@gmail.com>
Andy Parkins wrote:
> This patch chooses green for local, red for remote and bold green for
> current.
Sorry for chiming in so late, but red and green are usually poor choices
since red-green color-blindness is surprisingly frequent...
Maybe its sufficient to have just the remote branches (dark-)red, and
the rest in the default color, with the current branch bold?
-- Hannes
^ permalink raw reply
* Re: [PATCH] Allow building GIT in a different directory from the source directory
From: Junio C Hamano @ 2006-12-12 9:03 UTC (permalink / raw)
To: hanwen; +Cc: git
In-Reply-To: <eljo2u$pnq$2@sea.gmane.org>
Han-Wen Nienhuys <hanwen@xs4all.nl> writes:
> GIT can now be built in a separate builddirectory. This is done as
> follows:
>
> mkdir build
> cd build
> $my_git_dir/configure
> make
Somehow making this depend on the use of configure feels wrong,
since we tried to keep that config.mak.gen built by configure
strictly optional. In other words, I think the result of your
patch should be buildable with or without ./configure in a
separate directory if we are going to do this.
Care to explain why it is too cumbersome to handle without
./configure magic?
^ permalink raw reply
* Re: stgit: No patches to pop
From: Catalin Marinas @ 2006-12-12 9:10 UTC (permalink / raw)
To: Bahadir Balban; +Cc: Jakub Narebski, git
In-Reply-To: <7ac1e90c0612110905x3f1632b9v17bb14e810715cbf@mail.gmail.com>
"Bahadir Balban" <bahadir.balban@gmail.com> wrote:
> On 12/11/06, Jakub Narebski <jnareb@gmail.com> wrote:
>> That is kind of strange. Pop should work like pop does, for example
>> the one in Perl or Python, removing n elements from the stack of applied
>> patches. Not work as "float <patch>"...
>> --
>> Jakub Narebski
>> Warsaw, Poland
>> ShadeHawk on #git
>
> As a new user my first expectation was as Catalin has revised. If it's
> going to stay as in 0.11 at least it would be nice to have it
> described in the wiki.
It was already modified in the StGIT repository and I am won't revert
it to the 0.11 functionality. Please feel free to modify the wiki
(which is really out of date - "stg help <command>" has more
up-to-date information).
--
^ permalink raw reply
* Re: git-svn breakage
From: Eric Wong @ 2006-12-12 9:19 UTC (permalink / raw)
To: Dongsheng Song; +Cc: git
In-Reply-To: <4b3406f0612112123h13e346d2r5a3b196595bc017a@mail.gmail.com>
Dongsheng Song <dongsheng.song@gmail.com> wrote:
> Hi,
>
> I am trying to use git-svn synchronize git with svn.
>
> When git-fetch failed midway, and resumed later.The git-svn log output
> fine, but git-log output only before resumed.
>
> How can I fix it ?
git-svn only updates refs/heads/master to the last refs/remotes/git-svn
revision on the first time fetch runs. Since git-log defaults
to HEAD (which most likely points to refs/heads/master, use git-branch
to find out), it'll only show the information in refs/heads/master.
So if you want to see the latest revisions that git-svn fetched,
then use 'git log remotes/git-svn'
To pull changes into your working copy (or HEAD) use:
git rebase refs/remotes/git-svn
--
^ permalink raw reply
* Re: Collection of stgit issues and wishes
From: Catalin Marinas @ 2006-12-12 9:43 UTC (permalink / raw)
To: Yann Dirson; +Cc: GIT list
In-Reply-To: <20061208221744.GA3288@nan92-1-81-57-214-146.fbx.proxad.net>
On 08/12/06, Yann Dirson <ydirson@altern.org> wrote:
> - shortcuts (st -> status, etc.), possibly making use of the git alias
> system ?
Did this last night as it was pretty easy and without the GIT alias
system (which I am not familiar with). The idea is that if it cannot
find an exact match, it tries to look for all the commands starting
with the passed argument. If more than one command is found, it
reports an "ambiguous command".
--
^ permalink raw reply
* Re: Collection of stgit issues and wishes
From: Jakub Narebski @ 2006-12-12 10:02 UTC (permalink / raw)
To: git
In-Reply-To: <b0943d9e0612120143j7d0c1026rab046c8f44ec43ca@mail.gmail.com>
Catalin Marinas wrote:
> On 08/12/06, Yann Dirson <ydirson@altern.org> wrote:
>> - shortcuts (st -> status, etc.), possibly making use of the git alias
>> system ?
>
> Did this last night as it was pretty easy and without the GIT alias
> system (which I am not familiar with). The idea is that if it cannot
> find an exact match, it tries to look for all the commands starting
> with the passed argument. If more than one command is found, it
> reports an "ambiguous command".
Isn't it better to use tab completion for that?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ 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