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

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 <redacted>
---
 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

Carlos Rica [off-list ref] 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

David Kastrup wrote:

Carlos Rica [off-list ref] writes:

quoted

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

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

Andreas Ericsson [off-list ref] writes:

David Kastrup wrote:

quoted

Carlos Rica [off-list ref] writes:

quoted

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.

quoted

 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

On Wed, Aug 22, 2007 at 04:29:43PM +0200, David Kastrup [off-list ref] 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

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

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 [off-list ref] wrote:

quoted

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

Chris Shoemaker [off-list ref] writes:

On Wed, Aug 22, 2007 at 04:49:43PM +0200, Mike Hommey wrote:

quoted

On Wed, Aug 22, 2007 at 04:29:43PM +0200, David Kastrup [off-list ref] wrote:

quoted

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

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

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

Hi,

On Wed, 22 Aug 2007, Nicolas Pitre wrote:

On Wed, 22 Aug 2007, David Kastrup wrote:

quoted

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.

quoted

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

Johannes Schindelin [off-list ref] writes:

On Wed, 22 Aug 2007, Nicolas Pitre wrote:

quoted

On Wed, 22 Aug 2007, David Kastrup wrote:

quoted

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.

quoted

quoted

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

On Wed, 22 Aug 2007, Johannes Schindelin wrote:

Hi,

On Wed, 22 Aug 2007, Nicolas Pitre wrote:

quoted

On Wed, 22 Aug 2007, David Kastrup wrote:

quoted

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

On Wed, 22 Aug 2007, David Kastrup wrote:

quoted

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

Linus Torvalds [off-list ref] 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

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*.

quoted

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

On 22/08/07, Johannes Schindelin [off-list ref] wrote:

On Wed, 22 Aug 2007, Nicolas Pitre wrote:

quoted

On Wed, 22 Aug 2007, David Kastrup wrote:

quoted

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

On 22/08/07, David Kastrup [off-list ref] wrote:

Johannes Schindelin [off-list ref] writes:

quoted

On Wed, 22 Aug 2007, Nicolas Pitre wrote:

quoted

On Wed, 22 Aug 2007, David Kastrup wrote:

quoted

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

[ 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

On 8/22/07, Nicolas Pitre [off-list ref] 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

On 8/22/07, David Kastrup [off-list ref] wrote:

Andreas Ericsson [off-list ref] writes:

quoted

David Kastrup wrote:

quoted

Carlos Rica [off-list ref] writes:

quoted

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

On Wed, 22 Aug 2007, Nicolas Pitre wrote:

quoted

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.

quoted

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

Hi,

On Wed, 22 Aug 2007, Reece Dunn wrote:

On 22/08/07, Johannes Schindelin [off-list ref] wrote:

quoted

On Wed, 22 Aug 2007, Nicolas Pitre wrote:

quoted

On Wed, 22 Aug 2007, David Kastrup wrote:

quoted

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

Hi,

On Wed, 22 Aug 2007, Reece Dunn wrote:

On 22/08/07, David Kastrup [off-list ref] wrote:

quoted

Johannes Schindelin [off-list ref] writes:

quoted

On Wed, 22 Aug 2007, Nicolas Pitre wrote:

quoted

On Wed, 22 Aug 2007, David Kastrup wrote:

quoted

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.

quoted

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.

quoted

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

Hi,

On Wed, 22 Aug 2007, Linus Torvalds wrote:

On Wed, 22 Aug 2007, Nicolas Pitre wrote:

quoted

Linus wrote:

quoted

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

Hi,

On Wed, 22 Aug 2007, Nicolas Pitre wrote:

On Wed, 22 Aug 2007, Johannes Schindelin wrote:

quoted

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.

quoted

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

On Thu, Aug 23, 2007 at 10:10:20AM +0100, Johannes Schindelin wrote:

quoted

quoted

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

Hi,

On Thu, 23 Aug 2007, Theodore Tso wrote:

On Thu, Aug 23, 2007 at 10:10:20AM +0100, Johannes Schindelin wrote:

quoted

quoted

quoted

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

On 8/23/07, Theodore Tso [off-list ref] 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

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.

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

On 23/08/07, David Tweed [off-list ref] wrote:

On 8/23/07, Theodore Tso [off-list ref] wrote:

quoted

(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

On Thu, 23 Aug 2007, Johannes Schindelin wrote:

Hi,

On Wed, 22 Aug 2007, Nicolas Pitre wrote:

quoted

On Wed, 22 Aug 2007, Johannes Schindelin wrote:

quoted

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

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

David Kastrup, Wed, Aug 22, 2007 19:17:16 +0200:

Johannes Schindelin [off-list ref] writes:

quoted

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.