[PATCH] Make "git reset" a builtin. (incomplete)

[PATCH] Make "git reset" a builtin. (incomplete)

[Carlos Rica]

This is the first version of the program "builtin-reset.c",
intended for replacing the script "git-reset.sh".

The --mixed option with -- paths is not implemented yet.

The tests I made for it are not finished so they are not included,
but it seems to pass the rest of the test suite.

Signed-off-by: Carlos Rica <jasampler@gmail.com>
---
 Makefile                                      |    3 +-
 builtin-reset.c                               |  216 +++++++++++++++++++++++++
 builtin.h                                     |    1 +
 git-reset.sh => contrib/examples/git-reset.sh |    0
 git.c                                         |    1 +
 5 files changed, 220 insertions(+), 1 deletions(-)
 create mode 100644 builtin-reset.c
 rename git-reset.sh => contrib/examples/git-reset.sh (100%)

diff --git a/Makefile b/Makefile
index 4eb4637..4f70993 100644
--- a/Makefile
+++ b/Makefile
@@ -206,7 +206,7 @@ SCRIPT_SH = \
 	git-ls-remote.sh \
 	git-merge-one-file.sh git-mergetool.sh git-parse-remote.sh \
 	git-pull.sh git-rebase.sh git-rebase--interactive.sh \
-	git-repack.sh git-request-pull.sh git-reset.sh \
+	git-repack.sh git-request-pull.sh \
 	git-sh-setup.sh \
 	git-am.sh \
 	git-merge.sh git-merge-stupid.sh git-merge-octopus.sh \
@@ -353,6 +353,7 @@ BUILTIN_OBJS = \
 	builtin-reflog.o \
 	builtin-config.o \
 	builtin-rerere.o \
+	builtin-reset.o \
 	builtin-rev-list.o \
 	builtin-rev-parse.o \
 	builtin-revert.o \
diff --git a/builtin-reset.c b/builtin-reset.c
new file mode 100644
index 0000000..66aac45
--- /dev/null
+++ b/builtin-reset.c
@@ -0,0 +1,216 @@
+/*
+ * "git reset" builtin command
+ *
+ * Copyright (c) 2007 Carlos Rica
+ *
+ * Based on git-reset.sh, which is
+ *
+ * Copyright (c) 2005, 2006 Linus Torvalds and Junio C Hamano
+ */
+#include "cache.h"
+#include "tag.h"
+#include "object.h"
+#include "run-command.h"
+#include "refs.h"
+
+static const char builtin_reset_usage[] =
+"git-reset [--mixed | --soft | --hard]  [<commit-ish>] [ [--] <paths>...]";
+
+static char *args_to_str(const char **argv)
+{
+	char *buf = NULL;
+	unsigned long len, space = 0, nr = 0;
+
+	for (; *argv; argv++) {
+		len = strlen(*argv);
+		ALLOC_GROW(buf, nr + 1 + len, space);
+		if (nr)
+			buf[nr++] = ' ';
+		memcpy(buf + nr, *argv, len);
+		nr += len;
+	}
+	ALLOC_GROW(buf, nr + 1, space);
+	buf[nr] = '\0';
+
+	return buf;
+}
+
+static inline int is_merge(void)
+{
+	return !access(git_path("MERGE_HEAD"), F_OK);
+}
+
+static int unmerged_files(void)
+{
+	char b;
+	ssize_t len;
+	struct child_process cmd;
+	const char *argv_ls_files[] = {"ls-files", "--unmerged", NULL};
+
+	memset(&cmd, 0, sizeof(cmd));
+	cmd.argv = argv_ls_files;
+	cmd.git_cmd = 1;
+	cmd.out = -1;
+
+	if (start_command(&cmd))
+		die("Could not run sub-command: git ls-files");
+
+	len = xread(cmd.out, &b, 1);
+	if (len < 0)
+		die("Could not read output from git ls-files: %s",
+						strerror(errno));
+	finish_command(&cmd);
+
+	return len;
+}
+
+static int reset_index_file(const unsigned char *sha1, int is_hard_reset)
+{
+	int i = 0;
+	const char *args[6];
+
+	args[i++] = "read-tree";
+	args[i++] = "-v";
+	args[i++] = "--reset";
+	if (is_hard_reset)
+		args[i++] = "-u";
+	args[i++] = sha1_to_hex(sha1);
+	args[i] = NULL;
+
+	return run_command_v_opt(args, RUN_GIT_CMD);
+}
+
+static int print_line_current_head(void)
+{
+	const char *argv_log[] = {"log", "--max-count=1", "--pretty=oneline",
+					"--abbrev-commit", "HEAD", NULL};
+	printf("HEAD is now at ");
+	unsetenv("GIT_PAGER");
+	return run_command_v_opt(argv_log, RUN_GIT_CMD);
+}
+
+static int update_index_refresh(void)
+{
+	const char *argv_update_index[] = {"update-index", "--refresh", NULL};
+	return run_command_v_opt(argv_update_index, RUN_GIT_CMD);
+}
+
+static int update_ref(const char *action, const char *refname,
+		const unsigned char *sha1, const unsigned char *oldval)
+{
+	static struct ref_lock *lock;
+
+	lock = lock_any_ref_for_update(refname, oldval, 0);
+	if (!lock)
+		return error("Cannot lock the ref: '%s'.", refname);
+	if (write_ref_sha1(lock, sha1, action) < 0)
+		return error("Cannot update the ref: '%s'.", refname);
+	return 0;
+}
+
+enum reset_type { MIXED, SOFT, HARD };
+
+int cmd_reset(int argc, const char **argv, const char *prefix)
+{
+	int i = 1, reset_type = MIXED, update_ref_status = 0;
+	const char *rev = "HEAD";
+	unsigned char sha1[20], *orig = NULL, sha1_orig[20],
+				*old_orig = NULL, sha1_old_orig[20];
+	struct object *obj;
+	char *reflog_action;
+
+	git_config(git_default_config);
+
+	reflog_action = args_to_str(argv);
+	setenv("GIT_REFLOG_ACTION", reflog_action, 0);
+
+	if (i < argc) {
+		if (!strcmp(argv[i], "--mixed")) {
+			reset_type = MIXED;
+			i++;
+		}
+		else if (!strcmp(argv[i], "--soft")) {
+			reset_type = SOFT;
+			i++;
+		}
+		else if (!strcmp(argv[i], "--hard")) {
+			reset_type = HARD;
+			i++;
+		}
+	}
+
+	if (i < argc && argv[i][0] != '-')
+		rev = argv[i++];
+
+	if (get_sha1(rev, sha1))
+		die("Failed to resolve '%s' as a valid ref.", rev);
+
+	obj = deref_tag(parse_object(sha1), sha1_to_hex(sha1), 40);
+	if (!obj)
+		die("Could not parse object '%s'.", rev);
+	memcpy(sha1, obj->sha1, sizeof(sha1));
+
+	if (i < argc && argv[i][0] == '-') {
+		if (strcmp(argv[i], "--"))
+			usage(builtin_reset_usage);
+		else
+			i++;
+	}
+
+	/* git reset --mixed tree [--] paths... can be used to
+	 * load chosen paths from the tree into the index without
+	 * affecting the working tree nor HEAD. */
+	if (i < argc) {
+		if (reset_type != MIXED)
+			die("Cannot do partial %s reset.", argv[1]);
+		/*
+		git diff-index --cached $rev -- "$@" |
+		sed -e 's/^:\([0-7][0-7]*\) [0-7][0-7]* \([0-9a-f][0-9a-f]*\) [0-9a-f][0-9a-f]* [A-Z]	\(.*\)$/\1 \2	\3/' |
+		git update-index --add --remove --index-info || exit
+		*/
+		update_index_refresh();
+		return 0;
+	}
+
+	/* Soft reset does not touch the index file nor the working tree
+	 * at all, but requires them in a good order.  Other resets reset
+	 * the index file to the tree object we are switching to. */
+	if (reset_type == SOFT) {
+		if (is_merge() || unmerged_files())
+			die("Cannot do a soft reset in the middle of a merge.");
+	}
+	else if (reset_index_file(sha1, (reset_type == HARD)))
+		die("Could not reset index file to revision '%s'.", rev);
+
+	/* Any resets update HEAD to the head being switched to,
+	 * saving the previous head in ORIG_HEAD before. */
+	if (!get_sha1("ORIG_HEAD", sha1_old_orig))
+		old_orig = sha1_old_orig;
+	if (!get_sha1("HEAD", sha1_orig)) {
+		orig = sha1_orig;
+		update_ref("updating ORIG_HEAD", "ORIG_HEAD", orig, old_orig);
+	}
+	else if (old_orig)
+		delete_ref("ORIG_HEAD", old_orig);
+	update_ref_status = update_ref(reflog_action, "HEAD", sha1, orig);
+	free(reflog_action);
+
+	switch (reset_type) {
+	case HARD:
+		if (!update_ref_status)
+			print_line_current_head();
+		break;
+	case SOFT: /* Nothing else to do. */
+		break;
+	case MIXED: /* Report what has not been updated. */
+		update_index_refresh();
+		break;
+	}
+
+	unlink(git_path("MERGE_HEAD"));
+	unlink(git_path("rr-cache/MERGE_RR"));
+	unlink(git_path("MERGE_MSG"));
+	unlink(git_path("SQUASH_MSG"));
+
+	return update_ref_status;
+}
diff --git a/builtin.h b/builtin.h
index bb72000..03ee7bf 100644
--- a/builtin.h
+++ b/builtin.h
@@ -60,6 +60,7 @@ extern int cmd_read_tree(int argc, const char **argv, const char *prefix);
 extern int cmd_reflog(int argc, const char **argv, const char *prefix);
 extern int cmd_config(int argc, const char **argv, const char *prefix);
 extern int cmd_rerere(int argc, const char **argv, const char *prefix);
+extern int cmd_reset(int argc, const char **argv, const char *prefix);
 extern int cmd_rev_list(int argc, const char **argv, const char *prefix);
 extern int cmd_rev_parse(int argc, const char **argv, const char *prefix);
 extern int cmd_revert(int argc, const char **argv, const char *prefix);
diff --git a/git-reset.sh b/contrib/examples/git-reset.sh
similarity index 100%
rename from git-reset.sh
rename to contrib/examples/git-reset.sh
diff --git a/git.c b/git.c
index cab0e72..26720f4 100644
--- a/git.c
+++ b/git.c
@@ -359,6 +359,7 @@ static void handle_internal_command(int argc, const char **argv)
 		{ "reflog", cmd_reflog, RUN_SETUP },
 		{ "repo-config", cmd_config },
 		{ "rerere", cmd_rerere, RUN_SETUP },
+		{ "reset", cmd_reset, RUN_SETUP },
 		{ "rev-list", cmd_rev_list, RUN_SETUP },
 		{ "rev-parse", cmd_rev_parse, RUN_SETUP },
 		{ "revert", cmd_revert, RUN_SETUP | NEED_WORK_TREE },
-- 
1.5.0

Re: [PATCH] Make "git reset" a builtin. (incomplete)

[David Kastrup]

Carlos Rica <jasampler@gmail.com> writes:

> This is the first version of the program "builtin-reset.c",
> intended for replacing the script "git-reset.sh".
>
> The --mixed option with -- paths is not implemented yet.
>
> The tests I made for it are not finished so they are not included,
> but it seems to pass the rest of the test suite.

Could you be so kind as to give a one-sentence summary what the
benefits over using a shell script would be?  I think this work has
started before I joined the list, and I'd be interested in the
motivation for it.  In general, I find shell scripts more pleasant for
hacking on than C code, and there is no long-term plan to replace all
of them, is there?  So unless there is some issue that can't be
addressed reliably or efficiently by reverting to other commands for
everything involving bulk processing, I am not really happy to see
shell scripts replaced.

Thanks,

-- 
David Kastrup

Re: [PATCH] Make "git reset" a builtin. (incomplete)

[Andreas Ericsson]

David Kastrup wrote:
> Carlos Rica <jasampler@gmail.com> writes:
> 
>> This is the first version of the program "builtin-reset.c",
>> intended for replacing the script "git-reset.sh".
>>
>> The --mixed option with -- paths is not implemented yet.
>>
>> The tests I made for it are not finished so they are not included,
>> but it seems to pass the rest of the test suite.
> 
> Could you be so kind as to give a one-sentence summary what the
> benefits over using a shell script would be?

One word: Portability.

There's a plethora of various shell syntaxes. Discerning what's correct
shell and what's a bash'ism that may or may not be posixly correct (but
perhaps not supported on a multitude of out-of-the-box solaris system)
has so far taken almost as much time as convincing newcomers to git that
there really is no point in tracking file renames explicitly.

Otoh, the list of large and renowned projects that have shunned git for
its weak windows support grows longer, meaning we potentially lose
competent programmers simply because they're forced to use something
else.


>  I think this work has
> started before I joined the list, and I'd be interested in the
> motivation for it.  In general, I find shell scripts more pleasant for
> hacking on than C code, and there is no long-term plan to replace all
> of them, is there?

There is, but nobody is putting a full-time effort into it, so the change
is gradual and happens one program at a time whenever someone sends in a
well-written C-program to replace a shell-script. Normally the C-program
has to either show tremendous speed improvements or retain all functionality
of the shell-script in order to be accepted.

>  So unless there is some issue that can't be
> addressed reliably or efficiently by reverting to other commands for
> everything involving bulk processing, I am not really happy to see
> shell scripts replaced.
> 

It will happen, sooner or later. We may not like MS or their products, but
sooner or later we'll have to cater to their users or face the problem of
all the competent programmers helping out on some other SCM, because that
other SCM works everywhere, while git doesn't.

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

Re: [PATCH] Make "git reset" a builtin. (incomplete)

[Matthieu Moy]

David Kastrup <dak@gnu.org> writes:

> Could you be so kind as to give a one-sentence summary what the
> benefits over using a shell script would be?  I think this work has
> started before I joined the list, and I'd be interested in the
> motivation for it.  In general, I find shell scripts more pleasant for
> hacking on than C code, and there is no long-term plan to replace all
> of them, is there?

That's a Google SoC project :

http://git.or.cz/gitwiki/SoC2007Projects?highlight=%28soc%29#head-2b49ddde32756b52fde3b9d9ab01e1bff6aa687c

-- 
Matthieu

Re: [PATCH] Make "git reset" a builtin. (incomplete)

[Andy Parkins]

On Wednesday 2007 August 22, David Kastrup wrote:

> Could you be so kind as to give a one-sentence summary what the
> benefits over using a shell script would be?  I think this work has
> started before I joined the list, and I'd be interested in the
> motivation for it.  In general, I find shell scripts more pleasant for
> hacking on than C code, and there is no long-term plan to replace all

C is far more portable than shell.  I would imagine the primary target is 
Windows, where the shell code makes life hard for the poor mingw folk.  I 
think in general it's a good thing to reduce the number of dependencies in a 
project.

One could also argue that C is faster, but that's probably irrelevant for the 
remaining shell scripts in git.

As to shell being easier than C: I'd say that's a matter of opinion - you 
might find it harder to hack on C, someone else will find it easier.  It was 
always thus.



Andy
-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com

Re: [PATCH] Make "git reset" a builtin. (incomplete)

[David Kastrup]

Andreas Ericsson <ae@op5.se> writes:

> David Kastrup wrote:
>> Carlos Rica <jasampler@gmail.com> writes:
>>
>>> This is the first version of the program "builtin-reset.c",
>>> intended for replacing the script "git-reset.sh".
>>>
>>> The --mixed option with -- paths is not implemented yet.
>>>
>>> The tests I made for it are not finished so they are not included,
>>> but it seems to pass the rest of the test suite.
>>
>> Could you be so kind as to give a one-sentence summary what the
>> benefits over using a shell script would be?
>
> One word: Portability.
>
> There's a plethora of various shell syntaxes. Discerning what's
> correct shell and what's a bash'ism that may or may not be posixly
> correct (but perhaps not supported on a multitude of out-of-the-box
> solaris system) has so far taken almost as much time as convincing
> newcomers to git that there really is no point in tracking file
> renames explicitly.
>
> Otoh, the list of large and renowned projects that have shunned git
> for its weak windows support grows longer, meaning we potentially
> lose competent programmers simply because they're forced to use
> something else.

The problem I see is that C sucks really really bad as a scripting
language, and tying together plumbing functionality into porcelain is
one of the most powerful, flexible and hack-friendly features of git.
Deprecating scripts is making git more opaque.

Personally, I would prefer an approach of using an embedded script
interpreter: then language incompatibilities become a non-issue.
git-busybox sounded like a great idea for portability.

When the Unix toolchain is not the main focus, a very interesting
language for such projects is Lua <URL:http://www.lua.org>.  It is
(among hundreds of other applications) used as a scripting,
programming and extension engine for LuaTeX (now in beta), the
designated PDFTeX successor.  It is very portable, efficient and
minimalistic, while being quite expressive at the same time.

>>  So unless there is some issue that can't be addressed reliably or
>> efficiently by reverting to other commands for everything involving
>> bulk processing, I am not really happy to see shell scripts
>> replaced.
>>
>
> It will happen, sooner or later. We may not like MS or their
> products, but sooner or later we'll have to cater to their users or
> face the problem of all the competent programmers helping out on
> some other SCM, because that other SCM works everywhere, while git
> doesn't.

I am just not sure that C is the ultimate solution since it makes
things harder to hack on.

I'd prefer to see some scripting abilities retained: many of the
recent advances in the porcelain (like rebase -i) would likely not
have happened if one would had to write them in C in the first place.

If the scripting engine of choice for cobbling together prototypes
remains the Unix toolchain outside of git proper, then Windows users
will _always_ remain second class citizens since they will get to work
with and on new porcelain much later than the rest of the world:
namely when somebody bothers porting his new favorite tool for them to
C.

-- 
David Kastrup

Re: [PATCH] Make "git reset" a builtin. (incomplete)

[Mike Hommey]

On Wed, Aug 22, 2007 at 04:29:43PM +0200, David Kastrup <dak@gnu.org> wrote:
> The problem I see is that C sucks really really bad as a scripting
> language, and tying together plumbing functionality into porcelain is
> one of the most powerful, flexible and hack-friendly features of git.
> Deprecating scripts is making git more opaque.
(...)

Having tools being implemented in C rather than shell won't remove the
tools for you to be able to write scripts and do your plumbing. It might
remove some examples for you to write your plumbing, though.

So here you are, all you really need is examples of how to do some plumbing.

Mike

Re: [PATCH] Make "git reset" a builtin. (incomplete)

[Johannes Sixt]

Carlos Rica wrote:
> 
> This is the first version of the program "builtin-reset.c",
> intended for replacing the script "git-reset.sh".

You are my hero, Carlos!

git-reset.sh is the prominent script that does not grok "master@{1}" on
MinGW (because of mysterious bogus quoting of the braces). This should
be solved with this conversion to C code.

-- Hannes

Re: [PATCH] Make "git reset" a builtin. (incomplete)

[Chris Shoemaker]

On Wed, Aug 22, 2007 at 04:49:43PM +0200, Mike Hommey wrote:
> On Wed, Aug 22, 2007 at 04:29:43PM +0200, David Kastrup <dak@gnu.org> wrote:
> > The problem I see is that C sucks really really bad as a scripting
> > language, and tying together plumbing functionality into porcelain is
> > one of the most powerful, flexible and hack-friendly features of git.
> > Deprecating scripts is making git more opaque.
> (...)
> 
> Having tools being implemented in C rather than shell won't remove the
> tools for you to be able to write scripts and do your plumbing. It might
> remove some examples for you to write your plumbing, though.

Actually, the scripts are being moved into contrib/examples for this
reason, so, they're still available.

-chris

Re: [PATCH] Make "git reset" a builtin. (incomplete)

[David Kastrup]

Chris Shoemaker <c.shoemaker@cox.net> writes:

> On Wed, Aug 22, 2007 at 04:49:43PM +0200, Mike Hommey wrote:
>> On Wed, Aug 22, 2007 at 04:29:43PM +0200, David Kastrup <dak@gnu.org> wrote:
>> > The problem I see is that C sucks really really bad as a scripting
>> > language, and tying together plumbing functionality into porcelain is
>> > one of the most powerful, flexible and hack-friendly features of git.
>> > Deprecating scripts is making git more opaque.
>> (...)
>> 
>> Having tools being implemented in C rather than shell won't remove the
>> tools for you to be able to write scripts and do your plumbing. It might
>> remove some examples for you to write your plumbing, though.
>
> Actually, the scripts are being moved into contrib/examples for this
> reason, so, they're still available.

But they will eventually fall prey to bitrot and stop corresponding to
the actual documented commands.

-- 
David Kastrup

Re: [PATCH] Make "git reset" a builtin. (incomplete)

[Nicolas Pitre]

On Wed, 22 Aug 2007, David Kastrup wrote:

> The problem I see is that C sucks really really bad as a scripting
> language, and tying together plumbing functionality into porcelain is
> one of the most powerful, flexible and hack-friendly features of git.
> Deprecating scripts is making git more opaque.

I tend to agree with you.

> Personally, I would prefer an approach of using an embedded script
> interpreter: then language incompatibilities become a non-issue.
> git-busybox sounded like a great idea for portability.

Indeed.  And while the conversion of some script into C was the right 
thing to do performance wise, many other scripts are hardly performance 
critical.

There was a first attempt at a very specialized scripting language, even 
with a prototype a while ago from Linus: 

	http://marc.info/?l=git&m=114076345427378&w=2

but the idea never took off.

> I am just not sure that C is the ultimate solution since it makes
> things harder to hack on.
> 
> I'd prefer to see some scripting abilities retained: many of the
> recent advances in the porcelain (like rebase -i) would likely not
> have happened if one would had to write them in C in the first place.

The current scripting ability will never go away.  But it is less and 
less used meaning that scripting could never be a dependable ability on 
all platforms if the current trend continues.

> If the scripting engine of choice for cobbling together prototypes
> remains the Unix toolchain outside of git proper, then Windows users
> will _always_ remain second class citizens since they will get to work
> with and on new porcelain much later than the rest of the world:
> namely when somebody bothers porting his new favorite tool for them to
> C.

Right.


Nicolas

Re: [PATCH] Make "git reset" a builtin. (incomplete)

[Alex Riesen]

Carlos Rica, Wed, Aug 22, 2007 14:48:16 +0200:
> This is the first version of the program "builtin-reset.c",
> intended for replacing the script "git-reset.sh".

Very nice code :)

> +	obj = deref_tag(parse_object(sha1), sha1_to_hex(sha1), 40);
> +	if (!obj)
> +		die("Could not parse object '%s'.", rev);
> +	memcpy(sha1, obj->sha1, sizeof(sha1));

You might consider using hashcpy

Re: [PATCH] Make "git reset" a builtin. (incomplete)

[Johannes Schindelin]

Hi,

On Wed, 22 Aug 2007, Nicolas Pitre wrote:

> On Wed, 22 Aug 2007, David Kastrup wrote:
> 
> > Personally, I would prefer an approach of using an embedded script 
> > interpreter: then language incompatibilities become a non-issue. 
> > git-busybox sounded like a great idea for portability.
> 
> Indeed.  And while the conversion of some script into C was the right 
> thing to do performance wise, many other scripts are hardly performance 
> critical.

What is wrong with going from shell to C?  C _is_ portable.  Instead of 
relying on _yet_ another scripting language, introducing _yet_ another 
language that people have to learn to hack git, introducing _yet_ another 
place for bugs to hide, why not just admit that shell is nice for 
_prototyping_?

Why do we have to to have the same discussion over and over and over 
again?

> The current scripting ability will never go away.  But it is less and 
> less used meaning that scripting could never be a dependable ability on 
> all platforms if the current trend continues.

That is just not true.  The regular git hackers, you included, will always 
use scripts (or alias versions of them), so there is not much chance that 
scriptability will be hurt by builtinification.

> > If the scripting engine of choice for cobbling together prototypes
> > remains the Unix toolchain outside of git proper, then Windows users
> > will _always_ remain second class citizens since they will get to work
> > with and on new porcelain much later than the rest of the world:
> > namely when somebody bothers porting his new favorite tool for them to
> > C.
> 
> Right.

And not making the scripts builtins helps Windows users how, exactly?

Ciao,
Dscho

Re: [PATCH] Make "git reset" a builtin. (incomplete)

[David Kastrup]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> On Wed, 22 Aug 2007, Nicolas Pitre wrote:
>
>> On Wed, 22 Aug 2007, David Kastrup wrote:
>> 
>> > Personally, I would prefer an approach of using an embedded script 
>> > interpreter: then language incompatibilities become a non-issue. 
>> > git-busybox sounded like a great idea for portability.
>> 
>> Indeed.  And while the conversion of some script into C was the right 
>> thing to do performance wise, many other scripts are hardly performance 
>> critical.
>
> What is wrong with going from shell to C?

That it is not a script language where cause and effect of tying
simple functionality together is apparent, and easy to do.

> C _is_ portable.  Instead of relying on _yet_ another scripting
> language, introducing _yet_ another language that people have to
> learn to hack git, introducing _yet_ another place for bugs to hide,
> why not just admit that shell is nice for _prototyping_?

git-busybox would not be "yet another scripting language" that would
need an introduction.

Emacs did not become one of the most used editors by chance: it is
exactly _because_ its scripting language Emacs Lisp is good for
prototyping, and the prototypes can be _retained_ and improved.

Once development is dead, the need for prototyping stops.

>> > If the scripting engine of choice for cobbling together
>> > prototypes remains the Unix toolchain outside of git proper, then
>> > Windows users will _always_ remain second class citizens since
>> > they will get to work with and on new porcelain much later than
>> > the rest of the world: namely when somebody bothers porting his
>> > new favorite tool for them to C.
>> 
>> Right.
>
> And not making the scripts builtins helps Windows users how,
> exactly?

Red herring.  The proposal was not to do nothing, but rather give git
a dedicated scripting language internal to it.  Two suggestions of
mine with different advantages were git-busybox and Lua.  A third one
was once proposed by Linus with some code example: starting a
scripting language from scratch.  So obviously, the need for something
like that is recognized, and not having to start from zero for that
might be an advantage if a good, workable language can be found.

You could better address my points if you did not keep me in your
killfile.

-- 
David Kastrup

Re: [PATCH] Make "git reset" a builtin. (incomplete)

[Nicolas Pitre]

On Wed, 22 Aug 2007, Johannes Schindelin wrote:

> Hi,
> 
> On Wed, 22 Aug 2007, Nicolas Pitre wrote:
> 
> > On Wed, 22 Aug 2007, David Kastrup wrote:
> > 
> > > Personally, I would prefer an approach of using an embedded script 
> > > interpreter: then language incompatibilities become a non-issue. 
> > > git-busybox sounded like a great idea for portability.
> > 
> > Indeed.  And while the conversion of some script into C was the right 
> > thing to do performance wise, many other scripts are hardly performance 
> > critical.
> 
> What is wrong with going from shell to C?  C _is_ portable.  Instead of 
> relying on _yet_ another scripting language, introducing _yet_ another 
> language that people have to learn to hack git, introducing _yet_ another 
> place for bugs to hide, why not just admit that shell is nice for 
> _prototyping_?

This is a narrow view of the programming world that I don't share.

C is portable indeed, which is one of its upsides.  But it has many 
downsides too for many _users_, that as a Git _developer_ you apparently 
conveniently ignore.

> Why do we have to to have the same discussion over and over and over 
> again?

Because, as shown by the recurring nature of this discussion, using C for 
everything is evidently not the optimal solution.


Nicolas

Re: [PATCH] Make "git reset" a builtin. (incomplete)

[Linus Torvalds]

On Wed, 22 Aug 2007, David Kastrup wrote:
> >
> > What is wrong with going from shell to C?
> 
> That it is not a script language where cause and effect of tying
> simple functionality together is apparent, and easy to do.

Why does it have to be a scripting language?

"git reset" is a command, not a scripting language. We can still script 
git as much as we want, but the fewer dependencies we have on anything 
external, the better off we are.

We ended up writing our own versions (or merging other peoples code) for 
things like appying patches, generating diffs, three-way merging etc, 
because not having external dependencies is *so* much more maintainable 
and portable that it's not even funny.

Was it "simpler" to just depend on external things like GNU patch and 
diff? Yes. But it was strictly much worse to maintain, and it also limited 
us - thanks to integrating our own diff/merge/patch, we've been able to 
make them suit us much better.

I'd love for every single shell-script in git core to be written in C, so 
that we can drop the dependency on shell *entirely*.

I also dispute your "easy to do". Quite often, shell (or any scripting 
language) is actually much *more* complicated than C. Yes, the C code may 
be more lines (in this case, the shell script is 106 lines, and the C code 
was 216 lines), but from a maintenance standpoint, C has had *much* fewer 
problems than the shell script stuff has ever had!

So scripting languages are often good for *prototyping*, and a lot of 
people like scripting languages for that reason. But once something is 
already prototyped, and if somebody then rewrites it in C, all the 
advantages of a scripting language have already disappeared!

I don't understand why people consider scripting languages (whether shell, 
perl, or anything else) "better" than C if there is an alternative. Once 
the C work has been done (and if you require C _anyway_ for other reasons, 
like git does), doing it in C is simply superior.

> Red herring.  The proposal was not to do nothing, but rather give git
> a dedicated scripting language internal to it.  Two suggestions of
> mine with different advantages were git-busybox and Lua.

Having tried to do internal scripting languages, I can say that it's just 
easier to do it in C once you get past the hump of getting it written in C 
in the first place.

The "impedance match" problem between core code (which is inevtiably in C) 
and the interfaces the scripting language offers is invariably a nasty 
issue.

So yes, we could just make the shell/etc from busybox _be_ the scripting 
language, but the fact is, that is *more* C code than just making the 
commands C code in the first place, and while a lot of the effort is 
already done for us, "busybox under windows" is actually likely to be more 
of a maintenance problem than "native git commands under windows" are.

So if we have the choice, and somebody has written a git command in native 
C code, I think we should *always* take it. Just because it means that 
_eventually_ we can drop shell entirely, even if it would be a git 
internal busybox shell.

And LUA may be a nicer scriping thing than most, but you still end up 
having the impedance match, and quite frankly, I think we'd have much 
fewer problems with just rewriting all the remaining shell scripts in C, 
than to integrate LUA and write them in that.

(Quite frankly, havign looked at monotone development, I can say that we 
should avoid LUA and things like Boost like the plague. If it's not a 
library that has been around for ten years or more, it's not worth the 
headache).

			Linus

Re: [PATCH] Make "git reset" a builtin. (incomplete)

[David Kastrup]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> So scripting languages are often good for *prototyping*, and a lot
> of people like scripting languages for that reason. But once
> something is already prototyped, and if somebody then rewrites it in
> C, all the advantages of a scripting language have already
> disappeared!
>
> I don't understand why people consider scripting languages (whether
> shell, perl, or anything else) "better" than C if there is an
> alternative. Once the C work has been done (and if you require C
> _anyway_ for other reasons, like git does), doing it in C is simply
> superior.

Actually, the same holds for assembly language vs C.  Once the
prototyping is over...

The main point is that with an evolving product, the prototyping never
is over.  And if the prototyping language is good enough, one never
needs to spend the time to "implement properly" when one already has a
working prototype.  Instead one can build upon the prototype, which is
actual progress.  Emacs is an example: its bulk is written in Elisp.
Would it be faster, smaller and more efficient when rewritten
completely in C?  Sure.

But it would stop being as hackable.  And you could have the fun of
searching for memory leaks and buffer overflows and crashes all the
time with code you were just prototyping.  With Elisp, you have a
whole slew fewer ways to shoot yourself in the foot really hard.  When
only 5% of the code is C, only 5% can crash hard, leak memory and so
on.

> Having tried to do internal scripting languages, I can say that it's
> just easier to do it in C once you get past the hump of getting it
> written in C in the first place.

But it is not "once" that you need to do this.  It is a permanent job.

> So yes, we could just make the shell/etc from busybox _be_ the
> scripting language, but the fact is, that is *more* C code than just
> making the commands C code in the first place, and while a lot of
> the effort is already done for us, "busybox under windows" is
> actually likely to be more of a maintenance problem than "native git
> commands under windows" are.

Maintenance: yes.  Development: no.  If you want a product you do not
want to touch again, C is a good final choice.

> And LUA may be a nicer scriping thing than most, but you still end
> up having the impedance match, and quite frankly, I think we'd have
> much fewer problems with just rewriting all the remaining shell
> scripts in C, than to integrate LUA and write them in that.

Sure: if you are aiming for a job that gets finished and then no
longer touched.

Maybe something like Lua would be overkill for the amount of hacking
to be expected: it would indeed ask for reimplementing existing stuff
again.  git-busybox would have the advantage of being able to
jump-start the existing script base, while still obliterating the
whole portability angle.

> (Quite frankly, havign looked at monotone development, I can say
> that we should avoid LUA and things like Boost like the plague. If
> it's not a library that has been around for ten years or more, it's
> not worth the headache).

Lua development was started in 1993.

Anyway, I don't see things as black&white as you do, but as long as
nobody actually implements anything, the discussion is rather idle.

Lua would likely be more portable than git-busybox (and certainly much
smaller), but then one would indeed have a non-trivial rewriting task.
Anyway, I'll follow any git-busybox announcements.  At the current
point of time, it is probably the most advanced candidate for both
retaining scripting and gaining portability.

-- 
David Kastrup

Re: [PATCH] Make "git reset" a builtin. (incomplete)

[Linus Torvalds]

On Wed, 22 Aug 2007, David Kastrup wrote:
> 
> Actually, the same holds for assembly language vs C.  Once the
> prototyping is over...

No. Portability.

The point is, C is *more* portable (and thus maintainable) than shell, but 
assembly language is *less* portable than C.

So no, "the same holds" is not at all true.

It's not about whether something is evolving or not: it's about whether 
something is *maintainable* or not.

And C is most definitely maintainable, in ways that scripting languages 
often are *not*.

> > Having tried to do internal scripting languages, I can say that it's
> > just easier to do it in C once you get past the hump of getting it
> > written in C in the first place.
> 
> But it is not "once" that you need to do this.  It is a permanent job.

Sure, and that's exactly where C shines.

C is not great for "quick and dirty, and I'm not sure where this is 
going".

But once you know where it's going, and once it's not "quick and dirty" 
any more, very little beats C. It's easy to extend on, and if all the 
infrastructure is in C, there simply IS NO BETTER WAY TO GLUE THINGS 
TOGETHER.

There are "C bindings" for other languages (like LUA), but the fact is, 
none of them hold a candle to the "C bindings" of native C.

So you're seemingly ignoring the fact that all the infrastructure is in C 
(and absolutely _needs_ to be in C - there are no valid alternative 
languages at that level).

> Maintenance: yes.  Development: no.  If you want a product you do not
> want to touch again, C is a good final choice.

That's simply not true.

Look around. Most C language projects are really well maintained.

In contrast, a lot of _scripting_ languages are basically write-only. They 
may be write-only because that's their fundamental design (perl), or they 
may be write-only because they are limited enough that you can not easily 
extend them to do new things.

But your statement is provably wrong. Just *look* at well-maintained 
projects that have extended way past their original design and usage 
model. A lot of them are in C.

So why do you make these idiotic arguments that are clearly crap?

			Linus

Re: [PATCH] Make "git reset" a builtin. (incomplete)

[Reece Dunn]

On 22/08/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> On Wed, 22 Aug 2007, Nicolas Pitre wrote:
>
> > On Wed, 22 Aug 2007, David Kastrup wrote:
> >
> > > If the scripting engine of choice for cobbling together prototypes
> > > remains the Unix toolchain outside of git proper, then Windows users
> > > will _always_ remain second class citizens since they will get to work
> > > with and on new porcelain much later than the rest of the world:
> > > namely when somebody bothers porting his new favorite tool for them to
> > > C.
> >
> > Right.
>
> And not making the scripts builtins helps Windows users how, exactly?

IIUC, the plumbing is all (or mostly) ported to C code, whereas the
remaining scripts are on the porcelain side.

Given that you have to deal with other Windows issues (line ending,
case insensitive file names, path format), why not put the current
scripts in a posix porcelain directory and have a Windows porcelain
directory where the Windows porcelain is written in C#?

Alternatively, the porcelain could be unified to use Python and
compiled into an executable that is installed on the Windows platform
(removing the need to have anything other than git installed to use
it).

If not Python, then can you compile perl scripts to an executable
form, in which case perl could be standardized on.

This way, both camps (posix and Windows) will be happy.

- Reece

Re: [PATCH] Make "git reset" a builtin. (incomplete)

[Reece Dunn]

On 22/08/07, David Kastrup <dak@gnu.org> wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Wed, 22 Aug 2007, Nicolas Pitre wrote:
> >
> >> On Wed, 22 Aug 2007, David Kastrup wrote:
> >> > If the scripting engine of choice for cobbling together
> >> > prototypes remains the Unix toolchain outside of git proper, then
> >> > Windows users will _always_ remain second class citizens since
> >> > they will get to work with and on new porcelain much later than
> >> > the rest of the world: namely when somebody bothers porting his
> >> > new favorite tool for them to C.
> >>
> >> Right.
> >
> > And not making the scripts builtins helps Windows users how,
> > exactly?
>
> Red herring.  The proposal was not to do nothing, but rather give git
> a dedicated scripting language internal to it.

That is a really neat idea.

> Two suggestions of
> mine with different advantages were git-busybox and Lua.  A third one
> was once proposed by Linus with some code example: starting a
> scripting language from scratch.

Do you have a link to the proposal?

> So obviously, the need for something
> like that is recognized, and not having to start from zero for that
> might be an advantage if a good, workable language can be found.

It would also aid the Windows porting effort by having a single,
builtin scripting engine that does not have differing behaviours on
different platforms.

One thing that will need sorting is the binding of the C
plumbing/builtin command API to the scripting language, but this
shouldn't be that difficult to do.

- Reece

Re: [PATCH] Make "git reset" a builtin. (incomplete)

[David Kastrup]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> On Wed, 22 Aug 2007, David Kastrup wrote:
> In contrast, a lot of _scripting_ languages are basically
> write-only. They may be write-only because that's their fundamental
> design (perl), or they may be write-only because they are limited
> enough that you can not easily extend them to do new things.
>
> But your statement is provably wrong. Just *look* at well-maintained
> projects that have extended way past their original design and usage
> model. A lot of them are in C.

You mean like Emacs which is mostly scripted in Elisp?  Or the Gimp
which is mainly scripted using script-fu?  Or like TeX which is (to
the surprise of Donald Knuth) usually extended in TeX macros rather
than using Pascal?  Or HTML servers and content management systems,
done in a variety of scripting languages from PHP, Ajax, Plone,
whatever?  Or Mickysoft applications extended in Visual Basic?  Or
Autocad extended in Autolisp or what it is called?  Or autoconf or
sendmail extended in m4 (avaunt!)?

Pretty much _any_ complex extensible system nowadays comes with a
scripting/pattern/macro language of choice, and this language is, for
a variety of reasons, rarely C.

The question is not whether large complex systems are generally
managed in C, since that quite obviously is _not_ the rule.  The
question is rather whether the environment in which one assembles git
plumbing into porcelain should be treated as a large complex system in
itself.  That certainly is a valid question.  If one manages to get
past name-calling, one might answer this in one of several ways.

> So why do you make these idiotic arguments that are clearly crap?

Oooooh, I get the reference.  So _that's_ where the name comes from.

    Q:   WHAT DO YOU WANT?
    M:   Well, I was told outside that...
    Q:   Don't give me that, you snotty-faced heap of parrot
         droppings!
    M:   What?
    Q:   Shut your festering gob, you tit! Your type really makes me
         puke, you vacuous, coffee-nosed, maloderous, pervert!!!
    M:   Look, I CAME HERE FOR AN ARGUMENT, I'm not going to just
         stand...!! 
    Q:   OH, oh I'm sorry, but this is abuse.
    M:   Oh, I see, well, that explains it.
    Q:   Ah yes, you want room 12A, Just along the corridor.
    M:   Oh, Thank you very much. Sorry.
    Q:   Not at all.
    M:   Thank You.
    (Under his breath) Stupid git!!

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: [PATCH] Make "git reset" a builtin. (incomplete)

[David Kastrup]

Matthieu Moy <Matthieu.Moy@imag.fr> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> Could you be so kind as to give a one-sentence summary what the
>> benefits over using a shell script would be?  I think this work has
>> started before I joined the list, and I'd be interested in the
>> motivation for it.  In general, I find shell scripts more pleasant for
>> hacking on than C code, and there is no long-term plan to replace all
>> of them, is there?
>
> That's a Google SoC project :
>
> http://git.or.cz/gitwiki/SoC2007Projects?highlight=%28soc%29#head-2b49ddde32756b52fde3b9d9ab01e1bff6aa687c

Thanks, good to know.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: [PATCH] Make "git reset" a builtin. (incomplete)

[Linus Torvalds]

On Thu, 23 Aug 2007, David Kastrup wrote:
> >
> > But your statement is provably wrong. Just *look* at well-maintained
> > projects that have extended way past their original design and usage
> > model. A lot of them are in C.
> 
> You mean like Emacs which is mostly scripted in Elisp?  Or the Gimp
> which is mainly scripted using script-fu?

No. I mean standard C code projects. Like the kernel. Like a huge class of 
other projects that are C. Not scripts.

Big, huge, projects are all done in C, and they are well-maintained.

Scripting is not the rule at all. And it is silly to say that regular 
all-C projects need to have scripting.

			Linus

Re: [PATCH] Make "git reset" a builtin. (incomplete)

[David Kastrup]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> On Thu, 23 Aug 2007, David Kastrup wrote:
>> >
>> > But your statement is provably wrong. Just *look* at well-maintained
>> > projects that have extended way past their original design and usage
>> > model. A lot of them are in C.
>> 
>> You mean like Emacs which is mostly scripted in Elisp?  Or the Gimp
>> which is mainly scripted using script-fu?
>
> No. I mean standard C code projects. Like the kernel. Like a huge
> class of other projects that are C. Not scripts.

By golly, you are right.  Pretty much all projects that are defined by
not including a script language don't include a script language.

> Big, huge, projects are all done in C, and they are well-maintained.

Ok, so Emacs is a small project.  And Plone is a small project.  And
Ajax is a small project.  And LaTeX is a small project.  And autoconf
is a small project.  And gcc is a small project (we can't have RTL in
a big, huge, project, after all).  And the Linux kernel doesn't
include Makefiles or any other stuff that would be scripted in
anything but C.

> Scripting is not the rule at all. And it is silly to say that
> regular all-C projects need to have scripting.

Actually, if they are defined as all-C, they _can't_ have scripting
by definition.

I am not really interested in continuing this.  I don't think that
there is much I can do to make my point clearer than I did, so any
further amount of "does not" -- "does too" will not make anybody
including ourselves change his mind.

All the best,

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: [PATCH] Make "git reset" a builtin. (incomplete)

[Wincent Colaiuta]

El 23/8/2007, a las 0:25, David Kastrup escribió:

> Pretty much _any_ complex extensible system nowadays comes with a
> scripting/pattern/macro language of choice, and this language is, for
> a variety of reasons, rarely C.

But Git isn't really a "complex extensible system" relatively  
speaking. It's actually a remarkably simple version control system,  
both in terms of its design and in the number of lines of code to  
implement that design. You already have all the extensibility you  
will ever need in the form of the command set (about 144 commands by  
my count) and you're free to script them to your heart's content; the  
fact that some of these commands are being slowly migrated over to C  
is an implementation detail that shouldn't really affect you as a  
user at all, except indirectly in the sense that:

- it should run more quickly

- it should compile and work correctly more easily and with fewer  
dependencies on more platforms

And if you accept Linus' point about the maintainability of C projects:

- the overall quality of the code should be higher because fewer  
cycles will be burnt in maintenance

Cheers,
Wincent

Re: [PATCH] Make "git reset" a builtin. (incomplete)

[Nicolas Pitre]

[ I'm branching off from here and not from later posts on purpose ... ]

On Wed, 22 Aug 2007, Linus Torvalds wrote:

> "git reset" is a command, not a scripting language. We can still script 
> git as much as we want, but the fewer dependencies we have on anything 
> external, the better off we are.
> 
> I don't understand why people consider scripting languages (whether shell, 
> perl, or anything else) "better" than C if there is an alternative. Once 
> the C work has been done (and if you require C _anyway_ for other reasons, 
> like git does), doing it in C is simply superior.

Absolutely no argument with that.  Considering that "git reset" is a 
command, the language used to implement it is just that: an 
_implementation_ "detail".  Especially if the C conversion has already 
been done.

> We ended up writing our own versions (or merging other peoples code) for 
> things like appying patches, generating diffs, three-way merging etc, 
> because not having external dependencies is *so* much more maintainable 
> and portable that it's not even funny.

Indeed. And this is the very same reason why Git should _also_ acquire a 
script interpreter of its own if we want to continue bragging about 
Git's easy scriptability.

> I'd love for every single shell-script in git core to be written in C, so 
> that we can drop the dependency on shell *entirely*.

What about the test suite?

> I also dispute your "easy to do". Quite often, shell (or any scripting 
> language) is actually much *more* complicated than C. Yes, the C code may 
> be more lines (in this case, the shell script is 106 lines, and the C code 
> was 216 lines), but from a maintenance standpoint, C has had *much* fewer 
> problems than the shell script stuff has ever had!

Let's not talk strictly about this very case.  Like we agreed above, the 
C conversion has been done so there is no downside really not to move on 
with the C version.  Same for other core commands if/when they get 
converted.

That would still be nice, though, if we could have a unified scripting 
language for Git, that didn't have any nasty external dependency either.  
If only so Git could be self sufficient on any platform it is ported to 
for its test suite, and also for extra functionality that users would 
end up sharing across the whole user base and not only on platform where 
bash comes installed by default.

And there might be some cases where using that same scripting language 
for permanently implementing actual command could simply make sense once 
it can be safely depended upon.

> So scripting languages are often good for *prototyping*, and a lot of 
> people like scripting languages for that reason. But once something is 
> already prototyped, and if somebody then rewrites it in C, all the 
> advantages of a scripting language have already disappeared!
> 
> So yes, we could just make the shell/etc from busybox _be_ the scripting 
> language, but the fact is, that is *more* C code than just making the 
> commands C code in the first place, and while a lot of the effort is 
> already done for us, "busybox under windows" is actually likely to be more 
> of a maintenance problem than "native git commands under windows" are.

Possibly.  Again that depends how much we need from it.  We don't need 
_that_ much from a shell and the bad portability issues can certainly be 
avoided altogether simply by ripping out problematic functionality.  
Such shell doesn't even have to be POSIX compliant or whatever.

> So if we have the choice, and somebody has written a git command in native 
> C code, I think we should *always* take it. Just because it means that 
> _eventually_ we can drop shell entirely, even if it would be a git 
> internal busybox shell.

It could be taken the other way around too: If we have the choice, and 
somebody has ported a subset of busybox to Windows tailored for Git 
plumbing usage, then we _could_ stop worrying so much about shell 
portability right there and redirect our efforts toward other things.


Nicolas

Re: [PATCH] Make "git reset" a builtin. (incomplete)

[Linus Torvalds]

On Thu, 23 Aug 2007, David Kastrup wrote:
> 
> By golly, you are right.  Pretty much all projects that are defined by
> not including a script language don't include a script language.

The point is, you made a totally bogus and unsubstantiated claim: you 
claimed that projects that are written in C would be (direct quotes from 
your *idiotic* claims): "But it would stop being as hackable." and "if you 
are aiming for a job that gets finished and then no longer touched."

Both of those claims were pure and unadulterated *CRAP*.

Which I pointed out. You just seem to have trouble admitting it.

And both of those claims seemed to be the whole gist of your argument.

If you make your arguments based on stuff that is obviously crap and 
untrue, don't be surprised when people then consider your arguments to be 
less than convincing.

		Linus

Re: [PATCH] Make "git reset" a builtin. (incomplete)

[Jon Smirl]

On 8/22/07, Nicolas Pitre <nico@cam.org> wrote:
> Indeed. And this is the very same reason why Git should _also_ acquire a
> script interpreter of its own if we want to continue bragging about
> Git's easy scriptability.

Last project I was working on that needed a scripting language picked lua.
http://www.lua.org/about.html

I had never heard of it before but after working with it for a while I
found it to be a very nice package with minimal resource requirements.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: [PATCH] Make "git reset" a builtin. (incomplete)

[Nguyen Thai Ngoc Duy]

On 8/22/07, David Kastrup <dak@gnu.org> wrote:
> Andreas Ericsson <ae@op5.se> writes:
>
> > David Kastrup wrote:
> >> Carlos Rica <jasampler@gmail.com> writes:
> >>
> >>> This is the first version of the program "builtin-reset.c",
> >>> intended for replacing the script "git-reset.sh".
> >>>
> >>> The --mixed option with -- paths is not implemented yet.
> >>>
> >>> The tests I made for it are not finished so they are not included,
> >>> but it seems to pass the rest of the test suite.
> >>
> >> Could you be so kind as to give a one-sentence summary what the
> >> benefits over using a shell script would be?
> >
> > One word: Portability.
> >
> > There's a plethora of various shell syntaxes. Discerning what's
> > correct shell and what's a bash'ism that may or may not be posixly
> > correct (but perhaps not supported on a multitude of out-of-the-box
> > solaris system) has so far taken almost as much time as convincing
> > newcomers to git that there really is no point in tracking file
> > renames explicitly.
> >
> > Otoh, the list of large and renowned projects that have shunned git
> > for its weak windows support grows longer, meaning we potentially
> > lose competent programmers simply because they're forced to use
> > something else.
>
> The problem I see is that C sucks really really bad as a scripting
> language, and tying together plumbing functionality into porcelain is
> one of the most powerful, flexible and hack-friendly features of git.
> Deprecating scripts is making git more opaque.
>
> Personally, I would prefer an approach of using an embedded script
> interpreter: then language incompatibilities become a non-issue.
> git-busybox sounded like a great idea for portability.

Although I have never tested git-box (git-busybox) under Linux, I
believe it would work well because all Unix specific code remains the
same as in busybox. Making git-box part of git would increase git
binary size by ~200kb IIRC.
-- 
Duy

Re: [PATCH] Make "git reset" a builtin. (incomplete)

[Linus Torvalds]

On Wed, 22 Aug 2007, Nicolas Pitre wrote:
> 
> > We ended up writing our own versions (or merging other peoples code) for 
> > things like appying patches, generating diffs, three-way merging etc, 
> > because not having external dependencies is *so* much more maintainable 
> > and portable that it's not even funny.
> 
> Indeed. And this is the very same reason why Git should _also_ acquire a 
> script interpreter of its own if we want to continue bragging about 
> Git's easy scriptability.

I suspect that most people who want scriptability want it within the 
confines of whatever environment they run in.

For example, I swear by git's scriptability, but I do so not because I 
think it would be a good idea to script _within_ git using some magic 
language, but because I think we made good design decisions that makes it 
easy to integrate git with the kinds of scripts I write every day.

But the kinds of scriping *I* do has nothing to do with the kinds of 
scripting other people necessarily do. I use shell pipelines, and quite 
frankly, any "internal" scripting inside of git is totally uninteresting 
to me, exactly because I'm used to the generic UNIX tools, and I find it 
damn interesting to do things like

	git log -p --since=6.months | cut -c1 | sort | uniq -c

and use that as a really cheesy way to see how many lines have gotten 
added/removed in the patches in the last 6 months.

(Yeah, I get some other characters than just "+/-" too, I don't care, the 
part I care about is:

	 749754 -
	  96945 @
	1030104 +

ie about a hundred thousand hunks, with an average of 7.5 lines deleted 
per hunk, and 10 lines added)

See? Sure, some kind of internal git scripting language could do things 
like this too, but that defeats the point: it's that git is useful 
*within* a UNIX scripting environment, not that it makes its own.

There are enough scripting languages out there. It's wonderful if git can 
be used with then, rather than having to make up another language that you 
have to learn.

And yes, I agree with people who say that LUA is probably the best choice 
if people really want a scripting language, but would I actually use LUA 
for something like the above? No. I think that people who look for 
scriptability usually prefer the kind of scriptability that git already 
has, namely that it fits into their *existing* setup.

> > I'd love for every single shell-script in git core to be written in C, so 
> > that we can drop the dependency on shell *entirely*.
> 
> What about the test suite?

The test suite is indeed special. But I think that's a "build requiement", 
and if we require something like shell for *building*, that's different 
from requiring normal users to have it.

If somebody wants to re-code the test-suite in some other scripting 
engine, that would be fine by me. I'd hope you can automate it, though: 
that is a *lot* of lines of shell.

			Linus

Re: [PATCH] Make "git reset" a builtin. (incomplete)

[Junio C Hamano]

Linus Torvalds <torvalds@linux-foundation.org> writes:

>> > I'd love for every single shell-script in git core to be written in C, so 
>> > that we can drop the dependency on shell *entirely*.
>> 
>> What about the test suite?
>
> The test suite is indeed special. But I think that's a "build requiement", 
> and if we require something like shell for *building*, that's different 
> from requiring normal users to have it.

Also it is a good test for the kind of scriptability you (and I)
seek.  We should not drop shell from the test suite for that
reason.

Re: [PATCH] Make "git reset" a builtin. (incomplete)

[Johannes Schindelin]

Hi,

On Wed, 22 Aug 2007, Reece Dunn wrote:

> On 22/08/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >
> > On Wed, 22 Aug 2007, Nicolas Pitre wrote:
> >
> > > On Wed, 22 Aug 2007, David Kastrup wrote:
> > >
> > > > If the scripting engine of choice for cobbling together prototypes
> > > > remains the Unix toolchain outside of git proper, then Windows users
> > > > will _always_ remain second class citizens since they will get to work
> > > > with and on new porcelain much later than the rest of the world:
> > > > namely when somebody bothers porting his new favorite tool for them to
> > > > C.
> > >
> > > Right.
> >
> > And not making the scripts builtins helps Windows users how, exactly?
> 
> IIUC, the plumbing is all (or mostly) ported to C code, whereas the
> remaining scripts are on the porcelain side.

Well, I know.  And guess three times why _I_ know.

> Given that you have to deal with other Windows issues (line ending,
> case insensitive file names, path format), why not put the current
> scripts in a posix porcelain directory and have a Windows porcelain
> directory where the Windows porcelain is written in C#?

Isn't C# yet another dependency?  Worse yet, a dependency that you plan to 
have on _one_ platform, and that is utterly unusable on other platforms?  
And don't give me the Mono talk.  I happen to be _very_ unhappy with the 
Mono dependency that SuSE introduced, because it is _slow_ _as_ _magma_.

> Alternatively, the porcelain could be unified to use Python and compiled 
> into an executable that is installed on the Windows platform (removing 
> the need to have anything other than git installed to use it).

Mentioning Python in this context is not even funny.

> This way, both camps (posix and Windows) will be happy.

No.  I would be _very_ unhappy should your plans come true.

Ciao,
Dscho

Re: [PATCH] Make "git reset" a builtin. (incomplete)

[Johannes Schindelin]

Hi,

On Wed, 22 Aug 2007, Reece Dunn wrote:

> On 22/08/07, David Kastrup <dak@gnu.org> wrote:
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >
> > > On Wed, 22 Aug 2007, Nicolas Pitre wrote:
> > >
> > >> On Wed, 22 Aug 2007, David Kastrup wrote:
> > >> > If the scripting engine of choice for cobbling together
> > >> > prototypes remains the Unix toolchain outside of git proper, then
> > >> > Windows users will _always_ remain second class citizens since
> > >> > they will get to work with and on new porcelain much later than
> > >> > the rest of the world: namely when somebody bothers porting his
> > >> > new favorite tool for them to C.
> > >>
> > >> Right.
> > >
> > > And not making the scripts builtins helps Windows users how,
> > > exactly?
> >
> > Red herring.  The proposal was not to do nothing, but rather give git
> > a dedicated scripting language internal to it.
> 
> That is a really neat idea.

Why?  Why should just _having_ a dedicated scripting language _per se_ be 
a neat idea?  We do not _need_ it!  We script git in bash, perl, other 
people in Python, Ruby, and even Haskell.  So why should we _take away_ 
that freedom from others to script Git in whatever language they like 
most?  There is no good reason.

> > Two suggestions of mine with different advantages were git-busybox and 
> > Lua.  A third one was once proposed by Linus with some code example: 
> > starting a scripting language from scratch.
> 
> Do you have a link to the proposal?

Go search in the mailing list archives.  It's not hard to find.

> > So obviously, the need for something like that is recognized, and not 
> > having to start from zero for that might be an advantage if a good, 
> > workable language can be found.
> 
> It would also aid the Windows porting effort by having a single, builtin 
> scripting engine that does not have differing behaviours on different 
> platforms.

What is your problem?  msysGit is coming along pretty fine _without_ that 
maintenance nightmare of an own scripting language.  We use bash and perl, 
thank you very much.

> One thing that will need sorting is the binding of the C 
> plumbing/builtin command API to the scripting language, but this 
> shouldn't be that difficult to do.

It is that easy that you could do it in an hour or so, right?  Or not.  We 
need a whole GSoC project to do that, since sorting out a decent API is 
_not_ easy.

Ciao,
Dscho

Re: [PATCH] Make "git reset" a builtin. (incomplete)

[Johannes Schindelin]

Hi,

On Wed, 22 Aug 2007, Linus Torvalds wrote:

> On Wed, 22 Aug 2007, Nicolas Pitre wrote:
>
> > Linus wrote:
> >
> > > I'd love for every single shell-script in git core to be written in 
> > > C, so that we can drop the dependency on shell *entirely*.
> > 
> > What about the test suite?
> 
> The test suite is indeed special. But I think that's a "build 
> requiement", and if we require something like shell for *building*, 
> that's different from requiring normal users to have it.

And do not forget that "make install" is not _part_ of "make install".  If 
you do not want to check that all is fine, but trust the other 
suc^Wdevelopers, you can just omit running the tests.

Ciao,
Dscho

Re: [PATCH] Make "git reset" a builtin. (incomplete)

[Johannes Schindelin]

Hi,

On Wed, 22 Aug 2007, Nicolas Pitre wrote:

> On Wed, 22 Aug 2007, Johannes Schindelin wrote:
> 
> > What is wrong with going from shell to C?  C _is_ portable.  Instead 
> > of relying on _yet_ another scripting language, introducing _yet_ 
> > another language that people have to learn to hack git, introducing 
> > _yet_ another place for bugs to hide, why not just admit that shell is 
> > nice for _prototyping_?
> 
> This is a narrow view of the programming world that I don't share.

Well, you have to admit that some things are really, really hard to do in 
shell.  Just from the top of my head: locking, data structures, 
portability, scalability, process control.  There are a lot more, I guess, 
but for the _core_ of Git I really prefer C.

> C is portable indeed, which is one of its upsides.  But it has many 
> downsides too for many _users_, that as a Git _developer_ you apparently 
> conveniently ignore.

I do not want to shove C down the throat of every Git user.  You can use 
_whatever_ scripting language you like.

Nevertheless, this is _different_ from the choice for _core_ Git.  
Eventually I'd like to be able to run Git on embedded systems, or my 
digital watch.

> > Why do we have to to have the same discussion over and over and over 
> > again?
> 
> Because, as shown by the recurring nature of this discussion, using C for 
> everything is evidently not the optimal solution.

I think the reason is different (as shown by the content of the 
discussion).

Ciao,
Dscho

Re: [PATCH] Make "git reset" a builtin. (incomplete)

[Theodore Tso]

On Thu, Aug 23, 2007 at 10:10:20AM +0100, Johannes Schindelin wrote:
> > > Red herring.  The proposal was not to do nothing, but rather give git
> > > a dedicated scripting language internal to it.
> > 
> > That is a really neat idea.
> 
> Why?  Why should just _having_ a dedicated scripting language _per se_ be 
> a neat idea?  We do not _need_ it!  We script git in bash, perl, other 
> people in Python, Ruby, and even Haskell.  So why should we _take away_ 
> that freedom from others to script Git in whatever language they like 
> most?  There is no good reason.

Users should be able to script in whatever language they want; that's
clear.  However, what some people were talking about was an internal
scripting language that would be used for writing git commands, as an
alternative to an alternative future where everything gets moved to C.
(To accomodate those Windows users who for some silly reason refuse to
install Cygwin, bash, and perl on their Windows development box.  :-)

I mean, even today, if you were to implement some core git porcelein
command in Haskell, and submitted it for inclusion into the mainline
git tree, Junio would I suspect look somewhat skeptically at it.

So for those people who think an internal scripting language would be
a worthwhile way of implementing certain git commands, instead of
converting them all to C, my suggestion would be to "show us the
code".  Actually create the git to LUA bindings, and then show how
easily it would be to rewrite a bunch of the existing git commands
which are currently implemented in shell in LUA instead.  If you can
demonstrate that it could very easily and quickly get rid of all of
the remaining shell scripts and create a version of git that would be
considered a first class Windows port that doesn't require Cygwin, I'm
sure people would spend time looking at the results.

But if people are just gushing over the glories of elisp and saying
things like *someone* should create a scripting language for git, it's
just going to be a waste of everyone's time.

Regards,

						- Ted

Re: [PATCH] Make "git reset" a builtin. (incomplete)

[Johannes Schindelin]

Hi,

On Thu, 23 Aug 2007, Theodore Tso wrote:

> On Thu, Aug 23, 2007 at 10:10:20AM +0100, Johannes Schindelin wrote:
> > > > Red herring.  The proposal was not to do nothing, but rather give git
> > > > a dedicated scripting language internal to it.
> > > 
> > > That is a really neat idea.
> > 
> > Why?  Why should just _having_ a dedicated scripting language _per se_ be 
> > a neat idea?  We do not _need_ it!  We script git in bash, perl, other 
> > people in Python, Ruby, and even Haskell.  So why should we _take away_ 
> > that freedom from others to script Git in whatever language they like 
> > most?  There is no good reason.
> 
> Users should be able to script in whatever language they want; that's
> clear.  However, what some people were talking about was an internal
> scripting language that would be used for writing git commands, as an
> alternative to an alternative future where everything gets moved to C.

And that is _exactly_ where I fail to see benefits from.  You only get the 
full power of C by using C.  You only get the full power of all open 
source C programmers by using C.  And you only get the full flexibility, 
speed, name-your-own-pet-peeve using C.

Mind you, I use scripts a lot.  I even have some projects where I 
git-added a script to add aliases which are so large as to fit half a 
terminal.

But we should not _force_ people to have bash or perl when they do not 
plan to use it themselves.

> (To accomodate those Windows users who for some silly reason refuse to 
> install Cygwin, bash, and perl on their Windows development box.  :-)

I have seen boxes where the administrators locked down everything.  And 
Cygwin _does_ need to write the registry, and there is _no_ easy way to 
have two independent Cygwin installs on the same machine.  This is where 
MinGW/MSys really shines.

> So for those people who think an internal scripting language would be a 
> worthwhile way of implementing certain git commands, instead of 
> converting them all to C, my suggestion would be to "show us the code".  
> Actually create the git to LUA bindings, and then show how easily it 
> would be to rewrite a bunch of the existing git commands which are 
> currently implemented in shell in LUA instead.

And force everybody who wants to contribute to _those_ parts of Git to 
learn LUA?  It is not about languages.  It is about people.  Choosing an 
obscure language automatically limits your most valuable resource: people.

We saw that already with filter-branch (which saw some duplicate efforts, 
because one developer was not comfortable with shell; we had two different 
programs with different suboptimal behaviours).

> But if people are just gushing over the glories of elisp and saying 
> things like *someone* should create a scripting language for git, it's 
> just going to be a waste of everyone's time.

Amen,
Dscho

Re: [PATCH] Make "git reset" a builtin. (incomplete)

[David Tweed]

On 8/23/07, Theodore Tso <tytso@mit.edu> wrote:
> (To accomodate those Windows users who for some silly reason refuse to
> install Cygwin, bash, and perl on their Windows development box.  :-)

I know I'm really going to regret entering this discussion but...

_If_ your goal is widening git usage (and you could validly argue it should
stay a system for "code hackers"), the big worry is if you want to
accomodate on projects that you (as an upstanding traditional *nix person)
run where you've pushed for using git and are working with people
who work prefer working on windows and they only want to use your git
as the SCM for and don't care about git beyond that. The scenario goes:

Windows user: "You want me to use your git repo for development.
Ok. Install all those pre-requisites for me if you want me to use SCM
regularly."
...
Windows user: "Git isn't working. Come here and tell me what's wrong?"

*nix person: "Dunno, I've never seen that before. I wonder what's
causing it: is it a git thing I've never seen, is it a bash/Perl-on-Windows
weirdness, is it something implemented not as expected in the cygwin
libraries, is it native Windows behaviour that's actually "right"?
Or is it some mixture of the four? And given that I've never
used cygwin and other tools on windows, I'm ******** if I know...."

Windows user: "That's ok, I don't need to commit in this work-in-progress
so I won't commit until you've solved the problem."

I personally don't care exactly what's used implementing git on non-unix
platforms, but I get nervous as more and more "layers" are added so
it becomes more and more difficult to figure which layer a user problem
is occurring at. If it looks to difficult to "help out with" issues on Windows,
that would be a big enough reason for me not to use git on such projects.

-- 
cheers, dave tweed__________________________
david.tweed@gmail.com
Rm 124, School of Systems Engineering, University of Reading.
"we had no idea that when we added templates we were adding a Turing-
complete compile-time language." -- C++ standardisation committee

Re: [PATCH] Make "git reset" a builtin. (incomplete)

[Johannes Schindelin]

Hi,

[I thought that it was high time in this thread to review the code]

On Wed, 22 Aug 2007, Carlos Rica wrote:

> The tests I made for it are not finished so they are not included, but 
> it seems to pass the rest of the test suite.

AFAICS there are only "reset --hard"s in the test suite.

> diff --git a/builtin-reset.c b/builtin-reset.c
> [...]
> +
> +static int unmerged_files(void)
> +{
> +	char b;
> +	ssize_t len;
> +	struct child_process cmd;
> +	const char *argv_ls_files[] = {"ls-files", "--unmerged", NULL};
> +
> +	memset(&cmd, 0, sizeof(cmd));
> +	cmd.argv = argv_ls_files;
> +	cmd.git_cmd = 1;
> +	cmd.out = -1;
> +
> +	if (start_command(&cmd))
> +		die("Could not run sub-command: git ls-files");
> +
> +	len = xread(cmd.out, &b, 1);
> +	if (len < 0)
> +		die("Could not read output from git ls-files: %s",
> +						strerror(errno));
> +	finish_command(&cmd);
> +
> +	return len;
> +}

I think it is a good idea to start out using run_command, and if we ever 
run into performance issues, we can always switch to calling the functions 
directly.

> +static int print_line_current_head(void)
> +{
> +	const char *argv_log[] = {"log", "--max-count=1", "--pretty=oneline",
> +					"--abbrev-commit", "HEAD", NULL};
> +	printf("HEAD is now at ");
> +	unsetenv("GIT_PAGER");
> +	return run_command_v_opt(argv_log, RUN_GIT_CMD);
> +}

This is a candidate to refactoring, using commit.c's get_one_line() 
function.

> +int cmd_reset(int argc, const char **argv, const char *prefix)
> +{
> +	int i = 1, reset_type = MIXED, update_ref_status = 0;
> +	const char *rev = "HEAD";
> +	unsigned char sha1[20], *orig = NULL, sha1_orig[20],
> +				*old_orig = NULL, sha1_old_orig[20];
> +	struct object *obj;
> +	char *reflog_action;
> +
> +	git_config(git_default_config);
> +
> +	reflog_action = args_to_str(argv);
> +	setenv("GIT_REFLOG_ACTION", reflog_action, 0);
> +
> +	if (i < argc) {
> +		if (!strcmp(argv[i], "--mixed")) {
> +			reset_type = MIXED;
> +			i++;
> +		}
> +		else if (!strcmp(argv[i], "--soft")) {
> +			reset_type = SOFT;
> +			i++;
> +		}
> +		else if (!strcmp(argv[i], "--hard")) {
> +			reset_type = HARD;
> +			i++;
> +		}
> +	}
> +
> +	if (i < argc && argv[i][0] != '-')
> +		rev = argv[i++];
> +
> +	if (get_sha1(rev, sha1))
> +		die("Failed to resolve '%s' as a valid ref.", rev);
> +
> +	obj = deref_tag(parse_object(sha1), sha1_to_hex(sha1), 40);

IMHO it would be better to use "..., rev, strlen(rev));" instead.

> +	if (!obj)
> +		die("Could not parse object '%s'.", rev);
> +	memcpy(sha1, obj->sha1, sizeof(sha1));
> +
> +	if (i < argc && argv[i][0] == '-') {
> +		if (strcmp(argv[i], "--"))
> +			usage(builtin_reset_usage);
> +		else
> +			i++;
> +	}

IMHO this would be clearer:

	if (i < argc && !strcmp(argv[i], "--"))
		i++;
	else if (i < argc && argv[i][0] == '-')
		usage(builtin_reset_usage);

but I do not care _that_ deeply.

> +	/* git reset --mixed tree [--] paths... can be used to
> +	 * load chosen paths from the tree into the index without
> +	 * affecting the working tree nor HEAD. */
> +	if (i < argc) {
> +		if (reset_type != MIXED)
> +			die("Cannot do partial %s reset.", argv[1]);

Hmm.  Maybe use a static const array of "hard", "mixed" and "soft"?

> +		/*
> +		git diff-index --cached $rev -- "$@" |
> +		sed -e 's/^:\([0-7][0-7]*\) [0-7][0-7]* \([0-9a-f][0-9a-f]*\) [0-9a-f][0-9a-f]* [A-Z]	\(.*\)$/\1 \2	\3/' |
> +		git update-index --add --remove --index-info || exit
> +		*/
> +		update_index_refresh();

AFAICT this code misses out on added files, i.e. files which are in $rev, 
but not in the index.

> +	/* Any resets update HEAD to the head being switched to,
> +	 * saving the previous head in ORIG_HEAD before. */
> +	if (!get_sha1("ORIG_HEAD", sha1_old_orig))
> +		old_orig = sha1_old_orig;
> +	if (!get_sha1("HEAD", sha1_orig)) {
> +		orig = sha1_orig;
> +		update_ref("updating ORIG_HEAD", "ORIG_HEAD", orig, old_orig);
> +	}
> +	else if (old_orig)
> +		delete_ref("ORIG_HEAD", old_orig);

Why not put the get_sha1() into the else if()?  You spare a variable and a 
few lines there.

Otherwise it looks good to me.  It would be good if you could post your 
test script, though, so that people can get a feel what works and what 
needs work.

Ciao,
Dscho

Re: [PATCH] Make "git reset" a builtin. (incomplete)

[Theodore Tso]

On Thu, Aug 23, 2007 at 11:31:56AM +0100, Johannes Schindelin wrote:
> And that is _exactly_ where I fail to see benefits from.  You only get the 
> full power of C by using C.  You only get the full power of all open 
> source C programmers by using C.  And you only get the full flexibility, 
> speed, name-your-own-pet-peeve using C.

Sure, but not all porcelein commands need the full power of C.  Take
"git-gc" for example.  It was a *very* short shell script before it
was rewritten to use C.

> I have seen boxes where the administrators locked down everything.  And 
> Cygwin _does_ need to write the registry, and there is _no_ easy way to 
> have two independent Cygwin installs on the same machine.  This is where 
> MinGW/MSys really shines.

So are you claiming that MingGW/MSys is so good that it has a
perl/bash that is fully Linux compatible, so that we don't need to
convert our various internal commands that are implemented in shell to
C?  I didn't think that was a commonly held assessment...

> > So for those people who think an internal scripting language would be a 
> > worthwhile way of implementing certain git commands, instead of 
> > converting them all to C, my suggestion would be to "show us the code".  
> > Actually create the git to LUA bindings, and then show how easily it 
> > would be to rewrite a bunch of the existing git commands which are 
> > currently implemented in shell in LUA instead.
> 
> And force everybody who wants to contribute to _those_ parts of Git to 
> learn LUA?  It is not about languages.  It is about people.  Choosing an 
> obscure language automatically limits your most valuable resource: people.

I don't know enough about LUA to say for sure.  Having taken a quick
look at lua.org, the implementation looks pleasantly small, and LUA
scripts look more comprehensible than say Tcl (which is not saying
much, I know).  But part of "show me the code" is people demonstrating
that no really, LUA is an appropriate tool for simple scripts that is
portable enough that we don't need to have external dependencies on
bash and perl, and that it is easier than rewriting all of our shell
scripts in C.  Maybe that is a true statement.  I don't know.  My
suggestion to "Show us the code" was a way of hoping someone who cared
enough about this issue could show us.

On Thu, Aug 23, 2007 at 11:55:41AM +0100, David Tweed wrote:
> 
> *nix person: "Dunno, I've never seen that before. I wonder what's
> causing it: is it a git thing I've never seen, is it a bash/Perl-on-Windows
> weirdness, is it something implemented not as expected in the cygwin
> libraries, is it native Windows behaviour that's actually "right"?
> Or is it some mixture of the four? And given that I've never
> used cygwin and other tools on windows, I'm ******** if I know...."

This is definitely the case with Cygwin, and I *thought* it was an
issue with MSys/MingGW.  Johannes seems to be arguing otherwise, but I
don't have first hand experience, since happily I haven't had to do
Windows development since 1999, when I stopped working on Kerberos at
MIT.  (Back then we had some really gross perl scripts that converted
Unix makefiles into Windows makefiles, and I used Cygwin, so I know
how unsatisfying that would be for a die-hard Windows programmer.)

> I personally don't care exactly what's used implementing git on non-unix
> platforms, but I get nervous as more and more "layers" are added so
> it becomes more and more difficult to figure which layer a user problem
> is occurring at. If it looks to difficult to "help out with" issues on Windows,
> that would be a big enough reason for me not to use git on such projects.

I think people are aware of that, and that's why the debate is going
on about either rewriting all internal shell scripts to C, or perhaps
using some extension language.

My personal belief is that for anything longer than a relatively
trivial size, the right answer *is* to rewrite it to C, and we have
some GSoC students doing just that.  But for some of the simpler
scripts, maybe it makes sense to consider LUA.  I don't know.  But
someone who cares is going to have to implement a proof of concept and
then convince everyone that it is worthwhile for the git community to
learn LUA.  If it's not a simple enough language, or write-only
language like Perl (quick!  what does this do?  
$_="krJhruaesrltre c a cnP,ohet";$_.=$1,print$2while s/(..)(.)//;),
then such a proposal will fall flat on its face.  But from my very
quick examination of LUA, it seems to avoid the obvious problems of
Perl (too easy to write obfuscated code, no stable language specification,
too big), Python (too big, no stable language specification), Tcl 
(awful syntax), so if someone is willing to champion it, it should be
given a fair hearing.

Or maybe we just convert everything over to C.  That's an acceptable
outcome as well, and probably the most likely given that we're doing
this already.

						- Ted

Re: [PATCH] Make "git reset" a builtin. (incomplete)

[Reece Dunn]

On 23/08/07, David Tweed <david.tweed@gmail.com> wrote:
> On 8/23/07, Theodore Tso <tytso@mit.edu> wrote:
> > (To accomodate those Windows users who for some silly reason refuse to
> > install Cygwin, bash, and perl on their Windows development box.  :-)
>
> I personally don't care exactly what's used implementing git on non-unix
> platforms, but I get nervous as more and more "layers" are added so
> it becomes more and more difficult to figure which layer a user problem
> is occurring at. If it looks to difficult to "help out with" issues on Windows,
> that would be a big enough reason for me not to use git on such projects.

This is one of the reasons I _suggested_ C# for the _Windows_
porcelian. That way, you have the git plumbing written in C, and the
porcelain is implemented in supported tools for the target platform.

I don't mind what the porcelain is written in. However, standardizing
on a single language improves the ability to target more people,
especially as a shell, perl and python are not supported out of the
box on Windows like they are on posix systems. This is important for
some Windows developers and setting up build machines and the like
(most, if not all, Windows users expect each application to be
independant of anything else). It also reduces the surface area in
which problems can occur.

Therefore, we come back to porting the stable scripts to "pure" C.
Doing this for git-rebase _helped_ the Windows port. With a purely C
implementation you have fewer places where problems can arise and
platform issues can be dealt with in a unified way, instead of
duplicating them in each script.

This does not prevent new commands from being prototyped in a
scripting language. Nor does it prevent the user from running the
commands in their own shell/perl/python scripts. It would limit the
"bleeding edge" commands to posix platforms (including cygwin), until
they are supported natively, but that would not hinder adoption of git
on Windows platforms.

- Reece

Re: [PATCH] Make "git reset" a builtin. (incomplete)

[Johannes Schindelin]

Hi,

On Thu, 23 Aug 2007, Theodore Tso wrote:

> On Thu, Aug 23, 2007 at 11:31:56AM +0100, Johannes Schindelin wrote:
>
> > And that is _exactly_ where I fail to see benefits from.  You only get 
> > the full power of C by using C.  You only get the full power of all 
> > open source C programmers by using C.  And you only get the full 
> > flexibility, speed, name-your-own-pet-peeve using C.
> 
> Sure, but not all porcelein commands need the full power of C.  Take 
> "git-gc" for example.  It was a *very* short shell script before it was 
> rewritten to use C.

That is right.  It was short.

> > I have seen boxes where the administrators locked down everything.  
> > And Cygwin _does_ need to write the registry, and there is _no_ easy 
> > way to have two independent Cygwin installs on the same machine.  
> > This is where MinGW/MSys really shines.
> 
> So are you claiming that MingGW/MSys is so good that it has a perl/bash 
> that is fully Linux compatible, so that we don't need to convert our 
> various internal commands that are implemented in shell to C?  I didn't 
> think that was a commonly held assessment...

I did not even come close to saying that.

MinGW/MSys has the advantage over Cygwin that you can have multiple 
installations.  With different settings, in different places.

However, since we are on Windows we have plenty of problems.  Think 
fork().  Think "C:/srv" _not_ meaning a protocol.  Think non-Git programs 
that have a non-POSIX idea of path names, or of passing a command line 
(including quoting).

One problem we face ATM is that MSys apparently cannot be taught _not_ to 
mangle something as "repo.or.cz:/srv/git/something.git" into 
"repo.or.cz;C:\msysGit\srv/git/something.git".  If we had no scripts, this 
would be a non-issue.  Since no MSys would be involved.

Anyway, I'd much rather use my time hacking than reading monster threads 
with more LOC than I will ever write in my life.  And no, that "C" does 
not mean "code".

Ciao,
Dscho

Re: [PATCH] Make "git reset" a builtin. (incomplete)

[Nicolas Pitre]

On Thu, 23 Aug 2007, Johannes Schindelin wrote:

> Hi,
> 
> On Wed, 22 Aug 2007, Nicolas Pitre wrote:
> 
> > On Wed, 22 Aug 2007, Johannes Schindelin wrote:
> > 
> > > What is wrong with going from shell to C?  C _is_ portable.  Instead 
> > > of relying on _yet_ another scripting language, introducing _yet_ 
> > > another language that people have to learn to hack git, introducing 
> > > _yet_ another place for bugs to hide, why not just admit that shell is 
> > > nice for _prototyping_?
> > 
> > This is a narrow view of the programming world that I don't share.
> 
> Well, you have to admit that some things are really, really hard to do in 
> shell.  Just from the top of my head: locking, data structures, 
> portability, scalability, process control.  There are a lot more, I guess, 
> but for the _core_ of Git I really prefer C.

I don't dispute that.

I'm more concerned about easy scripting of Git operations that can be 
shared across different environments.

> I do not want to shove C down the throat of every Git user.  You can use 
> _whatever_ scripting language you like.

Sure.  I was thinking that a common scripting language, shipped with Git 
itself that would work out of the box either on Linux or Windows, could 
benefit the whole Git user base, with a possible side effect of being 
able to also run the test suite everywhere.  If that has no sufficient 
merits to other people and only remains a peep dream of mine then so be 
it.


Nicolas

Re: [PATCH] Make "git reset" a builtin. (incomplete)

[Jon Smirl]

On 8/23/07, Theodore Tso <tytso@mit.edu> wrote:
> I don't know enough about LUA to say for sure.  Having taken a quick
> look at lua.org, the implementation looks pleasantly small, and LUA
> scripts look more comprehensible than say Tcl (which is not saying
> much, I know).  But part of "show me the code" is people demonstrating
> that no really, LUA is an appropriate tool for simple scripts that is
> portable enough that we don't need to have external dependencies on
> bash and perl, and that it is easier than rewriting all of our shell
> scripts in C.  Maybe that is a true statement.  I don't know.  My
> suggestion to "Show us the code" was a way of hoping someone who cared
> enough about this issue could show us.

I just threw LUA out as an example of a tiny language in the hope of
avoiding something giant like mono. LUA is already installed on most
Linux distributions, liblua50.so on mine. It is 100KB.

LUA is used as a scripting language in some popular games. Because of
that it has good ports to Mac/Windows. There are over a dozen books on
Amazon about using LUA.

I only care about the scripting issue in that I don't want git to get
tied to a giant scripting system. LUA is small enough to package with
git.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: [PATCH] Make "git reset" a builtin. (incomplete)

[Robin Rosenberg]

onsdag 22 augusti 2007 skrev Reece Dunn:
> Given that you have to deal with other Windows issues (line ending,
> case insensitive file names, path format), why not put the current
> scripts in a posix porcelain directory and have a Windows porcelain
> directory where the Windows porcelain is written in C#?
Splitting effort in one language per platform would be very bad. Windows
programmers would write porcelains in C# that won't run on Linux.  Even
when you get the programs to run, C# is a second class citizen on *nix.

> Alternatively, the porcelain could be unified to use Python and
> compiled into an executable that is installed on the Windows platform
> (removing the need to have anything other than git installed to use
> it).
We need to attract developers on Windows too and making it hard to
get started with development (i.e. fix a tiny shitty bug or feature), should not require
lots of setups. When we speak of dependencies in an OSS project, those
that are required for development counts too.

> If not Python, then can you compile perl scripts to an executable
> form, in which case perl could be standardized on.

> This way, both camps (posix and Windows) will be happy.

Neither will be happy. Wannabe git hackers will find it hard to get started on
Windows, *nix users will be unhappy because the stuff written on windows
will be hard to get running on *nix etc and again windows users won't be 
unhappy because they don't get help with .NET issues from Linus.

-- robin

Re: [PATCH] Make "git reset" a builtin. (incomplete)

[Alex Riesen]

David Kastrup, Wed, Aug 22, 2007 19:17:16 +0200:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > And not making the scripts builtins helps Windows users how,
> > exactly?
> 
> Red herring.  The proposal was not to do nothing, but rather give git
> a dedicated scripting language internal to it.  Two suggestions of
> mine with different advantages were git-busybox and Lua.

Different "disadvantages". How do you do pipes and safe inter-program
argument passing in Lua? Portably?
What do you propose to do about gitbox becoming a dependency for
others, who inevitably start using it (why not? It promised to be
portable enough for Git itself!)

> A third one was once proposed by Linus with some code example:
> starting a scripting language from scratch.

It was all about pipes.

Re: [PATCH] Make "git reset" a builtin. (incomplete)

[David Kastrup]

Alex Riesen <raa.lkml@gmail.com> writes:

> David Kastrup, Wed, Aug 22, 2007 19:17:16 +0200:
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> > And not making the scripts builtins helps Windows users how,
>> > exactly?
>> 
>> Red herring.  The proposal was not to do nothing, but rather give git
>> a dedicated scripting language internal to it.  Two suggestions of
>> mine with different advantages were git-busybox and Lua.
>
> Different "disadvantages". How do you do pipes and safe
> inter-program argument passing in Lua? Portably?

Argument quoting would have to depend on the system.  If you implement
that, you should be able to use os.popen and os.system.  However, the
general Lua approach would be to write wrappers around C routines
dealing with the basic git data structures, giving you things like an
iterator over the index and similar.  One would usually not call
executables, but rather functions from a git-specific library.

Instead of stringing this stuff together with pipes, one would string
it together using coroutines (Lua "threads" are strictly synchronous,
about as fast as normal function calls, and a yield/resume rendezvous
passes a value together with control).

So pipes would not be a natural building block, anyway.

> What do you propose to do about gitbox becoming a dependency for
> others, who inevitably start using it (why not? It promised to be
> portable enough for Git itself!)

I don't understand what you mean here.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: [PATCH] Make "git reset" a builtin. (incomplete)

[Alex Riesen]

David Kastrup, Thu, Aug 23, 2007 23:14:20 +0200:
> Alex Riesen <raa.lkml@gmail.com> writes:
> 
> > David Kastrup, Wed, Aug 22, 2007 19:17:16 +0200:
> >> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >> > And not making the scripts builtins helps Windows users how,
> >> > exactly?
> >> 
> >> Red herring.  The proposal was not to do nothing, but rather give git
> >> a dedicated scripting language internal to it.  Two suggestions of
> >> mine with different advantages were git-busybox and Lua.
> >
> > Different "disadvantages". How do you do pipes and safe
> > inter-program argument passing in Lua? Portably?
> 
> Argument quoting would have to depend on the system.  If you implement
> that, you should be able to use os.popen and os.system.  However, the
> general Lua approach would be to write wrappers around C routines
> dealing with the basic git data structures, giving you things like an
> iterator over the index and similar.  One would usually not call
> executables, but rather functions from a git-specific library.
> 
> Instead of stringing this stuff together with pipes, one would string
> it together using coroutines (Lua "threads" are strictly synchronous,
> about as fast as normal function calls, and a yield/resume rendezvous
> passes a value together with control).
> 
> So pipes would not be a natural building block, anyway.

Now that'll be a mess.

> > What do you propose to do about gitbox becoming a dependency for
> > others, who inevitably start using it (why not? It promised to be
> > portable enough for Git itself!)
> 
> I don't understand what you mean here.
> 

Git gets a script language support. People use the script outside of
git and whine when it breaks or gets removed.

Re: [PATCH] Make "git reset" a builtin. (incomplete)

[David Kastrup]

Alex Riesen <raa.lkml@gmail.com> writes:

> David Kastrup, Thu, Aug 23, 2007 23:14:20 +0200:
>> Alex Riesen <raa.lkml@gmail.com> writes:
>> 
>> > David Kastrup, Wed, Aug 22, 2007 19:17:16 +0200:
>> >> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> >> > And not making the scripts builtins helps Windows users how,
>> >> > exactly?
>> >> 
>> >> Red herring.  The proposal was not to do nothing, but rather give git
>> >> a dedicated scripting language internal to it.  Two suggestions of
>> >> mine with different advantages were git-busybox and Lua.
>> >
>> > Different "disadvantages". How do you do pipes and safe
>> > inter-program argument passing in Lua? Portably?
>> 
>> Argument quoting would have to depend on the system.  If you implement
>> that, you should be able to use os.popen and os.system.  However, the
>> general Lua approach would be to write wrappers around C routines
>> dealing with the basic git data structures, giving you things like an
>> iterator over the index and similar.  One would usually not call
>> executables, but rather functions from a git-specific library.
>> 
>> Instead of stringing this stuff together with pipes, one would string
>> it together using coroutines (Lua "threads" are strictly synchronous,
>> about as fast as normal function calls, and a yield/resume rendezvous
>> passes a value together with control).
>> 
>> So pipes would not be a natural building block, anyway.
>
> Now that'll be a mess.

Huh?  Stringing executables together with pipes is quite the same
control flow as stringing coroutines together (except that coroutines
can pass values bidirectionally).  You just write "resume" instead of
"write" on the data producing side, and "yield" instead of "read" on
the data consuming side.

>> > What do you propose to do about gitbox becoming a dependency for
>> > others, who inevitably start using it (why not? It promised to be
>> > portable enough for Git itself!)
>> 
>> I don't understand what you mean here.
>
> Git gets a script language support. People use the script outside of
> git and whine when it breaks or gets removed.

I don't see the problem.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum