Git development
 help / color / mirror / Atom feed
* [PATCH 3/4] Export launch_editor() and make it accept ':' as a no-op editor.
From: Kristian Høgsberg @ 2007-11-02 15:33 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git
In-Reply-To: <1194017589-4669-2-git-send-email-krh@redhat.com>

Signed-off-by: Kristian Høgsberg <krh@redhat.com>
---
 builtin-tag.c |    5 ++++-
 strbuf.h      |    1 +
 2 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/builtin-tag.c b/builtin-tag.c
index 66e5a58..bcb3a7a 100644
--- a/builtin-tag.c
+++ b/builtin-tag.c
@@ -17,7 +17,7 @@ static const char builtin_tag_usage[] =
 
 static char signingkey[1000];
 
-static void launch_editor(const char *path, struct strbuf *buffer)
+void launch_editor(const char *path, struct strbuf *buffer)
 {
 	const char *editor, *terminal;
 	struct child_process child;
@@ -42,6 +42,9 @@ static void launch_editor(const char *path, struct strbuf *buffer)
 	if (!editor)
 		editor = "vi";
 
+	if (!strcmp(editor, ":"))
+		return;
+
 	memset(&child, 0, sizeof(child));
 	child.argv = args;
 	args[0] = editor;
diff --git a/strbuf.h b/strbuf.h
index 9b9e861..9720826 100644
--- a/strbuf.h
+++ b/strbuf.h
@@ -113,5 +113,6 @@ extern int strbuf_read_file(struct strbuf *sb, const char *path, size_t hint);
 extern int strbuf_getline(struct strbuf *, FILE *, int);
 
 extern void stripspace(struct strbuf *buf, int skip_comments);
+extern void launch_editor(const char *path, struct strbuf *buffer);
 
 #endif /* STRBUF_H */
-- 
1.5.3.4.206.g58ba4

^ permalink raw reply related

* [PATCH 2/4] Remove unecessary hard-coding of EDITOR=':' VISUAL=':' in some test suites.
From: Kristian Høgsberg @ 2007-11-02 15:33 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git
In-Reply-To: <1194017589-4669-1-git-send-email-krh@redhat.com>

Signed-off-by: Kristian Høgsberg <krh@redhat.com>
---
 t/t3501-revert-cherry-pick.sh |    4 ++--
 t/t3901-i18n-patch.sh         |    8 ++++----
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/t/t3501-revert-cherry-pick.sh b/t/t3501-revert-cherry-pick.sh
index 552af1c..2dbe04f 100755
--- a/t/t3501-revert-cherry-pick.sh
+++ b/t/t3501-revert-cherry-pick.sh
@@ -44,7 +44,7 @@ test_expect_success setup '
 test_expect_success 'cherry-pick after renaming branch' '
 
 	git checkout rename2 &&
-	EDITOR=: VISUAL=: git cherry-pick added &&
+	git cherry-pick added &&
 	test -f opos &&
 	grep "Add extra line at the end" opos
 
@@ -53,7 +53,7 @@ test_expect_success 'cherry-pick after renaming branch' '
 test_expect_success 'revert after renaming branch' '
 
 	git checkout rename1 &&
-	EDITOR=: VISUAL=: git revert added &&
+	git revert added &&
 	test -f spoo &&
 	! grep "Add extra line at the end" spoo
 
diff --git a/t/t3901-i18n-patch.sh b/t/t3901-i18n-patch.sh
index 28e9e37..235f372 100755
--- a/t/t3901-i18n-patch.sh
+++ b/t/t3901-i18n-patch.sh
@@ -154,7 +154,7 @@ test_expect_success 'cherry-pick(U/U)' '
 	git reset --hard master &&
 	git cherry-pick side^ &&
 	git cherry-pick side &&
-	EDITOR=: VISUAL=: git revert HEAD &&
+	git revert HEAD &&
 
 	check_encoding 3
 '
@@ -169,7 +169,7 @@ test_expect_success 'cherry-pick(L/L)' '
 	git reset --hard master &&
 	git cherry-pick side^ &&
 	git cherry-pick side &&
-	EDITOR=: VISUAL=: git revert HEAD &&
+	git revert HEAD &&
 
 	check_encoding 3 8859
 '
@@ -184,7 +184,7 @@ test_expect_success 'cherry-pick(U/L)' '
 	git reset --hard master &&
 	git cherry-pick side^ &&
 	git cherry-pick side &&
-	EDITOR=: VISUAL=: git revert HEAD &&
+	git revert HEAD &&
 
 	check_encoding 3
 '
@@ -200,7 +200,7 @@ test_expect_success 'cherry-pick(L/U)' '
 	git reset --hard master &&
 	git cherry-pick side^ &&
 	git cherry-pick side &&
-	EDITOR=: VISUAL=: git revert HEAD &&
+	git revert HEAD &&
 
 	check_encoding 3 8859
 '
-- 
1.5.3.4.206.g58ba4

^ permalink raw reply related

* [PATCH 1/4] Add testcase for ammending and fixing author in git commit.
From: Kristian Høgsberg @ 2007-11-02 15:33 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

Signed-off-by: Kristian Høgsberg <krh@redhat.com>
---
 t/t7501-commit.sh |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/t/t7501-commit.sh b/t/t7501-commit.sh
index b151b51..3f2112a 100644
--- a/t/t7501-commit.sh
+++ b/t/t7501-commit.sh
@@ -163,4 +163,14 @@ test_expect_success 'partial commit that involves removal (3)' '
 
 '
 
+author="The Real Author <someguy@his.email.org>"
+test_expect_success 'amend commit to fix author' '
+
+	git reset --hard
+	git cat-file -p HEAD | sed -e "s/author.*>/author $author/" > expected &&
+	git commit --amend --author="$author" &&
+	git cat-file -p HEAD > current &&
+	diff expected current
+	
+'
 test_done
-- 
1.5.3.4.206.g58ba4

^ permalink raw reply related

* Re: [PATCH] Implement git commit as a builtin command.
From: Kristian Høgsberg @ 2007-11-02 15:31 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr6j97ce6.fsf@gitster.siamese.dyndns.org>

On Thu, 2007-11-01 at 16:51 -0700, Junio C Hamano wrote:

Hi Junio,

Thanks for the review (again).  I've split the patch up in a couple of
test suite patches (a patch to accept ':' as a no-op editor, fixing
hard-coding of editor, and a test case for the commit --amend --author
case), exporting launch_editor() and a reworked version of the commit
patch that addresses your comments.

> Kristian Høgsberg <krh@redhat.com> writes:
> 
> > @@ -364,7 +365,6 @@ BUILTIN_OBJS = \
> >  	builtin-rev-parse.o \
> >  	builtin-revert.o \
> >  	builtin-rm.o \
> > -	builtin-runstatus.o \
> >  	builtin-shortlog.o \
> >  	builtin-show-branch.o \
> >  	builtin-stripspace.o \
> 
> I did not read in the commit log that runstatus is gone...

True, that should be documented.  Added in the following patch.

> > diff --git a/builtin-commit.c b/builtin-commit.c
> > new file mode 100644
> > index 0000000..56c7427
> > --- /dev/null
> > +++ b/builtin-commit.c
> > @@ -0,0 +1,608 @@
> > +/*
> > + * Builtin "git commit"
> > + *
> > + * Copyright (c) 2007 Kristian Høgsberg <krh@redhat.com>
> > + * Based on git-commit.sh by Junio C Hamano and Linus Torvalds
> > + */
> > +
> > +#include <sys/types.h>
> > +#include <sys/stat.h>
> > +#include <unistd.h>
> > +
> > +#include "cache.h"
> 
> 
> The system header files on some systems have a nasty habit of
> changing the behaviour depending on the order they are included.
> Since 85023577a8f4b540aa64aa37f6f44578c0c305a3 (simplify
> inclusion of system header files) in late 2006, we have a few
> rules for system-header inclusion to avoid the portability
> issues:
> 
>  (1) sources under compat/, platform sha-1 implementations, and
>      xdelta code are exempt from the following rules;
> 
>  (2) the first #include must be "git-compat-util.h" or one of
>      our own header file that includes it first (e.g. config.h,
>      builtin.h, pkt-line.h);
> 
>  (3) system headers that are included in "git-compat-util.h"
>      need not be included in individual C source files.
> 
>  (4) "git-compat-util.h" does not have to include subsystem
>      specific header files (e.g. expat.h).

Ah, yes, this has been pointed out to me before, sorry.  Patch updated.

> > +static void determine_author_info(struct strbuf *sb)
> > +{
> > +	char *p, *eol;
> > +	char *name = NULL, *email = NULL;
> > +
> > +	if (use_message) {
> > +		p = strstr(use_message_buffer, "\nauthor");
> > +		if (!p)
> > +			die("invalid commit: %s\n", use_message);
> > +		p++;
> > +		eol = strchr(p, '\n');
> > +		if (!eol)
> > +			die("invalid commit: %s\n", use_message);
> > +
> > +		strbuf_add(sb, p, eol + 1 - p);
> > +	} else if (force_author) {
> > +		const char *eoname = strstr(force_author, " <");
> > +		const char *eomail = strchr(force_author, '>');
> 
> Doesn't this break:
> 
>     $ git commit --amend --author='A U Thor <author@example.com>'
> 
> to fix a misattribution?

Dang, good catch.  I've fixed it by swapping the (use_message) and
(force_author) clauses and the new patch adds a test case for this.

> > +static int parse_and_validate_options(int argc, const char *argv[])
> > +{
> > ...
> > +	if (use_message) {
> > +		unsigned char sha1[20];
> > +		static char utf8[] = "UTF-8";
> > +		const char *out_enc;
> > +		char *enc, *end;
> > +		struct commit *commit;
> > +
> > +		if (get_sha1(use_message, sha1))
> > +			die("could not lookup commit %s", use_message);
> > +		commit = lookup_commit(sha1);
> > +		if (!commit || parse_commit(commit))
> > +			die("could not parse commit %s", use_message);
> > +
> > +		enc = strstr(commit->buffer, "\nencoding");
> > +		if (enc) {
> > +			end = strchr(enc + 10, '\n');
> > +			enc = xstrndup(enc + 10, end - (enc + 10));
> > +		} else {
> > +			enc = utf8;
> > +		}
> > +		out_enc = git_commit_encoding ? git_commit_encoding : utf8;
> > +
> > +		use_message_buffer =
> > +			reencode_string(commit->buffer, out_enc, enc);
> > +		if (enc != utf8)
> > +			free(enc);
> 
> A few issues.
> 
>  * When use_message is set because of --amend that wanted to
>    amend a commit message that was recorded in a corrupt
>    encoding, and iconv() in reencode_string() fails, saying "I
>    cannot convert that completely", most of the message can
>    still be salvageable.  This part should allow looser
>    reencoding if the message will be eyeballed and edited by the
>    user.

So in this case we just want to copy the old message byte for byte,
right?  That's what I have in the updated patch.

>  * We would want to avoid reencoding when !strcmp(out_enc, enc).
>    Both builtin-mailinfo.c and commit.c skip the call to the
>    function at the calling site, but it might make sense to
>    teach reencode_string() about such an optimization.

Right.  I just added the call-site optimization for builtin-commit for
now, but I would expect iconv() to be smart in case input and output
encodings are the same.

cheers,
Kristian

^ permalink raw reply

* Re: [PATCH 1/3] Implement parsing for new core.whitespace.* options.
From: Baz @ 2007-11-02 15:25 UTC (permalink / raw)
  To: David Symonds; +Cc: git, Junio C Hamano, Andreas Ericsson
In-Reply-To: <11940104611948-git-send-email-dsymonds@gmail.com>

On 02/11/2007, David Symonds <dsymonds@gmail.com> wrote:
> Each of the new core.whitespace.* options (enumerated below) can be set to one
> of:
>         * okay (default): Whitespace of this type is okay
>         * warn: Whitespace of this type should be warned about
>         * error: Whitespace of this type should raise an error
>         * autofix: Whitespace of this type should be automatically fixed

Sorry, this is a bit bikesheddy, but shouldn't that be 'fix' rather
than autofix? Otherwise you might want to rename the others
'autowarn', 'autookay' etc... since the computer does them
automatically too.

Cheers,
Baz

^ permalink raw reply

* Re: Bring parse_options to the shell
From: Pierre Habouzit @ 2007-11-02 15:14 UTC (permalink / raw)
  To: gitster, torvalds; +Cc: git
In-Reply-To: <1194016162-23599-1-git-send-email-madcoder@debian.org>

[-- Attachment #1: Type: text/plain, Size: 585 bytes --]

On Fri, Nov 02, 2007 at 03:09:18PM +0000, Pierre Habouzit wrote:
> This is also something that itches me, so here is a proposal for a
> git-parseopt helper that can be used in shell scripts as an option
> normalizer like getopt(1) does.
> 
> I migrated the discussed git-clean.sh to use it as a proof of concept.

  Needless to say, this is fetchable from
git://git.madism.org/git.git#ph/parseopt

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply

* Re: What's cooking in git.git (topics)
From: Miles Bader @ 2007-11-02 15:13 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <buofxzp18qp.fsf@dhapc248.dev.necel.com>

I previously wrote:
> Indeed... but for my personal shell scripts I like to use a construct
> like the following for parsing args:

In a little more detail, the arg-splitting case:

>        -[!-]?*)
>          # split concatenated single-letter options apart
>          FIRST="$1"; shift
>          set -- `echo $FIRST | $SED 's/-\(.\)\(.*\)/-\1 -\2/'` "$@"
>          ;;

Just strips off the first short option and stuffs it back into the list
of args to parse, so "-xyz" becomes "-x -yz".  That way short args get
split by default, but short-args with an appended value still work
correctly.

So, for instance, if in the above example, "-y" takes an argument, then
there'd be a switch case case for "-y*") which would consume the "-yz"
before it reached the arg-splitting case; if "-y" _doesn't_ take an
argument, then "-yz" would get split in turn, becoming "-y -z".

-Miles

-- 
/\ /\
(^.^)
(")")
*This is the cute kitty virus, please copy this into your sig so it can spread.

^ permalink raw reply

* Bring parse_options to the shell
From: Pierre Habouzit @ 2007-11-02 15:09 UTC (permalink / raw)
  To: gitster, torvalds; +Cc: git

This is also something that itches me, so here is a proposal for a
git-parseopt helper that can be used in shell scripts as an option
normalizer like getopt(1) does.

I migrated the discussed git-clean.sh to use it as a proof of concept.

Cheers,
-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

^ permalink raw reply

* [PATCH] Add git-parseopt(1) to bring parse-options to shell scripts.
From: Pierre Habouzit @ 2007-11-02 15:09 UTC (permalink / raw)
  To: gitster, torvalds, Junio C Hamano, Linus Torvalds; +Cc: git, Pierre Habouzit
In-Reply-To: <1194016162-23599-1-git-send-email-madcoder@debian.org>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 8709 bytes --]

---
 .gitignore                     |    1 +
 Documentation/cmd-list.perl    |    1 +
 Documentation/git-parseopt.txt |   91 +++++++++++++++++++++++++++++
 Makefile                       |    1 +
 builtin-parseopt.c             |  123 ++++++++++++++++++++++++++++++++++++++++
 builtin.h                      |    1 +
 git.c                          |    1 +
 7 files changed, 219 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/git-parseopt.txt
 create mode 100644 builtin-parseopt.c

diff --git a/.gitignore b/.gitignore
index c8c13f5..521155c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -86,6 +86,7 @@ git-pack-redundant
 git-pack-objects
 git-pack-refs
 git-parse-remote
+git-parseopt
 git-patch-id
 git-peek-remote
 git-prune
diff --git a/Documentation/cmd-list.perl b/Documentation/cmd-list.perl
index 8d21d42..c491964 100755
--- a/Documentation/cmd-list.perl
+++ b/Documentation/cmd-list.perl
@@ -147,6 +147,7 @@ git-pack-objects                        plumbingmanipulators
 git-pack-redundant                      plumbinginterrogators
 git-pack-refs                           ancillarymanipulators
 git-parse-remote                        synchelpers
+git-parseopt                            plumbingmanipulators
 git-patch-id                            purehelpers
 git-peek-remote                         purehelpers
 git-prune                               ancillarymanipulators
diff --git a/Documentation/git-parseopt.txt b/Documentation/git-parseopt.txt
new file mode 100644
index 0000000..77f5a10
--- /dev/null
+++ b/Documentation/git-parseopt.txt
@@ -0,0 +1,91 @@
+git-parseopt(1)
+============
+
+NAME
+----
+git-parseopt - Git shell script helper similar to getopt(1)
+
+
+SYNOPSIS
+--------
+'git-parseopt' [-u] [--keep-dashdash] -- [<args>...]
+
+DESCRIPTION
+-----------
+
+This is a helper for scripts to behave the same as git C commands. It merely
+breaks and normalize options so that the option parsing becomes shorter and
+easier to read. It takes the specifications of the options to undersand on its
+standard input.
+
+In case of error, it ouputs usage on the standard error stream, and exits with
+code 129. Else its ouput is suitable for evaluation with "eval" to replace
+the script arguments with the normalized form.
+
+OPTIONS
+-------
+
+--keep-dash-dash::
+	Keep the `--` in `<args>...`.
+
+\--::
+	Following arguments are the options to parse. This isn't optional.
+
+<args>...::
+	Options to parse and deal with
+
+INPUT FORMAT
+------------
+
+`git-parseopt` input format is fully text based. It has two parts, separated
+by a line that contains only `--`. The lines before (should be more than one)
+is used for the usage. The lines after describe the options.
+
+Each line of options has this format:
+
+------------
+<opt_spec><arg_spec>? SP+ help LF
+------------
+
+`<opt_spec>`::
+	its format is the short option character, then the long option name
+        separated by a comma. Both parts are not required, though at least one
+        is necessary. `h,help`, `dry-run` and `f` are all three correct
+        `<opt_spec>`.
+
+`<arg_spec>`::
+	an `<arg_spec>` tells the option parser if the option has an argument
+        (`=`), an optionnal one (`?` though its use is discouraged) or none
+        (no `<arg_spec>` in that case).
+
+The rest of the line after as many spaces up to the ending line feed is used
+as the help associated to the option.
+
+EXAMPLE
+-------
+
+------------
+OPTS_SPEC="\
+some-command [options] <args>...
+
+some-command does foo and bar !
+--
+h,help    show the help
+foo       some nifty option --foo
+bar=      some cool option --bar with an argument
+C?        option C with an optionnal argument"
+
+eval `echo "$OPTS_SPEC" | git-parseopt -- "$@" || echo exit $?`
+------------
+
+Author
+------
+Written by Pierre Habouzit <madcoder@debian.org>
+
+Documentation
+--------------
+Documentation by Pierre Habouzit.
+
+GIT
+---
+Part of the gitlink:git[7] suite
diff --git a/Makefile b/Makefile
index 042f79e..7c5df55 100644
--- a/Makefile
+++ b/Makefile
@@ -352,6 +352,7 @@ BUILTIN_OBJS = \
 	builtin-mv.o \
 	builtin-name-rev.o \
 	builtin-pack-objects.o \
+	builtin-parseopt.o \
 	builtin-prune.o \
 	builtin-prune-packed.o \
 	builtin-push.o \
diff --git a/builtin-parseopt.c b/builtin-parseopt.c
new file mode 100644
index 0000000..c032f5a
--- /dev/null
+++ b/builtin-parseopt.c
@@ -0,0 +1,123 @@
+/*
+ * Copyright © 2007 Pierre Habouzit <madcoder@debian.org>
+ */
+#include "git-compat-util.h"
+#include "cache.h"
+#include "quote.h"
+#include "parse-options.h"
+
+static int keep_dashdash = 0;
+static struct strbuf parsed = STRBUF_INIT;
+
+static struct option parseopt_opts[] = {
+	OPT_BOOLEAN(0, "keep-dashdash", &keep_dashdash,
+				"keep the `--` passed as an arg"),
+	OPT_END(),
+};
+
+static char const * const parseopt_usage[] = {
+	"git-parseopt [options] -- [<args>...]",
+	NULL
+};
+
+static int parseopt_dump(const struct option *o, const char *arg, int unset)
+{
+	if (unset)
+		strbuf_addf(&parsed, " --no-%s", o->long_name);
+	else if (o->short_name)
+		strbuf_addf(&parsed, " -%c", o->short_name);
+	else
+		strbuf_addf(&parsed, " --%s", o->long_name);
+	if (arg) {
+		strbuf_addch(&parsed, ' ');
+		sq_quote_buf(&parsed, arg);
+	}
+	return 0;
+}
+
+static const char *skipspaces(const char *s)
+{
+	while (isspace(*s))
+		s++;
+	return s;
+}
+
+int cmd_parseopt(int argc, const char **argv, const char *prefix)
+{
+	struct strbuf sb;
+	const char **usage = NULL;
+	struct option *opts = NULL;
+	int onb = 0, osz = 0, unb = 0, usz = 0;
+
+	strbuf_addstr(&parsed, "set --");
+	argc = parse_options(argc, argv, parseopt_opts, parseopt_usage,
+	                     PARSE_OPT_KEEP_DASHDASH);
+	if (argc < 1 || strcmp(argv[0], "--"))
+		usage_with_options(parseopt_usage, parseopt_opts);
+
+	strbuf_init(&sb, 0);
+	/* get the usage up to the first line with a -- on it */
+	for (;;) {
+		if (strbuf_getline(&sb, stdin, '\n') == EOF)
+			die("premature end of input");
+		ALLOC_GROW(usage, unb + 1, usz);
+		if (!strcmp("--", sb.buf)) {
+			if (unb < 1)
+				die("no usage string given before the `--' separator");
+			usage[unb] = NULL;
+			break;
+		}
+		usage[unb++] = strbuf_detach(&sb, NULL);
+	}
+
+	/* parse: (<short>|<short>,<long>|<long>)[=?]? SP+ <help> */
+	while (strbuf_getline(&sb, stdin, '\n') != EOF) {
+		const char *s;
+		struct option *o;
+
+		ALLOC_GROW(opts, onb + 1, osz);
+		memset(opts + onb, 0, sizeof(opts[onb]));
+
+		o = &opts[onb++];
+		s = strchr(sb.buf, ' ');
+		if (!s || *sb.buf == ' ')
+			die("invalid option spec");
+
+		o->type = OPTION_CALLBACK;
+		o->help = xstrdup(skipspaces(s));
+		o->callback = &parseopt_dump;
+		switch (s[-1]) {
+		case '=':
+			s--;
+			break;
+		case '?':
+			o->flags = PARSE_OPT_OPTARG;
+			s--;
+			break;
+		default:
+			o->flags = PARSE_OPT_NOARG;
+			break;
+		}
+
+		if (s - sb.buf == 1) /* short option only */
+			o->short_name = *sb.buf;
+		else if (sb.buf[1] != ',') /* long option only */
+			o->long_name = xmemdupz(sb.buf, s - sb.buf);
+		else {
+			o->short_name = *sb.buf;
+			o->long_name = xmemdupz(sb.buf + 2, s - sb.buf - 2);
+		}
+	}
+	strbuf_release(&sb);
+
+	/* put an OPT_END() */
+	ALLOC_GROW(opts, onb + 1, osz);
+	memset(opts + onb, 0, sizeof(opts[onb]));
+	argc = parse_options(argc, argv, opts, usage,
+	                     keep_dashdash ? PARSE_OPT_KEEP_DASHDASH : 0);
+
+	strbuf_addf(&parsed, " --");
+	sq_quote_argv(&parsed, argv, argc, 0);
+	puts(parsed.buf);
+	return 0;
+}
diff --git a/builtin.h b/builtin.h
index 9a6213a..b2ef7b6 100644
--- a/builtin.h
+++ b/builtin.h
@@ -55,6 +55,7 @@ extern int cmd_merge_file(int argc, const char **argv, const char *prefix);
 extern int cmd_mv(int argc, const char **argv, const char *prefix);
 extern int cmd_name_rev(int argc, const char **argv, const char *prefix);
 extern int cmd_pack_objects(int argc, const char **argv, const char *prefix);
+extern int cmd_parseopt(int argc, const char **argv, const char *prefix);
 extern int cmd_pickaxe(int argc, const char **argv, const char *prefix);
 extern int cmd_prune(int argc, const char **argv, const char *prefix);
 extern int cmd_prune_packed(int argc, const char **argv, const char *prefix);
diff --git a/git.c b/git.c
index 4e10581..89524dd 100644
--- a/git.c
+++ b/git.c
@@ -333,6 +333,7 @@ static void handle_internal_command(int argc, const char **argv)
 		{ "mv", cmd_mv, RUN_SETUP | NEED_WORK_TREE },
 		{ "name-rev", cmd_name_rev, RUN_SETUP },
 		{ "pack-objects", cmd_pack_objects, RUN_SETUP },
+		{ "parseopt", cmd_parseopt },
 		{ "pickaxe", cmd_blame, RUN_SETUP },
 		{ "prune", cmd_prune, RUN_SETUP },
 		{ "prune-packed", cmd_prune_packed, RUN_SETUP },
-- 
1.5.3.5.1458.g2aa13-dirty


^ permalink raw reply related

* [PATCH] Migrate git-clean.sh to use git-parseoptions(1)
From: Pierre Habouzit @ 2007-11-02 15:09 UTC (permalink / raw)
  To: gitster, torvalds, Junio C Hamano, Linus Torvalds; +Cc: git, Pierre Habouzit
In-Reply-To: <1194016162-23599-3-git-send-email-madcoder@debian.org>

Also minor consistency tweaks in how errors are caught.
---

    This patch is a pretty good example of the fact that git-parseopt(1)
    is not very disruptive to the general coding style thanks to
    git-sh-setup.

 git-clean.sh |   38 ++++++++++++++++++++------------------
 1 files changed, 20 insertions(+), 18 deletions(-)

diff --git a/git-clean.sh b/git-clean.sh
index 4491738..6959433 100755
--- a/git-clean.sh
+++ b/git-clean.sh
@@ -3,16 +3,21 @@
 # Copyright (c) 2005-2006 Pavel Roskin
 #
 
-USAGE="[-d] [-f] [-n] [-q] [-x | -X] [--] <paths>..."
-LONG_USAGE='Clean untracked files from the working directory
-	-d	remove directories as well
-	-f	override clean.requireForce and clean anyway
-	-n 	don'\''t remove anything, just show what would be done
-	-q	be quiet, only report errors
-	-x	remove ignored files as well
-	-X	remove only ignored files
+OPTIONS_SPEC="\
+git-clean [options] <paths>...
+
+Clean untracked files from the working directory
+
 When optional <paths>... arguments are given, the paths
-affected are further limited to those that match them.'
+affected are further limited to those that match them.
+--
+d remove directories as well
+f override clean.requireForce and clean anyway
+n don't remove anything, just show what would be done
+q be quiet, only report errors
+x remove ignored files as well
+X remove only ignored files"
+
 SUBDIRECTORY_OK=Yes
 . git-sh-setup
 require_work_tree
@@ -55,23 +60,20 @@ do
 		shift
 		break
 		;;
-	-*)
-		usage
-		;;
 	*)
-		break
+		usage # should not happen
+		;;
 	esac
 	shift
 done
 
 if [ "$disabled" = true ]; then
-	echo "clean.requireForce set and -n or -f not given; refusing to clean"
-	exit 1
+	die "clean.requireForce set and -n or -f not given; refusing to clean"
 fi
 
-case "$ignored,$ignoredonly" in
-	1,1) usage;;
-esac
+if [ "$ignored,$ignoredonly" = "1,1" ]; then
+	die "-x and -X cannot be set together"
+fi
 
 if [ -z "$ignored" ]; then
 	excl="--exclude-per-directory=.gitignore"
-- 
1.5.3.5.1458.g2aa13-dirty


^ permalink raw reply related

* [PATCH] Update git-sh-setup(1) to allow transparent use of git-parseopt(1)
From: Pierre Habouzit @ 2007-11-02 15:09 UTC (permalink / raw)
  To: gitster, torvalds, Junio C Hamano, Linus Torvalds; +Cc: git, Pierre Habouzit
In-Reply-To: <1194016162-23599-2-git-send-email-madcoder@debian.org>

If you set OPTIONS_SPEC, git-sh-setups uses git-parseopt automatically.
It also diverts usage to re-exec $0 with the -h option as parse-options.c
will catch that.

PARSEOPT_OPTS can also be used to pass options git git-parseopt(1) (like
--keep-dashdash).
---
 git-sh-setup.sh |   44 ++++++++++++++++++++++++++------------------
 1 files changed, 26 insertions(+), 18 deletions(-)

diff --git a/git-sh-setup.sh b/git-sh-setup.sh
index 86d7d4c..d7b13e0 100755
--- a/git-sh-setup.sh
+++ b/git-sh-setup.sh
@@ -16,9 +16,32 @@ die() {
 	exit 1
 }
 
-usage() {
-	die "Usage: $0 $USAGE"
-}
+if test -n "$OPTIONS_SPEC"; then
+	usage() {
+		exec "$0" -h
+	}
+
+	eval `echo "$OPTIONS_SPEC" | git parseopt $PARSEOPT_OPTS -- "$@" || echo exit $?`
+else
+	usage() {
+		die "Usage: $0 $USAGE"
+	}
+
+	if [ -z "$LONG_USAGE" ]
+	then
+		LONG_USAGE="Usage: $0 $USAGE"
+	else
+		LONG_USAGE="Usage: $0 $USAGE
+
+$LONG_USAGE"
+	fi
+
+	case "$1" in
+		-h|--h|--he|--hel|--help)
+		echo "$LONG_USAGE"
+		exit
+	esac
+fi
 
 set_reflog_action() {
 	if [ -z "${GIT_REFLOG_ACTION:+set}" ]
@@ -91,21 +114,6 @@ get_author_ident_from_commit () {
 	LANG=C LC_ALL=C sed -ne "$pick_author_script"
 }
 
-if [ -z "$LONG_USAGE" ]
-then
-	LONG_USAGE="Usage: $0 $USAGE"
-else
-	LONG_USAGE="Usage: $0 $USAGE
-
-$LONG_USAGE"
-fi
-
-case "$1" in
-	-h|--h|--he|--hel|--help)
-	echo "$LONG_USAGE"
-	exit
-esac
-
 # Make sure we are in a valid repository of a vintage we understand.
 if [ -z "$SUBDIRECTORY_OK" ]
 then
-- 
1.5.3.5.1458.g2aa13-dirty


^ permalink raw reply related

* [PATCH 2/2] git-diff: Respect core.whitespace.{space-indent,space-before-tab,trailing}.
From: David Symonds @ 2007-11-02 15:08 UTC (permalink / raw)
  To: git; +Cc: Junio C Hamano, Andreas Ericsson, David Symonds
In-Reply-To: <11940160932021-git-send-email-dsymonds@gmail.com>

Signed-off-by: David Symonds <dsymonds@gmail.com>
---
 diff.c |   24 ++++++++++++++++++------
 1 files changed, 18 insertions(+), 6 deletions(-)

diff --git a/diff.c b/diff.c
index a6aaaf7..aa86fa1 100644
--- a/diff.c
+++ b/diff.c
@@ -503,12 +503,15 @@ static void emit_line_with_ws(int nparents,
 	int tail = len;
 	int need_highlight_leading_space = 0;
 	/* The line is a newly added line.  Does it have funny leading
-	 * whitespaces?  In indent, SP should never precede a TAB.
+	 * whitespaces?  In indent, SP should never precede a TAB. In
+	 * addition, under "indent with non tab" rule, there should not
+	 * be 8 or more consecutive spaces.
 	 */
 	for (i = col0; i < len; i++) {
 		if (line[i] == '\t') {
 			last_tab_in_indent = i;
-			if (0 <= last_space_in_indent)
+			if ((ws_mode_space_before_tab != WS_OKAY) &&
+			    (0 <= last_space_in_indent))
 				need_highlight_leading_space = 1;
 		}
 		else if (line[i] == ' ')
@@ -516,6 +519,13 @@ static void emit_line_with_ws(int nparents,
 		else
 			break;
 	}
+	if ((ws_mode_space_indent != WS_OKAY) &&
+	    (0 <= last_space_in_indent) &&
+	    (last_tab_in_indent < 0) &&
+	    (8 <= (i - col0))) {
+		last_tab_in_indent = i;
+		need_highlight_leading_space = 1;
+	}
 	fputs(set, stdout);
 	fwrite(line, col0, 1, stdout);
 	fputs(reset, stdout);
@@ -540,10 +550,12 @@ static void emit_line_with_ws(int nparents,
 	tail = len - 1;
 	if (line[tail] == '\n' && i < tail)
 		tail--;
-	while (i < tail) {
-		if (!isspace(line[tail]))
-			break;
-		tail--;
+	if (ws_mode_trailing != WS_OKAY) {
+		while (i < tail) {
+			if (!isspace(line[tail]))
+				break;
+			tail--;
+		}
 	}
 	if ((i < tail && line[tail + 1] != '\n')) {
 		/* This has whitespace between tail+1..len */
-- 
1.5.3.1

^ permalink raw reply related

* [PATCH 1/2] Implement parsing for new core.whitespace.* options.
From: David Symonds @ 2007-11-02 15:08 UTC (permalink / raw)
  To: git; +Cc: Junio C Hamano, Andreas Ericsson, David Symonds

Each of the new core.whitespace.* options (enumerated below) can be set to one
of:
	* okay (default): Whitespace of this type is okay
	* warn: Whitespace of this type should be warned about
	* error: Whitespace of this type should raise an error
	* autofix: Whitespace of this type should be automatically fixed

The initial options are:
	* trailing: Whitespace at the end of a line
	* space-before-tab: SP HT sequence in the initial whitespace of a line
	* space-indent: At least 8 spaces in a row at the start of a line

Example usage:
	[core "whitespace"]
		trailing = autofix
		space-before-tab = error
		space-indent = warn

Signed-off-by: David Symonds <dsymonds@gmail.com>
---
 cache.h       |   16 ++++++++++++++++
 config.c      |   28 ++++++++++++++++++++++++++++
 environment.c |    3 +++
 3 files changed, 47 insertions(+), 0 deletions(-)

diff --git a/cache.h b/cache.h
index bfffa05..51e3982 100644
--- a/cache.h
+++ b/cache.h
@@ -602,4 +602,20 @@ extern int diff_auto_refresh_index;
 /* match-trees.c */
 void shift_tree(const unsigned char *, const unsigned char *, unsigned char *, int);
 
+/*
+ * whitespace rules.
+ * used by both diff and apply
+ */
+enum whitespace_mode {
+	WS_OKAY = 0,
+	WS_WARN,
+	WS_ERROR,
+	WS_AUTOFIX
+};
+extern enum whitespace_mode ws_mode_trailing;
+extern enum whitespace_mode ws_mode_space_before_tab;
+extern enum whitespace_mode ws_mode_space_indent;
+extern enum whitespace_mode git_config_whitespace_mode(const char *, const char *);
+
+
 #endif /* CACHE_H */
diff --git a/config.c b/config.c
index dc3148d..8e6f252 100644
--- a/config.c
+++ b/config.c
@@ -297,6 +297,19 @@ int git_config_bool(const char *name, const char *value)
 	return git_config_int(name, value) != 0;
 }
 
+enum whitespace_mode git_config_whitespace_mode(const char *name, const char *value)
+{
+	if (!strcasecmp(value, "okay"))
+		return WS_OKAY;
+	if (!strcasecmp(value, "warn"))
+		return WS_WARN;
+	if (!strcasecmp(value, "error"))
+		return WS_ERROR;
+	if (!strcasecmp(value, "autofix"))
+		return WS_AUTOFIX;
+	die("bad config value for '%s' in %s", name, config_file_name);
+}
+
 int git_default_config(const char *var, const char *value)
 {
 	/* This needs a better name */
@@ -431,6 +444,21 @@ int git_default_config(const char *var, const char *value)
 		return 0;
 	}
 
+	if (!strcmp(var, "core.whitespace.trailing")) {
+		ws_mode_trailing = git_config_whitespace_mode(var, value);
+		return 0;
+	}
+
+	if (!strcmp(var, "core.whitespace.space-before-tab")) {
+		ws_mode_space_before_tab = git_config_whitespace_mode(var, value);
+		return 0;
+	}
+
+	if (!strcmp(var, "core.whitespace.space-indent")) {
+		ws_mode_space_indent = git_config_whitespace_mode(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 b5a6c69..71502fc 100644
--- a/environment.c
+++ b/environment.c
@@ -35,6 +35,9 @@ int pager_in_use;
 int pager_use_color = 1;
 char *editor_program;
 int auto_crlf = 0;	/* 1: both ways, -1: only when adding git objects */
+enum whitespace_mode ws_mode_trailing = WS_OKAY;
+enum whitespace_mode ws_mode_space_before_tab = WS_OKAY;
+enum whitespace_mode ws_mode_space_indent = WS_OKAY;
 
 /* This is set by setup_git_dir_gently() and/or git_default_config() */
 char *git_work_tree_cfg;
-- 
1.5.3.1

^ permalink raw reply related

* Re: [PATCH 3/3] Act on WS_WARN for ws_mode_trailing.
From: David Symonds @ 2007-11-02 15:07 UTC (permalink / raw)
  To: git; +Cc: Junio C Hamano, Andreas Ericsson, David Symonds
In-Reply-To: <1194010463982-git-send-email-dsymonds@gmail.com>

On 11/3/07, David Symonds <dsymonds@gmail.com> wrote:
> Signed-off-by: David Symonds <dsymonds@gmail.com>
> ---
>  diff.c |   21 +++++++++++++--------
>  1 files changed, 13 insertions(+), 8 deletions(-)

Silly me; I somehow forgot I was only in diff.c. I'll fix and repost the series.


Dave.

^ permalink raw reply

* Re: New features in gitk
From: Linus Torvalds @ 2007-11-02 15:03 UTC (permalink / raw)
  To: Paul Mackerras; +Cc: git
In-Reply-To: <18218.63946.772767.179841@cargo.ozlabs.ibm.com>



On Fri, 2 Nov 2007, Paul Mackerras wrote:
> 
> How would that help?  That doesn't list about 2/3 of the commits at
> all.

Yeah, you'd have to do all the parent processing on your own, I guess that 
would be too slow.

> In any case, no that's not the only reason.  The main reason is that
> it (i.e. --topo-order) spits out the commits in exactly the order that
> gitk wants to display them (of which the bit about parents coming
> after all their children is a part), and thus reduces the amount of
> processing I need to do in Tcl.

The thing is, you shouldn't *care* how long it takes to get 50,000+ 
commits.

You're only visualizing ~20 commits at a time. Ignore the rest.

THAT is the number that is timing-critical. You're optimizing for the 
wrong case - the "whole history" thing doesn't matter as much as the 
"recent history" does.

So I bet from a usability standpoint, you'd be *much* better off with 
something that might take ten times as long for the whole thing, if the 
first thirty lines show up in a third of the time.

In fact, if you want to really optimize parsing and that is a big issue, 
use

	git log --left-right --parents --pretty=format:"%m %H %P %an <%ae> %aD"

which will give you a single line per commit. I bet tk is good at reading 
single lines. Don't even read anythign else - until somebody actually 
*selects* the commit, at which point you do the diff *and* the full thing.

Yes, it will make things slower over-all. And no, the above won't work for 
the "search everywhere", which means that once people start searching for 
everything, you'll be screwed, but with somethign like the above, you'll 
get the first commits immediately and can start showing them.

And yes, if they come in the wrong order, you'll have to recalculate the 
display, but I thought you had something incremental already - ie you can 
always do it for just the current window of 100 commits or whatever.

			Linus

^ permalink raw reply

* Re: [PATCH 10/10] push: teach push to be quiet if local ref is strict subset of remote ref
From: Steffen Prohaska @ 2007-11-02 14:49 UTC (permalink / raw)
  To: Andreas Ericsson; +Cc: Tom Prince, Junio C Hamano, git
In-Reply-To: <472B2B8F.1060203@op5.se>


On Nov 2, 2007, at 2:52 PM, Andreas Ericsson wrote:

>> I haven't had occasion to use git-bisect much, but I was under the
>> impression that bisect could already handle merges, or any other  
>> shaped
>> history just fine.
>
> It appears the code supports your statement. I started writing on my
> hack-around about a year ago, and the merge-handling code got in with
> 1c4fea3a40e836dcee2f16091bf7bfba96c924d0 at Wed Mar 21 22:16:24 2007.
> Perhaps I shouldn't be so paranoid about useless merges anymore then.
> Hmm. I shall have to look into it. Perhaps Junio can clarify how it
> works? The man-page was terribly silent about how git-bisect handles
> merges.

So eventually there's coming something good out of this thread,
without actually writing any code ;)

	Steffen

^ permalink raw reply

* Re: [PATCH] Make git-clone obey "--" (end argument parsing)
From: Heikki Orsila @ 2007-11-02 14:21 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

Junio C Hamano wrote:
> I do not think this breaks anything, but does it _help_
> anything in practice?
> 
> What kind of breakage does this patch fix?

It doesn't fix anything, but it is a good usability standard to obey --.
I was creating a script that would _automatically_ clone repositories of 
other users. As a little bit pedantic shell script writer I added "--" 
and noticed that git clone doesn't handle that, although it's expected 
behavior from many tools.

-- 
Heikki Orsila			Barbie's law:
heikki.orsila@iki.fi		"Math is hard, let's go shopping!"
http://www.iki.fi/shd

^ permalink raw reply

* Re: [PATCH 10/10] push: teach push to be quiet if local ref is strict subset of remote ref
From: Andreas Ericsson @ 2007-11-02 13:52 UTC (permalink / raw)
  To: Tom Prince; +Cc: Steffen Prohaska, Junio C Hamano, git
In-Reply-To: <20071102132446.GA31758@hermes.priv>

Tom Prince wrote:
> On Fri, Nov 02, 2007 at 11:03:36AM +0100, Andreas Ericsson wrote:
>> Steffen Prohaska wrote:
>>> On Nov 1, 2007, at 10:11 AM, Andreas Ericsson wrote:
>>>> It's easier to bisect. If git bisect lands you on a merge-commit,
>>>> you need to start a new bisect for each of the parents included
>>>> in the merge. Hopefully the nature of the merge gives a clue so
>>>> the user can make an educated guess as to which parent introduced
>>>> the bogus commit, but for an "evil octopus" (unusual) or if the
>>>> merge had conflicts which were resolved in a buggy way (not
>>>> exactly uncommon), it can be quite a hassle to get things right.
>>>> With a mostly linear history, this problem goes away.
>>> This is really an interesting point. I did not start to use
>>> git bisect regularly. But I certainly plan to do so in the future.
>>> Couldn't bisect learn to better cope with non-linear history?
>> Perhaps it could, but it's far from trivial. I started hacking on
>> a wrapper for git-bisect which would do just that, but gave up
>> rather quickly as the book-keeping required to remember each and
>> every parent-point tried just got out of hand, and it *still*
>> wouldn't run in full automatic. It broke down because I also
>> wanted merges on non-first-line parents to be delved into. If
>> that didn't happen, I wouldn't *know* the bisect would run fine
>> without me watching it, so then it was as useless as if I'd have
>> had to sit there the entire time anyway.
> 
> I haven't had occasion to use git-bisect much, but I was under the
> impression that bisect could already handle merges, or any other shaped
> history just fine.
> 

It appears the code supports your statement. I started writing on my
hack-around about a year ago, and the merge-handling code got in with
1c4fea3a40e836dcee2f16091bf7bfba96c924d0 at Wed Mar 21 22:16:24 2007.
Perhaps I shouldn't be so paranoid about useless merges anymore then.
Hmm. I shall have to look into it. Perhaps Junio can clarify how it
works? The man-page was terribly silent about how git-bisect handles
merges.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

^ permalink raw reply

* [PATCH 3/3] Act on WS_WARN for ws_mode_trailing.
From: David Symonds @ 2007-11-02 13:34 UTC (permalink / raw)
  To: git; +Cc: Junio C Hamano, Andreas Ericsson, David Symonds
In-Reply-To: <11940104621856-git-send-email-dsymonds@gmail.com>

Signed-off-by: David Symonds <dsymonds@gmail.com>
---
 diff.c |   21 +++++++++++++--------
 1 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/diff.c b/diff.c
index 6f9b624..ebcc0f3 100644
--- a/diff.c
+++ b/diff.c
@@ -544,17 +544,22 @@ static void emit_line_with_ws(int nparents,
 	tail = len - 1;
 	if (line[tail] == '\n' && i < tail)
 		tail--;
-	while (i < tail) {
-		if (!isspace(line[tail]))
-			break;
-		tail--;
+	if (ws_mode_trailing != WS_OKAY) {
+		while (i < tail) {
+			if (!isspace(line[tail]))
+				break;
+			tail--;
+		}
 	}
 	if ((i < tail && line[tail + 1] != '\n')) {
 		/* This has whitespace between tail+1..len */
-		fputs(set, stdout);
-		fwrite(line + i, tail - i + 1, 1, stdout);
-		fputs(reset, stdout);
-		emit_line(ws, reset, line + tail + 1, len - tail - 1);
+		if (ws_mode_trailing == WS_WARN) {
+			fputs(set, stdout);
+			fwrite(line + i, tail - i + 1, 1, stdout);
+			fputs(reset, stdout);
+			emit_line(ws, reset, line + tail + 1, len - tail - 1);
+		}
+		/* TODO: handle WS_ERROR and WS_AUTOFIX */
 	}
 	else
 		emit_line(set, reset, line + i, len - i);
-- 
1.5.3.1

^ permalink raw reply related

* [PATCH 2/3] Act on WS_WARN for ws_mode_space_before_tab.
From: David Symonds @ 2007-11-02 13:34 UTC (permalink / raw)
  To: git; +Cc: Junio C Hamano, Andreas Ericsson, David Symonds
In-Reply-To: <11940104611948-git-send-email-dsymonds@gmail.com>

Signed-off-by: David Symonds <dsymonds@gmail.com>
---
 diff.c |    8 ++++++--
 1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/diff.c b/diff.c
index a6aaaf7..6f9b624 100644
--- a/diff.c
+++ b/diff.c
@@ -508,8 +508,12 @@ static void emit_line_with_ws(int nparents,
 	for (i = col0; i < len; i++) {
 		if (line[i] == '\t') {
 			last_tab_in_indent = i;
-			if (0 <= last_space_in_indent)
-				need_highlight_leading_space = 1;
+			if ((ws_mode_space_before_tab != WS_OKAY) &&
+			    (0 <= last_space_in_indent)) {
+				if (ws_mode_space_before_tab == WS_WARN)
+					need_highlight_leading_space = 1;
+				/* TODO: handle WS_ERROR and WS_AUTOFIX */
+			}
 		}
 		else if (line[i] == ' ')
 			last_space_in_indent = i;
-- 
1.5.3.1

^ permalink raw reply related

* [PATCH 1/3] Implement parsing for new core.whitespace.* options.
From: David Symonds @ 2007-11-02 13:34 UTC (permalink / raw)
  To: git; +Cc: Junio C Hamano, Andreas Ericsson, David Symonds

Each of the new core.whitespace.* options (enumerated below) can be set to one
of:
	* okay (default): Whitespace of this type is okay
	* warn: Whitespace of this type should be warned about
	* error: Whitespace of this type should raise an error
	* autofix: Whitespace of this type should be automatically fixed

The initial options are:
	* trailing: Whitespace at the end of a line
	* space-before-tab: SP HT sequence in the initial whitespace of a line
	* space-indent: At least 8 spaces in a row at the start of a line

Example usage:
	[core "whitespace"]
		trailing = autofix
		space-before-tab = error
		space-indent = warn

Signed-off-by: David Symonds <dsymonds@gmail.com>
---
 cache.h       |   16 ++++++++++++++++
 config.c      |   28 ++++++++++++++++++++++++++++
 environment.c |    3 +++
 3 files changed, 47 insertions(+), 0 deletions(-)

diff --git a/cache.h b/cache.h
index bfffa05..51e3982 100644
--- a/cache.h
+++ b/cache.h
@@ -602,4 +602,20 @@ extern int diff_auto_refresh_index;
 /* match-trees.c */
 void shift_tree(const unsigned char *, const unsigned char *, unsigned char *, int);
 
+/*
+ * whitespace rules.
+ * used by both diff and apply
+ */
+enum whitespace_mode {
+	WS_OKAY = 0,
+	WS_WARN,
+	WS_ERROR,
+	WS_AUTOFIX
+};
+extern enum whitespace_mode ws_mode_trailing;
+extern enum whitespace_mode ws_mode_space_before_tab;
+extern enum whitespace_mode ws_mode_space_indent;
+extern enum whitespace_mode git_config_whitespace_mode(const char *, const char *);
+
+
 #endif /* CACHE_H */
diff --git a/config.c b/config.c
index dc3148d..8e6f252 100644
--- a/config.c
+++ b/config.c
@@ -297,6 +297,19 @@ int git_config_bool(const char *name, const char *value)
 	return git_config_int(name, value) != 0;
 }
 
+enum whitespace_mode git_config_whitespace_mode(const char *name, const char *value)
+{
+	if (!strcasecmp(value, "okay"))
+		return WS_OKAY;
+	if (!strcasecmp(value, "warn"))
+		return WS_WARN;
+	if (!strcasecmp(value, "error"))
+		return WS_ERROR;
+	if (!strcasecmp(value, "autofix"))
+		return WS_AUTOFIX;
+	die("bad config value for '%s' in %s", name, config_file_name);
+}
+
 int git_default_config(const char *var, const char *value)
 {
 	/* This needs a better name */
@@ -431,6 +444,21 @@ int git_default_config(const char *var, const char *value)
 		return 0;
 	}
 
+	if (!strcmp(var, "core.whitespace.trailing")) {
+		ws_mode_trailing = git_config_whitespace_mode(var, value);
+		return 0;
+	}
+
+	if (!strcmp(var, "core.whitespace.space-before-tab")) {
+		ws_mode_space_before_tab = git_config_whitespace_mode(var, value);
+		return 0;
+	}
+
+	if (!strcmp(var, "core.whitespace.space-indent")) {
+		ws_mode_space_indent = git_config_whitespace_mode(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 b5a6c69..71502fc 100644
--- a/environment.c
+++ b/environment.c
@@ -35,6 +35,9 @@ int pager_in_use;
 int pager_use_color = 1;
 char *editor_program;
 int auto_crlf = 0;	/* 1: both ways, -1: only when adding git objects */
+enum whitespace_mode ws_mode_trailing = WS_OKAY;
+enum whitespace_mode ws_mode_space_before_tab = WS_OKAY;
+enum whitespace_mode ws_mode_space_indent = WS_OKAY;
 
 /* This is set by setup_git_dir_gently() and/or git_default_config() */
 char *git_work_tree_cfg;
-- 
1.5.3.1

^ permalink raw reply related

* Re: [PATCH 1/2] War on whitespace: first, a bit of retreat.
From: David Symonds @ 2007-11-02 13:26 UTC (permalink / raw)
  To: Jakub Narebski; +Cc: git
In-Reply-To: <ee77f5c20711020553x1a329fa5g90f38d5b8c1a062e@mail.gmail.com>

On 11/2/07, David Symonds <dsymonds@gmail.com> wrote:
> On 11/2/07, Jakub Narebski <jnareb@gmail.com> wrote:
> > Nice idea, but the syntax is
> >
> > [core "whitespace"]
> >         trailing = error
> >         space-before-tab = error
> >         indent-with-space = warn
>
> Whoops, of course. My brain is a bit muddled tonight.

Okay, I've put my money where my mouth is, and coded up an equivalent
to Junio's patch from the start of this thread. I'll send it through
in a couple of minutes.


Dave.

^ permalink raw reply

* Re: [PATCH 10/10] push: teach push to be quiet if local ref is strict subset of remote ref
From: Tom Prince @ 2007-11-02 13:24 UTC (permalink / raw)
  To: Andreas Ericsson; +Cc: Steffen Prohaska, Junio C Hamano, git
In-Reply-To: <472AF5F8.40208@op5.se>

On Fri, Nov 02, 2007 at 11:03:36AM +0100, Andreas Ericsson wrote:
> Steffen Prohaska wrote:
>> On Nov 1, 2007, at 10:11 AM, Andreas Ericsson wrote:
>>>
>>> It's easier to bisect. If git bisect lands you on a merge-commit,
>>> you need to start a new bisect for each of the parents included
>>> in the merge. Hopefully the nature of the merge gives a clue so
>>> the user can make an educated guess as to which parent introduced
>>> the bogus commit, but for an "evil octopus" (unusual) or if the
>>> merge had conflicts which were resolved in a buggy way (not
>>> exactly uncommon), it can be quite a hassle to get things right.
>>> With a mostly linear history, this problem goes away.
>> This is really an interesting point. I did not start to use
>> git bisect regularly. But I certainly plan to do so in the future.
>> Couldn't bisect learn to better cope with non-linear history?
>
> Perhaps it could, but it's far from trivial. I started hacking on
> a wrapper for git-bisect which would do just that, but gave up
> rather quickly as the book-keeping required to remember each and
> every parent-point tried just got out of hand, and it *still*
> wouldn't run in full automatic. It broke down because I also
> wanted merges on non-first-line parents to be delved into. If
> that didn't happen, I wouldn't *know* the bisect would run fine
> without me watching it, so then it was as useless as if I'd have
> had to sit there the entire time anyway.

I haven't had occasion to use git-bisect much, but I was under the
impression that bisect could already handle merges, or any other shaped
history just fine.

If you test a merge and it is bad, git (eventually) picks a commit on one of
the branches. If that commit is good, then the merge-base is good, so that the
bug lies on some other branch. If that commit is bad, then the bug is on some
ancestor of the branch. Thus, no need for special book keeping.

  Tom

^ permalink raw reply

* Re: [PATCH 10/10] push: teach push to be quiet if local ref is strict subset of remote ref
From: Wincent Colaiuta @ 2007-11-02 13:11 UTC (permalink / raw)
  To: Steffen Prohaska; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <A862668C-7895-489A-B13B-597084CAEE11@zib.de>

El 2/11/2007, a las 13:48, Steffen Prohaska escribió:

> On Nov 2, 2007, at 1:14 PM, Johannes Schindelin wrote:
>
>> On Fri, 2 Nov 2007, Wincent Colaiuta wrote:
>>
>>> Of course, it's too late too change now, but it would be nice if the
>>> mirror of "fetch" were "send". (I know it's been commented in the  
>>> past
>>> that the fact that "push" and "pull" aren't mirror operations has
>>> surprised quite a few people.)
>>
>> Could you please just do
>>
>> 	git config --global alias.send push
>>
>> and be done with it?

(snip)

> The comment was about how to avoid surprises for people that
> are new to git, not how to let long-time users have an alias
> for push.

Exactly. I was talking about the *initial* surprise for new users, not  
for people who already know the difference between push, pull and  
fetch (99% of people reading this list already, myself included).

> The _only_ real solution I see right now, is to stop the
> discussion and leave "git push" as is. I strongly believe that
> the git community in its majority will refuse to rename push;
> though I have no evidence for this.

As I said above, "Of course, it's too late to change now"... I don't  
think it will be renamed either.

Cheers,
Wincent

^ permalink raw reply

* Re: [PATCH 1/2] War on whitespace: first, a bit of retreat.
From: David Symonds @ 2007-11-02 12:53 UTC (permalink / raw)
  To: Jakub Narebski; +Cc: git
In-Reply-To: <fgf4qu$e8c$1@ger.gmane.org>

On 11/2/07, Jakub Narebski <jnareb@gmail.com> wrote:
> Nice idea, but the syntax is
>
> [core "whitespace"]
>         trailing = error
>         space-before-tab = error
>         indent-with-space = warn

Whoops, of course. My brain is a bit muddled tonight.



Dave.

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox