[PATCH 0/2] Move sequencer

Hi,

This patch series moves the sequencer code which is only useful for builtin
commands, to builtin. This also creates the concept of 'builtin helpers'.

Felipe Contreras (2):
  log-tree: remove dependency from sequencer
  Move sequencer to builtin

 Makefile                           |   9 ++-
 sequencer.c => builtin/sequencer.c | 160 +-----------------------------------
 sequencer.h => builtin/sequencer.h |   4 -
 log-tree.c                         | 161 ++++++++++++++++++++++++++++++++++++-
 log-tree.h                         |   3 +
 5 files changed, 172 insertions(+), 165 deletions(-)
 rename sequencer.c => builtin/sequencer.c (87%)
 rename sequencer.h => builtin/sequencer.h (88%)

-- 
1.8.3.698.g079b096

This code is only useful for cherry-pick and revert built-ins, nothing
else, so let's make it a builtin object, but make sure 'git-sequencer'
is not generated.

Signed-off-by: Felipe Contreras <redacted>
---
 Makefile                           | 9 ++++++---
 sequencer.c => builtin/sequencer.c | 0
 sequencer.h => builtin/sequencer.h | 0
 3 files changed, 6 insertions(+), 3 deletions(-)
 rename sequencer.c => builtin/sequencer.c (100%)
 rename sequencer.h => builtin/sequencer.h (100%)

diff --git a/Makefile b/Makefile
index 03524d0..d28bf7f 100644
--- a/Makefile
+++ b/Makefile

@@ -583,7 +583,8 @@ TEST_PROGRAMS = $(patsubst %,%$X,$(TEST_PROGRAMS_NEED_X))
 
 # List built-in command $C whose implementation cmd_$C() is not in
 # builtin/$C.o but is linked in as part of some other command.
-BUILT_INS += $(patsubst builtin/%.o,git-%$X,$(BUILTIN_OBJS))
+BUILT_INS_OBJS = $(filter-out $(BUILTIN_HELPER_OBJS),$(BUILTIN_OBJS))
+BUILT_INS += $(patsubst builtin/%.o,git-%$X,$(BUILT_INS_OBJS))
 
 BUILT_INS += git-cherry$X
 BUILT_INS += git-cherry-pick$X

@@ -714,7 +715,6 @@ LIB_H += resolve-undo.h
 LIB_H += revision.h
 LIB_H += run-command.h
 LIB_H += send-pack.h
-LIB_H += sequencer.h
 LIB_H += sha1-array.h
 LIB_H += sha1-lookup.h
 LIB_H += shortlog.h

@@ -856,7 +856,6 @@ LIB_OBJS += resolve-undo.o
 LIB_OBJS += revision.o
 LIB_OBJS += run-command.o
 LIB_OBJS += send-pack.o
-LIB_OBJS += sequencer.o
 LIB_OBJS += server-info.o
 LIB_OBJS += setup.o
 LIB_OBJS += sha1-array.o

@@ -894,6 +893,8 @@ LIB_OBJS += wt-status.o
 LIB_OBJS += xdiff-interface.o
 LIB_OBJS += zlib.o
 
+BUILTIN_HELPER_OBJS += builtin/sequencer.o
+
 BUILTIN_OBJS += builtin/add.o
 BUILTIN_OBJS += builtin/annotate.o
 BUILTIN_OBJS += builtin/apply.o

@@ -990,6 +991,8 @@ BUILTIN_OBJS += builtin/verify-pack.o
 BUILTIN_OBJS += builtin/verify-tag.o
 BUILTIN_OBJS += builtin/write-tree.o
 
+BUILTIN_OBJS += $(BUILTIN_HELPER_OBJS)
+
 GITLIBS = $(LIB_FILE) $(XDIFF_LIB)
 EXTLIBS =
 

diff --git a/sequencer.c b/builtin/sequencer.c
similarity index 100%
rename from sequencer.c
rename to builtin/sequencer.c
diff --git a/sequencer.h b/builtin/sequencer.h
similarity index 100%
rename from sequencer.h
rename to builtin/sequencer.h
-- 
1.8.3.698.g079b096

Move the relevant code from sequencer to log-tree. This code is not
specific to sequencer, and this allows the sequencer to move out of
libgit.

Signed-off-by: Felipe Contreras <redacted>
---
 log-tree.c  | 161 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
 log-tree.h  |   3 ++
 sequencer.c | 160 ++---------------------------------------------------------
 sequencer.h |   4 --
 4 files changed, 166 insertions(+), 162 deletions(-)

diff --git a/log-tree.c b/log-tree.c
index 2eb69bc..654f5db 100644
--- a/log-tree.c
+++ b/log-tree.c

@@ -9,10 +9,13 @@
 #include "string-list.h"
 #include "color.h"
 #include "gpg-interface.h"
-#include "sequencer.h"
 #include "line-log.h"
 
+#define APPEND_SIGNOFF_DEDUP (1u << 0)
+
 struct decoration name_decoration = { "object names" };
+const char sign_off_header[] = "Signed-off-by: ";
+static const char cherry_picked_prefix[] = "(cherry picked from commit ";
 
 enum decoration_type {
 	DECORATION_NONE = 0,

@@ -472,6 +475,162 @@ static void show_mergetag(struct rev_info *opt, struct commit *commit)
 	free_commit_extra_headers(to_free);
 }
 
+static int is_rfc2822_line(const char *buf, int len)
+{
+	int i;
+
+	for (i = 0; i < len; i++) {
+		int ch = buf[i];
+		if (ch == ':')
+			return 1;
+		if (!isalnum(ch) && ch != '-')
+			break;
+	}
+
+	return 0;
+}
+
+static int is_cherry_picked_from_line(const char *buf, int len)
+{
+	/*
+	 * We only care that it looks roughly like (cherry picked from ...)
+	 */
+	return len > strlen(cherry_picked_prefix) + 1 &&
+		!prefixcmp(buf, cherry_picked_prefix) && buf[len - 1] == ')';
+}
+
+/*
+ * Returns 0 for non-conforming footer
+ * Returns 1 for conforming footer
+ * Returns 2 when sob exists within conforming footer
+ * Returns 3 when sob exists within conforming footer as last entry
+ */
+int has_conforming_footer(struct strbuf *sb, struct strbuf *sob,
+	int ignore_footer)
+{
+	char prev;
+	int i, k;
+	int len = sb->len - ignore_footer;
+	const char *buf = sb->buf;
+	int found_sob = 0;
+
+	/* footer must end with newline */
+	if (!len || buf[len - 1] != '\n')
+		return 0;
+
+	prev = '\0';
+	for (i = len - 1; i > 0; i--) {
+		char ch = buf[i];
+		if (prev == '\n' && ch == '\n') /* paragraph break */
+			break;
+		prev = ch;
+	}
+
+	/* require at least one blank line */
+	if (prev != '\n' || buf[i] != '\n')
+		return 0;
+
+	/* advance to start of last paragraph */
+	while (i < len - 1 && buf[i] == '\n')
+		i++;
+
+	for (; i < len; i = k) {
+		int found_rfc2822;
+
+		for (k = i; k < len && buf[k] != '\n'; k++)
+			; /* do nothing */
+		k++;
+
+		found_rfc2822 = is_rfc2822_line(buf + i, k - i - 1);
+		if (found_rfc2822 && sob &&
+		    !strncmp(buf + i, sob->buf, sob->len))
+			found_sob = k;
+
+		if (!(found_rfc2822 ||
+		      is_cherry_picked_from_line(buf + i, k - i - 1)))
+			return 0;
+	}
+	if (found_sob == i)
+		return 3;
+	if (found_sob)
+		return 2;
+	return 1;
+}
+
+void append_cherrypick(struct strbuf *msgbuf, struct object *obj)
+{
+	if (!has_conforming_footer(msgbuf, NULL, 0))
+		strbuf_addch(msgbuf, '\n');
+	strbuf_addstr(msgbuf, cherry_picked_prefix);
+	strbuf_addstr(msgbuf, sha1_to_hex(obj->sha1));
+	strbuf_addstr(msgbuf, ")\n");
+}
+
+void append_signoff(struct strbuf *msgbuf, int ignore_footer, unsigned flag)
+{
+	unsigned no_dup_sob = flag & APPEND_SIGNOFF_DEDUP;
+	struct strbuf sob = STRBUF_INIT;
+	int has_footer;
+
+	strbuf_addstr(&sob, sign_off_header);
+	strbuf_addstr(&sob, fmt_name(getenv("GIT_COMMITTER_NAME"),
+				getenv("GIT_COMMITTER_EMAIL")));
+	strbuf_addch(&sob, '\n');
+
+	/*
+	 * If the whole message buffer is equal to the sob, pretend that we
+	 * found a conforming footer with a matching sob
+	 */
+	if (msgbuf->len - ignore_footer == sob.len &&
+	    !strncmp(msgbuf->buf, sob.buf, sob.len))
+		has_footer = 3;
+	else
+		has_footer = has_conforming_footer(msgbuf, &sob, ignore_footer);
+
+	if (!has_footer) {
+		const char *append_newlines = NULL;
+		size_t len = msgbuf->len - ignore_footer;
+
+		if (!len) {
+			/*
+			 * The buffer is completely empty.  Leave foom for
+			 * the title and body to be filled in by the user.
+			 */
+			append_newlines = "\n\n";
+		} else if (msgbuf->buf[len - 1] != '\n') {
+			/*
+			 * Incomplete line.  Complete the line and add a
+			 * blank one so that there is an empty line between
+			 * the message body and the sob.
+			 */
+			append_newlines = "\n\n";
+		} else if (len == 1) {
+			/*
+			 * Buffer contains a single newline.  Add another
+			 * so that we leave room for the title and body.
+			 */
+			append_newlines = "\n";
+		} else if (msgbuf->buf[len - 2] != '\n') {
+			/*
+			 * Buffer ends with a single newline.  Add another
+			 * so that there is an empty line between the message
+			 * body and the sob.
+			 */
+			append_newlines = "\n";
+		} /* else, the buffer already ends with two newlines. */
+
+		if (append_newlines)
+			strbuf_splice(msgbuf, msgbuf->len - ignore_footer, 0,
+				append_newlines, strlen(append_newlines));
+	}
+
+	if (has_footer != 3 && (!no_dup_sob || has_footer != 2))
+		strbuf_splice(msgbuf, msgbuf->len - ignore_footer, 0,
+				sob.buf, sob.len);
+
+	strbuf_release(&sob);
+}
+
 void show_log(struct rev_info *opt)
 {
 	struct strbuf msgbuf = STRBUF_INIT;

diff --git a/log-tree.h b/log-tree.h
index d6ecd4d..1039e49 100644
--- a/log-tree.h
+++ b/log-tree.h

@@ -25,4 +25,7 @@ void load_ref_decorations(int flags);
 void fmt_output_commit(struct strbuf *, struct commit *, struct rev_info *);
 void fmt_output_subject(struct strbuf *, const char *subject, struct rev_info *);
 
+void append_cherrypick(struct strbuf *msgbuf, struct object *obj);
+void append_signoff(struct strbuf *msgbuf, int ignore_footer, unsigned flag);
+
 #endif

diff --git a/sequencer.c b/sequencer.c
index ab6f8a7..e92e039 100644
--- a/sequencer.c
+++ b/sequencer.c

@@ -14,94 +14,10 @@
 #include "merge-recursive.h"
 #include "refs.h"
 #include "argv-array.h"
+#include "log-tree.h"
 
 #define GIT_REFLOG_ACTION "GIT_REFLOG_ACTION"
 
-const char sign_off_header[] = "Signed-off-by: ";
-static const char cherry_picked_prefix[] = "(cherry picked from commit ";
-
-static int is_rfc2822_line(const char *buf, int len)
-{
-	int i;
-
-	for (i = 0; i < len; i++) {
-		int ch = buf[i];
-		if (ch == ':')
-			return 1;
-		if (!isalnum(ch) && ch != '-')
-			break;
-	}
-
-	return 0;
-}
-
-static int is_cherry_picked_from_line(const char *buf, int len)
-{
-	/*
-	 * We only care that it looks roughly like (cherry picked from ...)
-	 */
-	return len > strlen(cherry_picked_prefix) + 1 &&
-		!prefixcmp(buf, cherry_picked_prefix) && buf[len - 1] == ')';
-}
-
-/*
- * Returns 0 for non-conforming footer
- * Returns 1 for conforming footer
- * Returns 2 when sob exists within conforming footer
- * Returns 3 when sob exists within conforming footer as last entry
- */
-static int has_conforming_footer(struct strbuf *sb, struct strbuf *sob,
-	int ignore_footer)
-{
-	char prev;
-	int i, k;
-	int len = sb->len - ignore_footer;
-	const char *buf = sb->buf;
-	int found_sob = 0;
-
-	/* footer must end with newline */
-	if (!len || buf[len - 1] != '\n')
-		return 0;
-
-	prev = '\0';
-	for (i = len - 1; i > 0; i--) {
-		char ch = buf[i];
-		if (prev == '\n' && ch == '\n') /* paragraph break */
-			break;
-		prev = ch;
-	}
-
-	/* require at least one blank line */
-	if (prev != '\n' || buf[i] != '\n')
-		return 0;
-
-	/* advance to start of last paragraph */
-	while (i < len - 1 && buf[i] == '\n')
-		i++;
-
-	for (; i < len; i = k) {
-		int found_rfc2822;
-
-		for (k = i; k < len && buf[k] != '\n'; k++)
-			; /* do nothing */
-		k++;
-
-		found_rfc2822 = is_rfc2822_line(buf + i, k - i - 1);
-		if (found_rfc2822 && sob &&
-		    !strncmp(buf + i, sob->buf, sob->len))
-			found_sob = k;
-
-		if (!(found_rfc2822 ||
-		      is_cherry_picked_from_line(buf + i, k - i - 1)))
-			return 0;
-	}
-	if (found_sob == i)
-		return 3;
-	if (found_sob)
-		return 2;
-	return 1;
-}
-
 static void remove_sequencer_state(void)
 {
 	struct strbuf seq_dir = STRBUF_INIT;

@@ -578,13 +494,8 @@ static int do_pick_commit(struct commit *commit, struct replay_opts *opts)
 			strbuf_addstr(&msgbuf, p);
 		}
 
-		if (opts->record_origin) {
-			if (!has_conforming_footer(&msgbuf, NULL, 0))
-				strbuf_addch(&msgbuf, '\n');
-			strbuf_addstr(&msgbuf, cherry_picked_prefix);
-			strbuf_addstr(&msgbuf, sha1_to_hex(commit->object.sha1));
-			strbuf_addstr(&msgbuf, ")\n");
-		}
+		if (opts->record_origin)
+			append_cherrypick(&msgbuf, &commit->object);
 	}
 
 	if (!opts->strategy || !strcmp(opts->strategy, "recursive") || opts->action == REPLAY_REVERT) {

@@ -1123,68 +1034,3 @@ int sequencer_pick_revisions(struct replay_opts *opts)
 	save_opts(opts);
 	return pick_commits(todo_list, opts);
 }
-
-void append_signoff(struct strbuf *msgbuf, int ignore_footer, unsigned flag)
-{
-	unsigned no_dup_sob = flag & APPEND_SIGNOFF_DEDUP;
-	struct strbuf sob = STRBUF_INIT;
-	int has_footer;
-
-	strbuf_addstr(&sob, sign_off_header);
-	strbuf_addstr(&sob, fmt_name(getenv("GIT_COMMITTER_NAME"),
-				getenv("GIT_COMMITTER_EMAIL")));
-	strbuf_addch(&sob, '\n');
-
-	/*
-	 * If the whole message buffer is equal to the sob, pretend that we
-	 * found a conforming footer with a matching sob
-	 */
-	if (msgbuf->len - ignore_footer == sob.len &&
-	    !strncmp(msgbuf->buf, sob.buf, sob.len))
-		has_footer = 3;
-	else
-		has_footer = has_conforming_footer(msgbuf, &sob, ignore_footer);
-
-	if (!has_footer) {
-		const char *append_newlines = NULL;
-		size_t len = msgbuf->len - ignore_footer;
-
-		if (!len) {
-			/*
-			 * The buffer is completely empty.  Leave foom for
-			 * the title and body to be filled in by the user.
-			 */
-			append_newlines = "\n\n";
-		} else if (msgbuf->buf[len - 1] != '\n') {
-			/*
-			 * Incomplete line.  Complete the line and add a
-			 * blank one so that there is an empty line between
-			 * the message body and the sob.
-			 */
-			append_newlines = "\n\n";
-		} else if (len == 1) {
-			/*
-			 * Buffer contains a single newline.  Add another
-			 * so that we leave room for the title and body.
-			 */
-			append_newlines = "\n";
-		} else if (msgbuf->buf[len - 2] != '\n') {
-			/*
-			 * Buffer ends with a single newline.  Add another
-			 * so that there is an empty line between the message
-			 * body and the sob.
-			 */
-			append_newlines = "\n";
-		} /* else, the buffer already ends with two newlines. */
-
-		if (append_newlines)
-			strbuf_splice(msgbuf, msgbuf->len - ignore_footer, 0,
-				append_newlines, strlen(append_newlines));
-	}
-
-	if (has_footer != 3 && (!no_dup_sob || has_footer != 2))
-		strbuf_splice(msgbuf, msgbuf->len - ignore_footer, 0,
-				sob.buf, sob.len);
-
-	strbuf_release(&sob);
-}

diff --git a/sequencer.h b/sequencer.h
index 1fc22dc..c341918 100644
--- a/sequencer.h
+++ b/sequencer.h

@@ -6,8 +6,6 @@
 #define SEQ_TODO_FILE	"sequencer/todo"
 #define SEQ_OPTS_FILE	"sequencer/opts"
 
-#define APPEND_SIGNOFF_DEDUP (1u << 0)
-
 enum replay_action {
 	REPLAY_REVERT,
 	REPLAY_PICK

@@ -50,6 +48,4 @@ int sequencer_pick_revisions(struct replay_opts *opts);
 
 extern const char sign_off_header[];
 
-void append_signoff(struct strbuf *msgbuf, int ignore_footer, unsigned flag);
-
 #endif

-- 
1.8.3.698.g079b096

On Sat, Jun 8, 2013 at 5:16 AM, Felipe Contreras
[off-list ref] wrote:

This code is only useful for cherry-pick and revert built-ins, nothing
else, so let's make it a builtin object, but make sure 'git-sequencer'
is not generated.

As you can see, the convention is builtin/foo.c corresponds to git-foo
(and maybe more). Why make an exception for sequencer? What do we gain
from this? A lot of code in libgit.a is only used by builtin commands,
e.g. fetch-pack.c, should we move it to? I ask because I moved
fetch-pack from builtin out because of linking issues and I don't want
the same happen to sequencer.c.
-- 
Duy

Felipe Contreras wrote:

 sequencer.c => builtin/sequencer.c | 160 +-----------------------------------
 sequencer.h => builtin/sequencer.h |   4 -

Why exactly?  The plan was to unify continuation semantics, and get
all the continuation-commands to use the sequencer.  That clearly
hasn't materialized, but I don't know what this move buys us.

On Fri, Jun 7, 2013 at 9:35 PM, Duy Nguyen [off-list ref] wrote:

On Sat, Jun 8, 2013 at 5:16 AM, Felipe Contreras
[off-list ref] wrote:

quoted

This code is only useful for cherry-pick and revert built-ins, nothing
else, so let's make it a builtin object, but make sure 'git-sequencer'
is not generated.

As you can see, the convention is builtin/foo.c corresponds to git-foo
(and maybe more). Why make an exception for sequencer?

Why not?

What do we gain from this?

Organization.

A lot of code in libgit.a is only used by builtin commands,
e.g. fetch-pack.c, should we move it to?

Yes.

I ask because I moved
fetch-pack from builtin out because of linking issues and I don't want
the same happen to sequencer.c.

I'm sure those linking issues can be solved.

I don't see why libgit.a couldn't eventually be the same as libgit2.
We need better organization tough (e.g. builtins/lib.a).

If you are arguing favor of a more messy setup, then we should link
all the builtin/*.o to libgit.a, because the current situation just
doesn't cut it.

For example, init_copy_notes_for_rewrite() cannot be accessed by
sequencer.c, and while it's possible to move that function (and
others) to libgit.a, it doesn't make sense, because it can only be
used by builtins.

-- 
Felipe Contreras

On Fri, Jun 7, 2013 at 10:35 PM, Ramkumar Ramachandra
[off-list ref] wrote:

Felipe Contreras wrote:

quoted

 sequencer.c => builtin/sequencer.c | 160 +-----------------------------------
 sequencer.h => builtin/sequencer.h |   4 -

Why exactly?  The plan was to unify continuation semantics, and get
all the continuation-commands to use the sequencer.  That clearly
hasn't materialized, but I don't know what this move buys us.

So? The sequencer is only used by builtin commands, and other
continuation commands are also builtins.

The sequencer needs to access methods from builtins/*.o, so unless you
propose that libgit.a includes all the objects in builtins/*.o, this
is the way to go.

-- 
Felipe Contreras

On Sat, Jun 8, 2013 at 5:14 PM, Felipe Contreras
[off-list ref] wrote:

On Fri, Jun 7, 2013 at 9:35 PM, Duy Nguyen [off-list ref] wrote:

quoted

On Sat, Jun 8, 2013 at 5:16 AM, Felipe Contreras
[off-list ref] wrote:

quoted

This code is only useful for cherry-pick and revert built-ins, nothing
else, so let's make it a builtin object, but make sure 'git-sequencer'
is not generated.

As you can see, the convention is builtin/foo.c corresponds to git-foo
(and maybe more). Why make an exception for sequencer?

Why not?

And while we are at "why not", why don't you fork git?

quoted

I ask because I moved
fetch-pack from builtin out because of linking issues and I don't want
the same happen to sequencer.c.

I'm sure those linking issues can be solved.

Yeah, I scratched my head for hours and finally gave in. Maybe you are
better at the toolchain than me.

I don't see why libgit.a couldn't eventually be the same as libgit2.
We need better organization tough (e.g. builtins/lib.a).

If you are arguing favor of a more messy setup, then we should link
all the builtin/*.o to libgit.a, because the current situation just
doesn't cut it.

For example, init_copy_notes_for_rewrite() cannot be accessed by
sequencer.c, and while it's possible to move that function (and
others) to libgit.a, it doesn't make sense, because it can only be
used by builtins.

libgit.a is just a way of grouping a bunch of objects together, not a
real library and not meant to be. If you aim something more organized,
please show at least a roadmap what to move where.
--
Duy

On Sat, Jun 8, 2013 at 6:42 AM, Duy Nguyen [off-list ref] wrote:

On Sat, Jun 8, 2013 at 5:14 PM, Felipe Contreras
[off-list ref] wrote:

quoted

On Fri, Jun 7, 2013 at 9:35 PM, Duy Nguyen [off-list ref] wrote:

quoted

On Sat, Jun 8, 2013 at 5:16 AM, Felipe Contreras
[off-list ref] wrote:

quoted

This code is only useful for cherry-pick and revert built-ins, nothing
else, so let's make it a builtin object, but make sure 'git-sequencer'
is not generated.

As you can see, the convention is builtin/foo.c corresponds to git-foo
(and maybe more). Why make an exception for sequencer?

Why not?

And while we are at "why not", why don't you fork git?

That's not an answer.

quoted

quoted

I ask because I moved
fetch-pack from builtin out because of linking issues and I don't want
the same happen to sequencer.c.

I'm sure those linking issues can be solved.

Yeah, I scratched my head for hours and finally gave in. Maybe you are
better at the toolchain than me.

I gave it a try, but transport.c needs fetch_pack(), and transport
does belong in libgit.a, so fetch_pack() belongs there too.

This is not the case for sequencer.c.

quoted

I don't see why libgit.a couldn't eventually be the same as libgit2.
We need better organization tough (e.g. builtins/lib.a).

If you are arguing favor of a more messy setup, then we should link
all the builtin/*.o to libgit.a, because the current situation just
doesn't cut it.

For example, init_copy_notes_for_rewrite() cannot be accessed by
sequencer.c, and while it's possible to move that function (and
others) to libgit.a, it doesn't make sense, because it can only be
used by builtins.

libgit.a is just a way of grouping a bunch of objects together, not a
real library

That's what a library is.

and not meant to be. If you aim something more organized,
please show at least a roadmap what to move where.

I already did that; we move code from libgit.a to builtin/*.o until
libgit.a == libgit2. Done.

-- 
Felipe Contreras

On Sat, Jun 8, 2013 at 7:25 PM, Felipe Contreras
[off-list ref] wrote:

On Sat, Jun 8, 2013 at 6:42 AM, Duy Nguyen [off-list ref] wrote:

quoted

On Sat, Jun 8, 2013 at 5:14 PM, Felipe Contreras
[off-list ref] wrote:

quoted

On Fri, Jun 7, 2013 at 9:35 PM, Duy Nguyen [off-list ref] wrote:

quoted

On Sat, Jun 8, 2013 at 5:16 AM, Felipe Contreras
[off-list ref] wrote:

quoted

This code is only useful for cherry-pick and revert built-ins, nothing
else, so let's make it a builtin object, but make sure 'git-sequencer'
is not generated.

As you can see, the convention is builtin/foo.c corresponds to git-foo
(and maybe more). Why make an exception for sequencer?

Why not?

And while we are at "why not", why don't you fork git?

That's not an answer.

Neither is "Why not?"

quoted

and not meant to be. If you aim something more organized,
please show at least a roadmap what to move where.

I already did that; we move code from libgit.a to builtin/*.o

what code besides sequencer.c?

until libgit.a == libgit2. Done.

Read up about the introduction of libgit2, why it was created in the
first place instead of moving a few files around renaming libgit.a to
libgit2.a. Unless you have a different definition of "==" than I do.
--
Duy

Duy Nguyen wrote:

quoted

until libgit.a == libgit2. Done.

Read up about the introduction of libgit2, why it was created in the
first place instead of moving a few files around renaming libgit.a to
libgit2.a. Unless you have a different definition of "==" than I do.

As far as I know, there was never an extensive on-list discussion
about why git.git cannot be lib'ified.  The first appearance of
libgit2 is here [1].  I briefly read through the initial history of
libgit2.git too, but I cannot find a single discussion detailing why
lib'ifying git.git is fundamentally unworkable (there's some vague
mention of "global state baggage" and "presence of die()", but that's
about it).  Unless you can point to some detailed discussions, or
write out a really good reason yourself, I don't think there's any
harm in letting fc try.  Ofcourse, he still indicated any sort of plan
yet, and I'm also waiting for that.

[1]: http://thread.gmane.org/gmane.comp.version-control.git/99608

On Sat, Jun 8, 2013 at 7:55 PM, Ramkumar Ramachandra [off-list ref] wrote:

Duy Nguyen wrote:

quoted

quoted

until libgit.a == libgit2. Done.

Read up about the introduction of libgit2, why it was created in the
first place instead of moving a few files around renaming libgit.a to
libgit2.a. Unless you have a different definition of "==" than I do.

As far as I know, there was never an extensive on-list discussion
about why git.git cannot be lib'ified.  The first appearance of
libgit2 is here [1].  I briefly read through the initial history of
libgit2.git too, but I cannot find a single discussion detailing why
lib'ifying git.git is fundamentally unworkable (there's some vague
mention of "global state baggage" and "presence of die()", but that's
about it).  Unless you can point to some detailed discussions, or
write out a really good reason yourself, I don't think there's any
harm in letting fc try.  Ofcourse, he still indicated any sort of plan
yet, and I'm also waiting for that.

[1]: http://thread.gmane.org/gmane.comp.version-control.git/99608

Hm.. I thought Shawn wrote a bit more in that mail. Apparently I was
wrong. I think it's discuessed in the list from time to time
(otherwise I wouldn't know) but I don't keep bookmarks.

I _think_ the reason is because git was never written as a reusable
library in mind from the beginning.  So global states and die() exist.
Worse, "run once and let the OS clean eveything up at process exit"
leads to some deliberate memory leak if it's made a library. See
alloc.c for example. The internal API is not really designed to be
usuable/stable as a library. All of these made it very hard to convert
the current code base into a true library. So the effort was put into
creating a new library instead, copying code from git code base over
when possible.

So instead of redoing it again, I think it's better that you help
libgit2 guys improve it to the extend that git commands can be easily
reimplemented. Then bring up the discussion about using libgit2 in C
Git again.
--
Duy

On Sat, Jun 8, 2013 at 7:34 AM, Duy Nguyen [off-list ref] wrote:

On Sat, Jun 8, 2013 at 7:25 PM, Felipe Contreras
[off-list ref] wrote:

quoted

On Sat, Jun 8, 2013 at 6:42 AM, Duy Nguyen [off-list ref] wrote:

quoted

On Sat, Jun 8, 2013 at 5:14 PM, Felipe Contreras
[off-list ref] wrote:

quoted

On Fri, Jun 7, 2013 at 9:35 PM, Duy Nguyen [off-list ref] wrote:

quoted

On Sat, Jun 8, 2013 at 5:16 AM, Felipe Contreras
[off-list ref] wrote:

quoted

This code is only useful for cherry-pick and revert built-ins, nothing
else, so let's make it a builtin object, but make sure 'git-sequencer'
is not generated.

As you can see, the convention is builtin/foo.c corresponds to git-foo
(and maybe more). Why make an exception for sequencer?

Why not?

And while we are at "why not", why don't you fork git?

That's not an answer.

Neither is "Why not?"

The answer is the rest of the e-mail.

quoted

quoted

and not meant to be. If you aim something more organized,
please show at least a roadmap what to move where.

I already did that; we move code from libgit.a to builtin/*.o

what code besides sequencer.c?

A roadmap doesn't require code. If you truly think that there's
nothing else that is specific to builtins; alias.c.

quoted

until libgit.a == libgit2. Done.

Read up about the introduction of libgit2, why it was created in the
first place instead of moving a few files around renaming libgit.a to
libgit2.a. Unless you have a different definition of "==" than I do.

Are you being obtuse on purpose? It doesn't matter how different
libgit.a and libgit2 currently are, there's always a path from one
code-base to another. Unless libgit2 has code for builtin commands,
the first step would invariably be to move the code that is specific
for builtins to builtin/*.o.

-- 
Felipe Contreras

On Sat, Jun 8, 2013 at 8:15 AM, Duy Nguyen [off-list ref] wrote:

So instead of redoing it again, I think it's better that you help
libgit2 guys improve it to the extend that git commands can be easily
reimplemented. Then bring up the discussion about using libgit2 in C
Git again.

There's no reason not to move libgit2 closer to libgit.a, and libgit.a
closer to libgit2, both at the same time. I have rewritten a lot of
code using this strategy.

-- 
Felipe Contreras

Duy Nguyen wrote:

I _think_ the reason is because git was never written as a reusable
library in mind from the beginning.

We cannot reverse-engineer intents, but I tend to agree with this.  My
question is: so what?  Is it impossible to do now?

So global states and die() exist.
Worse, "run once and let the OS clean eveything up at process exit"
leads to some deliberate memory leak if it's made a library. See
alloc.c for example. The internal API is not really designed to be
usuable/stable as a library. All of these made it very hard to convert
the current code base into a true library. So the effort was put into
creating a new library instead, copying code from git code base over
when possible.

I'm not saying that we can convert libgit.a into something that's
usable as a long-running process by production servers tomorrow.  All
I'm saying is that it might be possible to get ruby (and possibly
other languages) to call into git-core, to make scripting more sane
than shell-spawning everything like brutes.  I think this is what fc
is aiming at, atleast in the foreseeable future.

As far as long-running server-side implementations go, I think jgit is
the way forward (sop is more interested in that now, I believe).
libgit2 might work for GitHub now, but I don't know if they will be
forced to move to the jvm in the future.

So instead of redoing it again, I think it's better that you help
libgit2 guys improve it to the extend that git commands can be easily
reimplemented. Then bring up the discussion about using libgit2 in C
Git again.

Please look at the code in libgit2.git briefly.  It's _very_ different
from git.git, and the amount of glue code that would be needed to
piece them together is unfathomable.

There are no git.git contributors committing to libgit2.git, or
vice-versa.  libgit2 is primarily developed by vmg, cmn, and (more
recently) rb.  It's quite an active project that's diverging from the
git.git design with every passing day.

On Sat, Jun 8, 2013 at 8:34 AM, Ramkumar Ramachandra [off-list ref] wrote:

Duy Nguyen wrote:

quoted

I _think_ the reason is because git was never written as a reusable
library in mind from the beginning.

We cannot reverse-engineer intents, but I tend to agree with this.  My
question is: so what?  Is it impossible to do now?

Nothing is impossible.

My feeling is that no Git developers are interested in libgit2, so the
idea of me contributing to libgit2 and leave libgit.a alone is more
like a "we don't want no reorganization". Then wait until libgit2 is
ready before considering using it in Git's core, but that's never
going to happen if we don't first start to bring the two code-bases
closer together.

IOW; sweep the issue under the carpet.

-- 
Felipe Contreras

On Sat, Jun 8, 2013 at 8:34 PM, Ramkumar Ramachandra [off-list ref] wrote:

I'm not saying that we can convert libgit.a into something that's
usable as a long-running process by production servers tomorrow.  All
I'm saying is that it might be possible to get ruby (and possibly
other languages) to call into git-core, to make scripting more sane
than shell-spawning everything like brutes.  I think this is what fc
is aiming at, atleast in the foreseeable future.

It's technically possible. You can already call into libgit.a as fc
demonstrated with his ruby binding. Assuming that you are willing to
dig in and fix all the problems (in a non-intrusive way) when a call
into libgit.a does not work, there's still API issue. Do we want to
freeze libgit.a API so that scripts will not be audited and changed
unncessarily? Freezing the API at cmd_* level loses a lot of
flexibility. Freezing at lower level may prevent us from making some
changes. I still think that binding new languages to a clean library
like libgit2 is better than to libgit.a. Just thinking of what might
work and what might not is already a headache.
-- 
Duy

On Sat, Jun 8, 2013 at 9:10 AM, Duy Nguyen [off-list ref] wrote:

Do we want to
freeze libgit.a API so that scripts will not be audited and changed
unncessarily?

No. Until we ship libgit.so the API remains internal, and free to change.

I still think that binding new languages to a clean library
like libgit2 is better than to libgit.a. Just thinking of what might
work and what might not is already a headache.

Let the code speak. Show me a script in any language that does
something useful using libgit2, doing the equivalent to at least a
couple of 'git foo' commands.

-- 
Felipe Contreras

Duy Nguyen wrote:

libgit.a is just a way of grouping a bunch of objects together, not a
real library and not meant to be. If you aim something more organized,
please show at least a roadmap what to move where.

Exactly.  There are some rough plans I would like to help with in the
direction of a more organized source tree (so "ls" output can be less
intimidating --- see Nico Pitre's mail on this a while ago for more
hints), but randomly moving files one at a time to builtin/ destroys
consistency and just makes things *worse*.  So if you'd like to work
on this, you'll need to start with a description of the endpoint, to
help people work with you to ensure it is something consistent and
usable.

Actually, Felipe, I doubt that would work well.  This project requires
understanding how a variety of people use the git source code, which
requires listening carefully to them and not alienating them so you
can find out what they need.  Someone good at moderating a discussion
could do that on-list, but based on my experience of how threads with
you go, a better strategy might be to cultivate a wiki page somewhere
with a plan and give it some time (a month, maybe) to collect input.

NAK to changing the meaning of builtin/ to "built-in commands, plus
sequencer", which seriously hurts consistency.

Sincerely,
Jonathan

On Sat, Jun 8, 2013 at 11:49 AM, Jonathan Nieder [off-list ref] wrote:

Duy Nguyen wrote:

quoted

libgit.a is just a way of grouping a bunch of objects together, not a
real library and not meant to be. If you aim something more organized,
please show at least a roadmap what to move where.

Exactly.  There are some rough plans I would like to help with in the
direction of a more organized source tree (so "ls" output can be less
intimidating --- see Nico Pitre's mail on this a while ago for more
hints), but randomly moving files one at a time to builtin/ destroys
consistency and just makes things *worse*.  So if you'd like to work
on this, you'll need to start with a description of the endpoint, to
help people work with you to ensure it is something consistent and
usable.

So lets stash everything together.

--- a/Makefile
+++ b/Makefile

@@ -990,6 +990,8 @@ BUILTIN_OBJS += builtin/verify-pack.o
 BUILTIN_OBJS += builtin/verify-tag.o
 BUILTIN_OBJS += builtin/write-tree.o

+LIB_OBJS += $(BUILTIN_OBJS)
+
 GITLIBS = $(LIB_FILE) $(XDIFF_LIB)
 EXTLIBS =

@@ -1712,9 +1714,9 @@ git.sp git.s git.o: EXTRA_CPPFLAGS = \
        '-DGIT_MAN_PATH="$(mandir_relative_SQ)"' \
        '-DGIT_INFO_PATH="$(infodir_relative_SQ)"'

-git$X: git.o GIT-LDFLAGS $(BUILTIN_OBJS) $(GITLIBS)
+git$X: git.o GIT-LDFLAGS $(GITLIBS)
        $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ git.o \
-               $(BUILTIN_OBJS) $(ALL_LDFLAGS) $(LIBS)
+               $(ALL_LDFLAGS) $(LIBS)

 help.sp help.s help.o: common-cmds.h

@@ -1892,7 +1894,7 @@ VCSSVN_OBJS += vcs-svn/svndiff.o
 VCSSVN_OBJS += vcs-svn/svndump.o

 TEST_OBJS := $(patsubst test-%$X,test-%.o,$(TEST_PROGRAMS))
-OBJECTS := $(LIB_OBJS) $(BUILTIN_OBJS) $(PROGRAM_OBJS) $(TEST_OBJS) \
+OBJECTS := $(LIB_OBJS) $(PROGRAM_OBJS) $(TEST_OBJS) \
        $(XDIFF_OBJS) \
        $(VCSSVN_OBJS) \
        git.o

And stop any delusions that libgit.a has any meaning at all, and along
the way get rid of any hopes of ever having an official public library
similar to libgit2.

Actually, Felipe, I doubt that would work well.  This project requires
understanding how a variety of people use the git source code, which
requires listening carefully to them and not alienating them so you
can find out what they need.

My patch covers every need. Nobody has come forward with a reason not
to organize the object files. Everything works after my patch the same
way it has worked before.

Someone good at moderating a discussion
could do that on-list, but based on my experience of how threads with
you go, a better strategy might be to cultivate a wiki page somewhere
with a plan and give it some time (a month, maybe) to collect input.

This has nothing to do with better strategy, it has everything to do
with gut feelings and tradition. Not reasons.

NAK to changing the meaning of builtin/ to "built-in commands, plus
sequencer", which seriously hurts consistency.

Then apply the patch above and stop wasting our time with a "library".
Git is nothing but a bunch of disorganized object files, all squashed
together, there's no library, nor will ever be; libgit.a is a
misnomer.

-- 
Felipe Contreras

Felipe Contreras wrote:

This has nothing to do with better strategy, it has everything to do
with gut feelings and tradition. Not reasons.

I try to help you, and you insult me.  I don't think this is worth it.

If I were managing this list, I would ban mails from you, since this
discussion style does more harm than good.  If I were maintaining git,
I'd still accept your contributions, waiting until times when I had
more patience to read them and sending them to the list when
appropriate to get more feedback.  Of course I am neither managing the
list nor maintaining git, but I thought I should put that out there...

Annoyed,
Jonathan

On Sat, Jun 8, 2013 at 12:34 PM, Jonathan Nieder [off-list ref] wrote:

Felipe Contreras wrote:

quoted

This has nothing to do with better strategy, it has everything to do
with gut feelings and tradition. Not reasons.

I try to help you, and you insult me.  I don't think this is worth it.

I didn't direct that comment to you; you took the pellet and threw it
at yourself.

Moreover, following gut feelings and traditions without reason is not
an insult, that's what human beings do.

-- 
Felipe Contreras

On Sat, Jun 8, 2013 at 12:34 PM, Jonathan Nieder [off-list ref] wrote:

If I were managing this list, I would ban mails from you, since this
discussion style does more harm than good.

There is a nice motto around: "Talk is cheap. Show me the code."

Just the past three months I've probably done more work than anybody
else[1], and you would ban me because you don't like my words? At the
end of the day the project has benefited from my patches, and a wise
maintainer would do what is best for the project. If you don't like my
words, ignore them.

Taking things personal is more often than not the wrong thing to do.
Specially when they were not even directed to you.

[1] https://www.ohloh.net/p/git/contributors?query=&sort=commits_12_mo

-- 
Felipe Contreras

Felipe Contreras wrote:

Just the past three months I've probably done more work than anybody
else[1], and you would ban me because you don't like my words?

Definitely, yes.  Even if you look at the impact on code alone and
don't care about the people, destroying a collegial work environment
is harmful enough to the code to outweigh the (admittedly often
useful) patches.

But I am not the mailing list owner, so what I would do is not too
important.

Jonathan

On Sat, Jun 8, 2013 at 8:40 PM, Jonathan Nieder [off-list ref] wrote:

Felipe Contreras wrote:

quoted

Just the past three months I've probably done more work than anybody
else[1], and you would ban me because you don't like my words?

Definitely, yes.  Even if you look at the impact on code alone and
don't care about the people, destroying a collegial work environment
is harmful enough to the code to outweigh the (admittedly often
useful) patches.

A collegial work environment is overrated, and proof of that the Linux
kernel, where honest and straight talk is the bread and butter of the
mailing list. And the Linux kernel is the most successful software
project in history by far. It's code that speaks.

And I have not destroyed anything, except maybe your sense of fairness
and balance when reviewing my patches, but that is not my fault.

-- 
Felipe Contreras

Felipe Contreras wrote:

A collegial work environment is overrated, and proof of that the Linux
kernel, where honest and straight talk is the bread and butter of the
mailing list.

An aside, since it doesn't bear too much on the topic at hand:

For what it's worth, in my experience the people working on the kernel
are quite sensible and friendly on-list.  Probably you are referring
to some high-profile cases of flames, which perhaps I have just been
lucky to avoid.  I do not think the way the list works normally is a
counterexample to common decency being useful.

So no, I don't find "But they are mean, and look how well they are
doing!" to be a compelling argument here.

Jonathan

On Sat, Jun 8, 2013 at 10:21 PM, Jonathan Nieder [off-list ref] wrote:

Felipe Contreras wrote:

quoted

A collegial work environment is overrated, and proof of that the Linux
kernel, where honest and straight talk is the bread and butter of the
mailing list.

An aside, since it doesn't bear too much on the topic at hand:

For what it's worth, in my experience the people working on the kernel
are quite sensible and friendly on-list.

They are professional. When they need to be straight-forward, they
are, even if that hurts the feelings of the colleagues.

Probably you are referring to some high-profile cases of flames,

No, I'm not. Heated discussions happen all the time, specially when
the issue at hand is important.

I do not think the way the list works normally is a
counterexample to common decency being useful.

Of course you wouldn't, but you are purposely ignoring the facts.

The Linux kernel mailing lists concentrates on *the code*; he who
writes the code has a voice, he who only has words doesn't. Personal
beefs are not relevant. When there's something horribly wrong with the
code, so are the responses.

So no, I don't find "But they are mean, and look how well they are
doing!" to be a compelling argument here.

Because you dismiss the premise a priori.

-- 
Felipe Contreras

On Sat, Jun 08, 2013 at 09:20:54AM -0500, Felipe Contreras wrote:

Let the code speak. Show me a script in any language that does
something useful using libgit2, doing the equivalent to at least a
couple of 'git foo' commands.

Sorry that I cannot show you the source code, but you may interested to
know that libgit2 powers:

  1. Microsoft's "Visual Studio Tools for Git" plugin

  2. GitHub's native Mac and Windows clients (using Objective C and C#
     bindings); some operations still shell out to git where the
     functionality is not yet implemented in libgit2.

  3. Parts of the web view of GitHub.com via Ruby bindings

It is definitely not feature-complete when compared with git.git. But I
do think it is in a state that is usable for quite a few tasks.

-Peff

On Sat, Jun 08, 2013 at 09:17:56PM -0500, Felipe Contreras wrote:

quoted

Definitely, yes.  Even if you look at the impact on code alone and
don't care about the people, destroying a collegial work environment
is harmful enough to the code to outweigh the (admittedly often
useful) patches.

A collegial work environment is overrated, and proof of that the Linux
kernel, where honest and straight talk is the bread and butter of the
mailing list. And the Linux kernel is the most successful software
project in history by far. It's code that speaks.

Sorry, but I don't agree, and I want to publicly state my opinion so
that Jonathan (and other bystanders on the list) knows that he is not
alone in his opinions.

I have consistently found your demeanor on the list to be very
unfriendly and difficult to work with. It is one thing to have honest
and straight talk, and another thing to be obstinate, unmindful of
feedback (both with respect to technical details, as well as to
communication styles), and disrespectful of other people.

You have accused others of assuming you make comments in bad faith.
Perhaps it is true that you are very pleasant and easy to work with in
person, but in my opinion that is not the case, at least by email. I may
be wrong, of course, and I certainly do not claim to be perfect myself.
But I find it telling that many of the list participants seem to have
had conflicts with you, and not with anyone else. So perhaps you may
want to reconsider your style of communication.

Unlike Jonathan, I would not ban you from the list. I do not believe in
censoring anybody who is not a direct and constant nuisance (like a
spammer). But personally I have a limited capacity for discussion with
you, as it seems to have a knack for going back and forth, consuming a
lot of time, and ending nowhere productive.

It is certainly your choice about how you will communicate. But likewise
it is the choice of readers and reviewers to choose how much of their
time to give to your writings.

-Peff

Jeff King wrote:

Sorry that I cannot show you the source code, but you may interested to
know that libgit2 powers:

Yes, I'm well aware of these: libgit2 is LGPL, because of which these
three proprietary applications have been made possible.  Isn't it
completely orthogonal to the discussion about how best to lib'ify
git.git though?  From what I understand, fc is not interested in
building another application leveraging libgit.a or libgit2; he's
interested in improving libgit.a and getting more users.

It is definitely not feature-complete when compared with git.git. But I
do think it is in a state that is usable for quite a few tasks.

What is this task you are discussing?  fc is talking about improving
libgit.a and getting an official git library with many users.  Answer
the question: what should we do now?

1. Start moving irrelevant code out of libgit.a, and use inspiration
from libgit2 to improve it (this might or might not involve taking
code from libgit2).  Get _users_ of libgit.a via ruby bindings (or
something) asap, so it puts pressure on fixing it.

2. Wait indefinitely until libgit2.git magically becomes ready to be
usable by git.git as-is.  Then throw libgit.a out the window, and
rewrite git.git to call into libgit2.a instead [*1*].

What you seem to be saying is "3. Work on libgit2 (and abandon
git.git?)" [*2*], or worse: 2.  fc is in favor of 1.  Unless you are
in favor of _not_ improving libgit.a, don't stand in his way: you
might personally think that it is a difficult (or impossible) task,
but that's no reason to stop fc from trying.  I personally think his
goal is admirable, and I'm nobody to say that it cannot be done:
therefore, I will review his patches and help him in whatever little
way I can.

[Footnote]

*1* You have dismissed 1 as being unworkable, but do you realize how
unrealistic this sounds?

*2* git.git has _far_ more users and a _lot_ more contributors.  Don't
be unwelcoming to contributors by asking them to go away and work on
something else.  The three proprietary applications you have given as
counter-examples (?) is not helping anyone.

On Sat, Jun 8, 2013 at 11:34 PM, Jeff King [off-list ref] wrote:

On Sat, Jun 08, 2013 at 09:20:54AM -0500, Felipe Contreras wrote:

quoted

Let the code speak. Show me a script in any language that does
something useful using libgit2, doing the equivalent to at least a
couple of 'git foo' commands.

Sorry that I cannot show you the source code, but you may interested to
know that libgit2 powers:

  1. Microsoft's "Visual Studio Tools for Git" plugin

  2. GitHub's native Mac and Windows clients (using Objective C and C#
     bindings); some operations still shell out to git where the
     functionality is not yet implemented in libgit2.

  3. Parts of the web view of GitHub.com via Ruby bindings

It is definitely not feature-complete when compared with git.git. But I
do think it is in a state that is usable for quite a few tasks.

That's not what a I asked. We have perl, and shell, and python, and
ruby scripts in git.git, they all use 'git foo' commands to get things
done. But to do that, forks are needed, many of them, constantly. The
proposal was to use libgit2 to avoid such forks. Well, show me a
*script* that does that and is worthy of inclusion to git.git, even if
it's to contrib.

I didn't ask for irrelevant 3rd parties, I asked for something worthy
of inclusion into git.git, a script that does something useful using
libgit2.

Duy Nguyen seems to think it's easy to do that. I'm waiting.

-- 
Felipe Contreras

On Sun, Jun 9, 2013 at 12:26 AM, Jeff King [off-list ref] wrote:

On Sat, Jun 08, 2013 at 09:17:56PM -0500, Felipe Contreras wrote:

quoted

quoted

Definitely, yes.  Even if you look at the impact on code alone and
don't care about the people, destroying a collegial work environment
is harmful enough to the code to outweigh the (admittedly often
useful) patches.

A collegial work environment is overrated, and proof of that the Linux
kernel, where honest and straight talk is the bread and butter of the
mailing list. And the Linux kernel is the most successful software
project in history by far. It's code that speaks.

Sorry, but I don't agree, and I want to publicly state my opinion so
that Jonathan (and other bystanders on the list) knows that he is not
alone in his opinions.

You don't agree that 1) a collegial work environment is overrated, 2)
that the Linux kernel doesn't put an emphasis on being collegial, or
3) that it's the most successful software project in history?

I have consistently found your demeanor on the list to be very
unfriendly and difficult to work with. It is one thing to have honest
and straight talk, and another thing to be obstinate, unmindful of
feedback (both with respect to technical details, as well as to
communication styles), and disrespectful of other people.

Go back to my 261 commits, show me one that is "unmindful of technical details".

It is certainly your choice about how you will communicate. But likewise
it is the choice of readers and reviewers to choose how much of their
time to give to your writings.

Exactly. Nobody is forcing you to read my emails. But somehow you
already know that ignoring them is not in the best interest of the
project. And by that I mean it's in the best interest of our users,
without which our project is nothing.

-- 
Felipe Contreras

Jeff King wrote:

quoted

quoted

Definitely, yes.  Even if you look at the impact on code alone and
don't care about the people, destroying a collegial work environment
is harmful enough to the code to outweigh the (admittedly often
useful) patches.

A collegial work environment is overrated, and proof of that the Linux
kernel, where honest and straight talk is the bread and butter of the
mailing list. And the Linux kernel is the most successful software
project in history by far. It's code that speaks.

I have consistently found your demeanor on the list to be very
unfriendly and difficult to work with. It is one thing to have honest
and straight talk, and another thing to be obstinate, unmindful of
feedback (both with respect to technical details, as well as to
communication styles), and disrespectful of other people.

While I agree that being rude and obstinate is definitely undesirable,
and that a healthy on-list environment is important, I have something
to add:

Being super-tactful comes at a cost.  Regulars on the mailing list
have to spend 3~4x the amount of time to compose an email (reading and
re-reading their drafts to see how to express them in a more friendly
way); this leads to a lot of inefficiency and creates a suffocating
environment in which people don't have freedom of expression.  I would
much rather prefer straight talk where nobody reads into what is
written and takes offense.  In this case, jrn took offense and talked
about how he would ban fc from the list if he were managing it: while
I'm not defending fc's tone, I'm not defending jrn's comment either.
jrn has been around since mid-2008, and fc has been around since
early-2009.  It's mid-2013, and they still haven't learnt to work with
each other.

Disagreement is healthy, and is the foundation of progress.  When it
comes to sensitive issues, stern disagreement is often mis-interpreted
as disrespect (or worse).  If we keep beating up disagreements on the
basis of tone and demeanor, git.git would go nowhere.  Sure, it would
be more ideal if fc's tone were friendlier [*1*], but it isn't: let's
deal with the issue instead of constantly whining about it.

[Footnotes]

*1* Oh, and mine too.  I've been told several times off-list that my
tone is unfriendly.  I'm working on fixing the issue, but I don't
enjoy the constant suffocation: I should be able to say what I want
without too much effort.

On Sun, Jun 9, 2013 at 7:48 AM, Ramkumar Ramachandra [off-list ref] wrote:

Jeff King wrote:

quoted

quoted

quoted

Definitely, yes.  Even if you look at the impact on code alone and
don't care about the people, destroying a collegial work environment
is harmful enough to the code to outweigh the (admittedly often
useful) patches.

A collegial work environment is overrated, and proof of that the Linux
kernel, where honest and straight talk is the bread and butter of the
mailing list. And the Linux kernel is the most successful software
project in history by far. It's code that speaks.

I have consistently found your demeanor on the list to be very
unfriendly and difficult to work with. It is one thing to have honest
and straight talk, and another thing to be obstinate, unmindful of
feedback (both with respect to technical details, as well as to
communication styles), and disrespectful of other people.

While I agree that being rude and obstinate is definitely undesirable,
and that a healthy on-list environment is important, I have something
to add:

Being super-tactful comes at a cost.  Regulars on the mailing list
have to spend 3~4x the amount of time to compose an email (reading and
re-reading their drafts to see how to express them in a more friendly
way); this leads to a lot of inefficiency and creates a suffocating
environment in which people don't have freedom of expression.

That's exactly the reason why they don't put emphasis on that in the
Linux kernel mailing list.

Besides, when something is really fucked up, the most effective way to
convey the fact that you think it's totally fucked up, is to say
precisely that. If somebody's feelings get hurt along the way, and
they decide to leave the project, they were not cut for Linux
development anyway.

I would
much rather prefer straight talk where nobody reads into what is
written and takes offense.  In this case, jrn took offense and talked
about how he would ban fc from the list if he were managing it: while
I'm not defending fc's tone, I'm not defending jrn's comment either.
jrn has been around since mid-2008, and fc has been around since
early-2009.  It's mid-2013, and they still haven't learnt to work with
each other.

We don't _need_ to work with each other. If he helps the project, and
I help the project, what's wrong with that?

Disagreement is healthy, and is the foundation of progress.  When it
comes to sensitive issues, stern disagreement is often mis-interpreted
as disrespect (or worse).  If we keep beating up disagreements on the
basis of tone and demeanor, git.git would go nowhere.  Sure, it would
be more ideal if fc's tone were friendlier [*1*], but it isn't: let's
deal with the issue instead of constantly whining about it.

Completely agree. Disagreement is not disrespect. Besides, ideas don't
have feelings, ideas don't need respect; ideas should be criticized.
Any rational person, specially scientists, understand that it's not
healthy to have an emotional attachment to ideas; they might be wrong,
and they need scrutiny. If one doesn't tolerate criticism of one's
ideas (however straightforward or delicate it might be), one is never
going to find the truth.

-- 
Felipe Contreras

On Sun, Jun 09, 2013 at 07:15:45AM -0500, Felipe Contreras wrote:

quoted

Sorry, but I don't agree, and I want to publicly state my opinion so
that Jonathan (and other bystanders on the list) knows that he is not
alone in his opinions.

You don't agree that 1) a collegial work environment is overrated, 2)
that the Linux kernel doesn't put an emphasis on being collegial, or
3) that it's the most successful software project in history?

Point 1.

Go back to my 261 commits, show me one that is "unmindful of technical details".

I do not have an interest in cataloguing past conflicts I and others
have had with you; the list archive has done so. I have already made my
comments there, and I see no point in starting a new argument.

Exactly. Nobody is forcing you to read my emails. But somehow you
already know that ignoring them is not in the best interest of the
project. And by that I mean it's in the best interest of our users,
without which our project is nothing.

I never claimed that you contribute nothing. But every minute spent
arguing with you is a minute that could be spent on something more
productive. It is certainly possible that community members reading your
emails could be a net negative for the users, if it leaves them no time
for other code.

-Peff

On Sun, Jun 09, 2013 at 03:28:48PM +0530, Ramkumar Ramachandra wrote:

Jeff King wrote:

quoted

Sorry that I cannot show you the source code, but you may interested to
know that libgit2 powers:

Yes, I'm well aware of these: libgit2 is LGPL, because of which these
three proprietary applications have been made possible.  Isn't it
completely orthogonal to the discussion about how best to lib'ify
git.git though?  From what I understand, fc is not interested in
building another application leveraging libgit.a or libgit2; he's
interested in improving libgit.a and getting more users.

Perhaps I misunderstood the discussion, but it looked to me that there
was an assertion that libgit2 was not ready for useful work. I do not
think that is true, and I tried to counter it with facts.

If that was not useful to the discussion, I apologize for leading it
astray.

quoted

It is definitely not feature-complete when compared with git.git. But I
do think it is in a state that is usable for quite a few tasks.

What is this task you are discussing?

You snipped the part of Felipe's message that I quoted:

  Let the code speak. Show me a script in any language that does
  something useful using libgit2, doing the equivalent to at least a
  couple of 'git foo' commands.

I meant tasks that were "equivalent to at least a couple of 'git foo'
commands" as performed by the programs I mentioned. Like cloning,
checkout, commit, revision traversal, diffs, etc.

fc is talking about improving libgit.a and getting an official git
library with many users. Answer the question: what should we do now?

I do not think I was addressing that point at all in my email. But since
you ask...

1. Start moving irrelevant code out of libgit.a, and use inspiration
from libgit2 to improve it (this might or might not involve taking
code from libgit2).  Get _users_ of libgit.a via ruby bindings (or
something) asap, so it puts pressure on fixing it.

I already mentioned elsewhere that I think it would be fine to massage
libgit.a in that direction. I even joined the conversation pointing out
some cases where Felipe's ruby module would break. But I do not think
that moving code in and out of libgit.a is an important first step at
all. That is simply code that no library users would want to call, and
is easy to deal with: move it out. The hard part is code that users
_would_ want to call, and is totally broken. Patches dealing with that
are the hard obstacle that people working in this direction would need
to overcome. But I do not see any such patches under discussion.

2. Wait indefinitely until libgit2.git magically becomes ready to be
usable by git.git as-is.  Then throw libgit.a out the window, and
rewrite git.git to call into libgit2.a instead [*1*].

I think the "magically" here could be "work on libgit2 to move it
towards being useful for git.git". I also do not think there needs to be
a "throw out libgit.a" flag day. We can make a decision later to start
adopting bits of libgit2 inside git.git (the big downside being an
increased dependency).

Maybe the code style will diverge too much and it will never be
appropriate to do so. We'll have to see.

What you seem to be saying is "3. Work on libgit2 (and abandon
git.git?)" [*2*], or worse: 2.

I didn't say that at all. If the two projects co-exist forever, working
compatibly on the same repositories, and git.git is the command line and
libgit2 is the library, I do not see that as the end of the world. The
downside there is is code duplication, which is why it may eventually
make sense for libgit.a to start adopting bits of libgit2 (it is usually
hard to go the other way, both for licensing reasons, and for the fact
that the library code tends to be more reusable).

fc is in favor of 1.  Unless you are
in favor of _not_ improving libgit.a, don't stand in his way:

I'm not. I tried to give pointers on the path that I think would be
useful (e.g., what would break with his ruby patch).

*1* You have dismissed 1 as being unworkable, but do you realize how
unrealistic this sounds?

I don't think I dismissed it as unworkable. I said it was a lot of work,
tried to describe some examples, and said that I think the other route
may be _less_ work.

*2* git.git has _far_ more users and a _lot_ more contributors.  Don't
be unwelcoming to contributors by asking them to go away and work on
something else.  The three proprietary applications you have given as
counter-examples (?) is not helping anyone.

They were counter-examples to the point "libgit2 is not ready for real
work", which I thought was being made. If that was not the point being
made, then no, they are not helping anyone.

-Peff

On Sun, Jun 9, 2013 at 12:40 PM, Jeff King [off-list ref] wrote:

On Sun, Jun 09, 2013 at 07:15:45AM -0500, Felipe Contreras wrote:

quoted

quoted

Sorry, but I don't agree, and I want to publicly state my opinion so
that Jonathan (and other bystanders on the list) knows that he is not
alone in his opinions.

You don't agree that 1) a collegial work environment is overrated, 2)
that the Linux kernel doesn't put an emphasis on being collegial, or
3) that it's the most successful software project in history?

Point 1.

Good, so we agree that a project doesn't need a collegial work
environment to be extremely and amazingly successful. In fact, any
rational person would keep an open mind to the fact that perhaps it
actually _helps_ to not have such environment, based on the evidence.

quoted

Go back to my 261 commits, show me one that is "unmindful of technical details".

I do not have an interest in cataloguing past conflicts I and others
have had with you; the list archive has done so.

No. There is no such catalog. You made a claim, it's not backed by
evidence, merely by your subjective experience. And memory is a pretty
bad indicator of reality.

"The first principle is that you must not fool yourself—and you are
the easiest person to fool" -- Richard Feynman

-- 
Felipe Contreras

On Sun, Jun 09, 2013 at 06:18:51PM +0530, Ramkumar Ramachandra wrote:

quoted

I have consistently found your demeanor on the list to be very
unfriendly and difficult to work with. It is one thing to have honest
and straight talk, and another thing to be obstinate, unmindful of
feedback (both with respect to technical details, as well as to
communication styles), and disrespectful of other people.

While I agree that being rude and obstinate is definitely undesirable,
and that a healthy on-list environment is important, I have something
to add:

Being super-tactful comes at a cost.

I actually think word choice and politeness is only a small part of it,
and one that I live without.  It is not just _how_ something is said,
but _what_ is said. And sometimes what is said does not lead in a
productive direction. I found Thomas's comment here:

  http://article.gmane.org/gmane.comp.version-control.git/227053

sums up the core of many of the conflicts I've seen on the list.

I am less interested in people's feelings than I am in discussions
trying to reach a productive position of agreement, rather than turning
it into a point by point debate that may no longer have any use for the
project (sometimes individual points need to be refuted or discussed, of
course, but it is easy to lose sight of the purpose of an email).

-Peff

On Sun, Jun 9, 2013 at 12:55 PM, Jeff King [off-list ref] wrote:

On Sun, Jun 09, 2013 at 03:28:48PM +0530, Ramkumar Ramachandra wrote:

quoted

Jeff King wrote:

quoted

Sorry that I cannot show you the source code, but you may interested to
know that libgit2 powers:

Yes, I'm well aware of these: libgit2 is LGPL, because of which these
three proprietary applications have been made possible.  Isn't it
completely orthogonal to the discussion about how best to lib'ify
git.git though?  From what I understand, fc is not interested in
building another application leveraging libgit.a or libgit2; he's
interested in improving libgit.a and getting more users.

Perhaps I misunderstood the discussion, but it looked to me that there
was an assertion that libgit2 was not ready for useful work. I do not
think that is true, and I tried to counter it with facts.

That was not the point. Take 'contrib/related/git-related', or any
useful script, and make it so it uses libgit2 instead of forking 'git
foo' commands.

It's not going to happen.

-- 
Felipe Contreras

Jeff King wrote:

I already mentioned elsewhere that I think it would be fine to massage
libgit.a in that direction. I even joined the conversation pointing out
some cases where Felipe's ruby module would break. But I do not think
that moving code in and out of libgit.a is an important first step at
all. That is simply code that no library users would want to call, and
is easy to deal with: move it out. The hard part is code that users
_would_ want to call, and is totally broken. Patches dealing with that
are the hard obstacle that people working in this direction would need
to overcome. But I do not see any such patches under discussion.

Forget the rest; this makes it clear.  Thanks, and sorry for all the confusion.

So, reorganization is not the first step.  Can you please post an
example patch illustrating what needs to be done, so we can follow?

On Sun, Jun 09, 2013 at 01:01:30PM -0500, Felipe Contreras wrote:

quoted

quoted

quoted

Sorry, but I don't agree, and I want to publicly state my opinion so
that Jonathan (and other bystanders on the list) knows that he is not
alone in his opinions.

You don't agree that 1) a collegial work environment is overrated, 2)
that the Linux kernel doesn't put an emphasis on being collegial, or
3) that it's the most successful software project in history?

Point 1.

Good, so we agree that a project doesn't need a collegial work
environment to be extremely and amazingly successful.

No, I said that point 1 was the point I was not agreeing with. I do not
have an opinion on 2, as I do not interact with the kernel community
enough to know.

In fact, any rational person would keep an open mind to the fact that
perhaps it actually _helps_ to not have such environment, based on the
evidence.

In my experience, dealing with you has been a giant time sink. For
example, this thread. Without needing to get into the exact definition
of "such an environment", the above statement is certainly my backed by
empirical experience.

quoted

I do not have an interest in cataloguing past conflicts I and others
have had with you; the list archive has done so.

No. There is no such catalog. You made a claim, it's not backed by
evidence, merely by your subjective experience. And memory is a pretty
bad indicator of reality.

I think this thread is an excellent example all by itself.

-Peff

On Sun, Jun 9, 2013 at 1:06 PM, Ramkumar Ramachandra [off-list ref] wrote:

Jeff King wrote:

quoted

I already mentioned elsewhere that I think it would be fine to massage
libgit.a in that direction. I even joined the conversation pointing out
some cases where Felipe's ruby module would break. But I do not think
that moving code in and out of libgit.a is an important first step at
all. That is simply code that no library users would want to call, and
is easy to deal with: move it out. The hard part is code that users
_would_ want to call, and is totally broken. Patches dealing with that
are the hard obstacle that people working in this direction would need
to overcome. But I do not see any such patches under discussion.

Forget the rest; this makes it clear.  Thanks, and sorry for all the confusion.

So, reorganization is not the first step.  Can you please post an
example patch illustrating what needs to be done, so we can follow?

If you have a code-base with 100 functions, 10 of which make sense in
a public library, instead of going ahead to fix those 10 functions, it
makes sense to *first* separate those 10 functions, and *then* clean
them up for public usage.

But let's assume that Jeff is right and this is not the first step. It
doesn't matter; I already started that step and created builtin/lib.a.
Are you going to throw away that because it's not "the first step"?

-- 
Felipe Contreras

On Sun, Jun 9, 2013 at 1:10 PM, Jeff King [off-list ref] wrote:

On Sun, Jun 09, 2013 at 01:01:30PM -0500, Felipe Contreras wrote:

quoted

quoted

I do not have an interest in cataloguing past conflicts I and others
have had with you; the list archive has done so.

No. There is no such catalog. You made a claim, it's not backed by
evidence, merely by your subjective experience. And memory is a pretty
bad indicator of reality.

I think this thread is an excellent example all by itself.

It's an excellent example of your personal issues clouding your judgement.

The topic was this (which you just snipped):

Go back to my 261 commits, show me one that is "unmindful of technical details".

And you say this thread is an excellent example of your point that I'm
unmindful of technical details?

It's not. There are no technical details I was unmindful of in this thread.

Once more, you have no evidence of that claim. Only subjective
personal experience.

-- 
Felipe Contreras

On Sun, Jun 09, 2013 at 11:36:42PM +0530, Ramkumar Ramachandra wrote:

Jeff King wrote:

quoted

I already mentioned elsewhere that I think it would be fine to massage
libgit.a in that direction. I even joined the conversation pointing out
some cases where Felipe's ruby module would break. But I do not think
that moving code in and out of libgit.a is an important first step at
all. That is simply code that no library users would want to call, and
is easy to deal with: move it out. The hard part is code that users
_would_ want to call, and is totally broken. Patches dealing with that
are the hard obstacle that people working in this direction would need
to overcome. But I do not see any such patches under discussion.

Forget the rest; this makes it clear.  Thanks, and sorry for all the confusion.

So, reorganization is not the first step.  Can you please post an
example patch illustrating what needs to be done, so we can follow?

Sorry, I don't have patches. It is a hard problem for which I do not
have the solution, which is kind of my point.

For the record, I am not _against_ any code organization that might be
useful for lib-ification later. I just do not see it as an interesting
step to be discussing if you want to know whether such a lib-ification
effort is feasible.

-Peff

On Sun, Jun 9, 2013 at 1:22 PM, Jeff King [off-list ref] wrote:

On Sun, Jun 09, 2013 at 11:36:42PM +0530, Ramkumar Ramachandra wrote:

quoted

Jeff King wrote:

quoted

I already mentioned elsewhere that I think it would be fine to massage
libgit.a in that direction. I even joined the conversation pointing out
some cases where Felipe's ruby module would break. But I do not think
that moving code in and out of libgit.a is an important first step at
all. That is simply code that no library users would want to call, and
is easy to deal with: move it out. The hard part is code that users
_would_ want to call, and is totally broken. Patches dealing with that
are the hard obstacle that people working in this direction would need
to overcome. But I do not see any such patches under discussion.

Forget the rest; this makes it clear.  Thanks, and sorry for all the confusion.

So, reorganization is not the first step.  Can you please post an
example patch illustrating what needs to be done, so we can follow?

Sorry, I don't have patches. It is a hard problem for which I do not
have the solution, which is kind of my point.

Wouldn't it make sense then to concentrate on the patches that we do have?

For the record, I am not _against_ any code organization that might be
useful for lib-ification later. I just do not see it as an interesting
step to be discussing if you want to know whether such a lib-ification
effort is feasible.

If you don't find it interesting, don't do it. I already did this step
(Move sequencer to builtin), the question is; does it go forward, or
should it be rejected?

-- 
Felipe Contreras

Jeff King wrote:

I actually think word choice and politeness is only a small part of it,
and one that I live without.  It is not just _how_ something is said,
but _what_ is said. And sometimes what is said does not lead in a
productive direction. I found Thomas's comment here:

  http://article.gmane.org/gmane.comp.version-control.git/227053

sums up the core of many of the conflicts I've seen on the list.

This is all very good, Jeff.  Various people have expressed what's
wrong with fc's "demeanour", "tone", and "style of discussion" in
various different ways at various different points in time.  This goes
on and on and on with no end in sight. WHAT do we do?

I'll be frank: I'm a pragmatic person, and I want to see work.
Despite all this mess, who has shown me the most number of patches
with some direction?  Felipe.  Who gets the most number of patches
into git.git, by far?  Felipe.  And who is wasting time theorizing
about what's wrong with Felipe in various ways?  Everyone else.

I am less interested in people's feelings than I am in discussions
trying to reach a productive position of agreement, rather than turning
it into a point by point debate that may no longer have any use for the
project (sometimes individual points need to be refuted or discussed, of
course, but it is easy to lose sight of the purpose of an email).

Felipe has discussed the {sequencer.c -> builtin/sequencer.c} move
with a bunch of us (and sent a patch), discussed how to write tests
properly with me (with a patch), and discussed how ruby can be used to
call into libgit.a (with code that I'm currently playing with).

Jeff King wrote:

Sorry, I don't have patches. It is a hard problem for which I do not
have the solution, which is kind of my point.

So, what is the problem?  We are moving towards what we think is the
way forward.  Nobody said that it is the theoretical best, but it's
_much_ better than doing nothing, no?

For the record, I am not _against_ any code organization that might be
useful for lib-ification later. I just do not see it as an interesting
step to be discussing if you want to know whether such a lib-ification
effort is feasible.

Then whom are we to ask about this feasibility?  All the core
contributors (including Junio) are in the CC.  Nobody has said
anything.  So, are you proposing that we sit and ponder over our
theoretically-indeterminate-feasibility problem?  There is no magic
bullet, Jeff.  We write code, and we fix bugs as and when they crop
up; there's really not much else anyone can do.  Help by writing code,
or reviewing someone else's code.

On Mon, Jun 10, 2013 at 12:02:11AM +0530, Ramkumar Ramachandra wrote:

This is all very good, Jeff.  Various people have expressed what's
wrong with fc's "demeanour", "tone", and "style of discussion" in
various different ways at various different points in time.  This goes
on and on and on with no end in sight. WHAT do we do?

My advice would be to ignore him when the discussion proceeds in an
unproductive direction.

But I never wanted to tell other people what to do with respect to
Felipe. My point was to express public agreement with Jonathan, and show
that individual members of the community may be less interested in
helping you if you behave in certain ways. At this point, I do not have
any hope of impacting Felipe's behavior, but I thought it might be
demonstrative to other list members.  We do not have an explicit code of
conduct on the list, but it is not as if behavior is without
consequences. If you are not easy to work with, people will get tired of
dealing with you eventually[1].

-Peff

[1] Or maybe not. Maybe there are enough people interested in what
    Felipe has to say that he will continue to get review. I even try to
    review his patches myself when there is something factually and
    obviously wrong to point out, and it won't suck me into a
    time-wasting argument that goes nowhere.

    But the point is that each individual can make the choice
    themselves, and then the problem is solved for them.

On Sun, Jun 9, 2013 at 1:32 PM, Ramkumar Ramachandra [off-list ref] wrote:

Jeff King wrote:

quoted

I actually think word choice and politeness is only a small part of it,
and one that I live without.  It is not just _how_ something is said,
but _what_ is said. And sometimes what is said does not lead in a
productive direction. I found Thomas's comment here:

  http://article.gmane.org/gmane.comp.version-control.git/227053

sums up the core of many of the conflicts I've seen on the list.

This is all very good, Jeff.  Various people have expressed what's
wrong with fc's "demeanour", "tone", and "style of discussion" in
various different ways at various different points in time.  This goes
on and on and on with no end in sight. WHAT do we do?

What really puzzles me is that I think discussion and disagreement are
healthy, not only in open source projects, but in any organization; If
everyone always agrees, you know something is really wrong. But if
others think disagreement is not helpful, why do they bother replying
at all? Arguing. And they think their time is better spent not
discussing, but writing code (or something else), why don't they spend
their time that way. Why blame me for their choices?

We disagree, that's fine, move on.

I'll be frank: I'm a pragmatic person, and I want to see work.
Despite all this mess, who has shown me the most number of patches
with some direction?  Felipe.  Who gets the most number of patches
into git.git, by far?  Felipe.  And who is wasting time theorizing
about what's wrong with Felipe in various ways?  Everyone else.

Thanks! "Talk is cheap, show me the code."

quoted

I am less interested in people's feelings than I am in discussions
trying to reach a productive position of agreement, rather than turning
it into a point by point debate that may no longer have any use for the
project (sometimes individual points need to be refuted or discussed, of
course, but it is easy to lose sight of the purpose of an email).

Felipe has discussed the {sequencer.c -> builtin/sequencer.c} move
with a bunch of us (and sent a patch), discussed how to write tests
properly with me (with a patch), and discussed how ruby can be used to
call into libgit.a (with code that I'm currently playing with).

Interesting. In case it might help you, this is the extconf.rb I used:

---
ruby/extconf.rb:
#!/usr/bin/env ruby

require 'mkmf'

$INCFLAGS = "-I.. #{$INCFLAGS}"
$CFLAGS += " -DSHA1_HEADER='<openssl/sha.h>'"

# libs
$LOCAL_LIBS += ' ../builtin/lib.a ../libgit.a ../xdiff/lib.a'
$LIBS += ' -lssl -lcrypto -lz'

# make sure there are no undefined symbols
$LDFLAGS += ' -Wl,--no-undefined'

# Create Makefile
dir_config('git')
create_makefile('git')
--

I have to build all the objects with -fPIC though.

-- 
Felipe Contreras

On Mon, Jun 10, 2013 at 12:14:36AM +0530, Ramkumar Ramachandra wrote:

Jeff King wrote:

quoted

Sorry, I don't have patches. It is a hard problem for which I do not
have the solution, which is kind of my point.

So, what is the problem?  We are moving towards what we think is the
way forward.  Nobody said that it is the theoretical best, but it's
_much_ better than doing nothing, no?

I thought I already said: there is a lot of global state that is assumed
to be wiped between various functions and git commands. For example, you
cannot just call cmd_log twice in the same process and get the right
answers. I haven't seen a proposal for dealing with that.

Then whom are we to ask about this feasibility?  All the core
contributors (including Junio) are in the CC.  Nobody has said
anything.  So, are you proposing that we sit and ponder over our
theoretically-indeterminate-feasibility problem?  There is no magic
bullet, Jeff.  We write code, and we fix bugs as and when they crop
up; there's really not much else anyone can do.  Help by writing code,
or reviewing someone else's code.

I mentioned a bug above. How are you going to fix it? Where is your
patch to review?

-Peff

On Sun, Jun 9, 2013 at 1:49 PM, Jeff King [off-list ref] wrote:

On Mon, Jun 10, 2013 at 12:14:36AM +0530, Ramkumar Ramachandra wrote:

quoted

Jeff King wrote:

quoted

Sorry, I don't have patches. It is a hard problem for which I do not
have the solution, which is kind of my point.

So, what is the problem?  We are moving towards what we think is the
way forward.  Nobody said that it is the theoretical best, but it's
_much_ better than doing nothing, no?

I thought I already said: there is a lot of global state that is assumed
to be wiped between various functions and git commands. For example, you
cannot just call cmd_log twice in the same process and get the right
answers. I haven't seen a proposal for dealing with that.

quoted

Then whom are we to ask about this feasibility?  All the core
contributors (including Junio) are in the CC.  Nobody has said
anything.  So, are you proposing that we sit and ponder over our
theoretically-indeterminate-feasibility problem?  There is no magic
bullet, Jeff.  We write code, and we fix bugs as and when they crop
up; there's really not much else anyone can do.  Help by writing code,
or reviewing someone else's code.

I mentioned a bug above. How are you going to fix it? Where is your
patch to review?

--- a/git.c
+++ b/git.c

@@ -359,7 +359,7 @@ static void handle_internal_command(int argc,

const char **argv)
                { "index-pack", cmd_index_pack, RUN_SETUP_GENTLY },
                { "init", cmd_init_db },
                { "init-db", cmd_init_db },
-               { "log", cmd_log, RUN_SETUP },
+               { "log", cmd_log, RUN_SETUP | NEEDS_FORK },
                { "ls-files", cmd_ls_files, RUN_SETUP },
                { "ls-remote", cmd_ls_remote, RUN_SETUP_GENTLY },
                { "ls-tree", cmd_ls_tree, RUN_SETUP },

Done.

But either way, that's orthogonal to the builtin/lib.a issue. It has
absolutely nothing to do with Ruby, or my experiment. It's about the
sequencer and notes, and all that stuff for which I just sent
forty-something patches. If you have a better idea how to fix that,
let's see it.

-- 
Felipe Contreras

On Sun, Jun 9, 2013 at 8:16 PM, Felipe Contreras
[off-list ref] wrote:

On Sun, Jun 9, 2013 at 1:10 PM, Jeff King [off-list ref] wrote:

quoted

Go back to my 261 commits, show me one that is "unmindful of technical details".

And you say this thread is an excellent example of your point that I'm
unmindful of technical details?

It's not. There are no technical details I was unmindful of in this thread.

Ok, I'll bite (against my better judgment). From a related thread, a
few minutes ago:

On Sun, Jun 9, 2013 at 7:46 PM, Felipe Contreras
[off-list ref] wrote:

On Sun, Jun 9, 2013 at 12:32 PM, Thomas Rast [off-list ref] wrote:

quoted

So you would deliberately break a bisection on this test file?

No, this patch series won't be applied.

Thomas points out a technical detail with the patch series, and the
answer given is 100% non-constructive.

FWIW, I'd like to express my support for the opinions expressed by
Jonathan, Jeff and Thomas. They accurately describe my impression of
these discussion threads.


...Johan

-- 
Johan Herland, [off-list ref]
www.herland.net

On Sun, Jun 9, 2013 at 2:11 PM, Johan Herland [off-list ref] wrote:

On Sun, Jun 9, 2013 at 8:16 PM, Felipe Contreras
[off-list ref] wrote:

quoted

On Sun, Jun 9, 2013 at 1:10 PM, Jeff King [off-list ref] wrote:

quoted

Go back to my 261 commits, show me one that is "unmindful of technical details".

And you say this thread is an excellent example of your point that I'm
unmindful of technical details?

It's not. There are no technical details I was unmindful of in this thread.

Ok, I'll bite (against my better judgment). From a related thread, a
few minutes ago:

On Sun, Jun 9, 2013 at 7:46 PM, Felipe Contreras
[off-list ref] wrote:

quoted

On Sun, Jun 9, 2013 at 12:32 PM, Thomas Rast [off-list ref] wrote:

quoted

So you would deliberately break a bisection on this test file?

No, this patch series won't be applied.

Thomas points out a technical detail with the patch series, and the
answer given is 100% non-constructive.

Geezus!

http://thread.gmane.org/gmane.comp.version-control.git/227109

There. Are you happy?

I dropped the patches that are not part of the series.

Who benefits from this? NOBODY. Certainly not the users.

-- 
Felipe Contreras

Jeff King wrote:

My advice would be to ignore him when the discussion proceeds in an
unproductive direction.

There is something appealing about that option.  The problem is that
it doesn't work, at least for someone that relies on the list as a way
of understanding patches that have been applied (which often don't
have self-contained descriptions, sadly) and the context of other
patches.

Of course that's not the intent: the intent of ignoring someone is to
hope they'll go away. :)

In the context of other unhealthy behaviors (like alcoholism) there is
a concept of enabling behavior.  One of an addict's friends might
confront her and try to help her understand that things have gone too
far.  Another friend says, "What a mess.  Let's go to a bar and talk"
and they are drinking again.  The usual approach for avoiding this is
an intervention, where a large group of people that care about a
person together agree to confront the addict and make sure she
actually understands and work together to find a real way out.

Of course the git development community is not organized enough for an
intervention, but as context I thought I'd mention that that's what
works.

Ramkumar Ramachandra wrote:

I'll be frank: I'm a pragmatic person, and I want to see work.
Despite all this mess, who has shown me the most number of patches
with some direction?  Felipe.  Who gets the most number of patches
into git.git, by far?  Felipe.  And who is wasting time theorizing
about what's wrong with Felipe in various ways?  Everyone else.

In that case, I can see a simple solution.  Felipe, who provides the
most patches in git.git, by far (I don't know what that means, but
I'll take it as an assumption), can put up a fork of git that you run.
He can solicit whatever level of review he is comfortable with before
pushing out changes, and then the result is available, without the
pesky middle-man of those theorizers that were trying to develop git a
different way and then got annoyed.

No harm done, right?  It doesn't have to involve the list, because
what's relevant in this worldview is code, not the people.

So why aren't I privately ignoring his messages and letting the list
become what it may?  It would seem that I'm making the problem much
worse, by starting discussions that focus of how to stop pushing other
contributors away instead of (what's important) code!

Jonathan

On Sun, Jun 9, 2013 at 2:57 PM, Jonathan Nieder [off-list ref] wrote:

Jeff King wrote:

Of course that's not the intent: the intent of ignoring someone is to
hope they'll go away. :)

In the context of other unhealthy behaviors (like alcoholism) there is
a concept of enabling behavior.

The only one that can enable me is Junio. If he stops merging my
patches I would stop sending them.

It appears Junio is a good maintainer though, as he puts the needs of
the project, and thus our users, above your personal issues.

quoted

I'll be frank: I'm a pragmatic person, and I want to see work.
Despite all this mess, who has shown me the most number of patches
with some direction?  Felipe.  Who gets the most number of patches
into git.git, by far?  Felipe.  And who is wasting time theorizing
about what's wrong with Felipe in various ways?  Everyone else.

In that case, I can see a simple solution.  Felipe, who provides the
most patches in git.git, by far (I don't know what that means, but
I'll take it as an assumption),

Maybe this will help understand the meaning of that:

% git shortlog -n -s --no-merges --since '3 months ago'
   221	Felipe Contreras
    83	Junio C Hamano
    71	Jeff King
    62	Michael Haggerty
    48	Ramkumar Ramachandra
    35	Thomas Rast
    33	Nguyễn Thái Ngọc Duy
    32	John Keeping
    30	René Scharfe
    23	Kevin Bracey

-- 
Felipe Contreras

Jonathan Nieder wrote:

Of course the git development community is not organized enough for an
intervention, but as context I thought I'd mention that that's what
works.

Atleast this is more interesting that the canned
Felipe-demeanour-complaint people constantly bring up boring everyone
to death.

In that case, I can see a simple solution.  Felipe, who provides the
most patches in git.git, by far (I don't know what that means, but
I'll take it as an assumption), can put up a fork of git that you run.
He can solicit whatever level of review he is comfortable with before
pushing out changes, and then the result is available, without the
pesky middle-man of those theorizers that were trying to develop git a
different way and then got annoyed.

No harm done, right?  It doesn't have to involve the list, because
what's relevant in this worldview is code, not the people.

I'm still scratching my head over what you interpreted.  People are
not unimportant!  Code is result of everyone in the community
scratching their itches.  I value each and every community member, and
git.git wouldn't be what it is today without everyone.  How did you
interpret that as "I am only interested in Felipe's work, and everyone
else is a theorizing buffoon"?  I specifically said theorizing about
Felipe's behavior over and over and over again is not changing
anything.  Stay on topic, and discuss how to improve libgit.a.

To me, it is important that everyone stays productive, so we can
maximize output.  I want more review, more discussions, more code.  I
get bored out of my mind when Junio does feature freezes and nothing
goes in.  Obviously, people getting offended and writing long
emotional rants on the list is unproductive and undesirable.

So why aren't I privately ignoring his messages and letting the list
become what it may?  It would seem that I'm making the problem much
worse, by starting discussions that focus of how to stop pushing other
contributors away instead of (what's important) code!

It is imperative that you express your opinion and discuss it, if
something is troubling you.  What is this dichotomy between
contributors and code?  When did I discuss pushing contributors away?

On 06/09/2013 09:11 PM, Johan Herland wrote:

[...]
FWIW, I'd like to express my support for the opinions expressed by
Jonathan, Jeff and Thomas. They accurately describe my impression of
these discussion threads.

I also agree.  In my opinion, Felipe, your abrasiveness, your disregard
of project standards, and your eternal argumentativeness outweigh the
benefit of your contributions, large though they may be.

Writing code is only a small part of keeping the Git project going.

* Reviewing code is an essential, more thankless, and therefore more
precious, contribution.  Therefore the Git project has standards to make
code review less unpleasant and more effective; for example: (1) patches
shouldn't cause regressions; (2) commit messages have to be written to
very high standards; (3) reviewers' comments should be accepted
gratefully and taken very seriously.  Almost everybody in the Git
community accepts these standards.  Felipe, you do not seem to.  The
result is that reviewers' time and goodwill are wasted, and they
justifiably feel unvalued.  We can't afford to misuse reviewers; they
are the bedrock (and the bottleneck) of the project.

* Gaining and keeping contributors is important to maintaining the
success of the project.  The mailing list is the main forum for the
development community; therefore, it is important that the mailing list
be a place where people display a high degree of technical excellence,
but also respect for one another, friendliness (or at least a lack of
hostility), and discussions that do turn into flame wars.  It is
possible to have a profound technical disagreement without losing
respect for the other side; contrariwise it is NOT acceptable to twist a
technical disagreement into a personal attack, even by the slightest
insinuation.  Felipe, in my opinion your participation in the mailing
list lowers the tone dramatically, and will result in loss of other
contributors and the failure to attract new contributors.

Felipe, I wish that you would devote a small fraction of your prodigious
energy to the very difficult challenge of feeling empathy,
understanding, and respect for the other members of the community.  But
if things continue the way they have, I personally would, with sadness
in my heart, prefer to forgo your patches in exchange for the more
important benefit of a more collegial (and therefore overall more
productive and sustainable) community.

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/

[Sorry for the full quote, but sometimes, repetita iuvant]

On 06/09/2013 11:42 PM, Michael Haggerty wrote:

On 06/09/2013 09:11 PM, Johan Herland wrote:

quoted

[...]
FWIW, I'd like to express my support for the opinions expressed by
Jonathan, Jeff and Thomas. They accurately describe my impression of
these discussion threads.

I also agree.  In my opinion, Felipe, your abrasiveness, your disregard
of project standards, and your eternal argumentativeness outweigh the
benefit of your contributions, large though they may be.

Writing code is only a small part of keeping the Git project going.

* Reviewing code is an essential, more thankless, and therefore more
precious, contribution.  Therefore the Git project has standards to make
code review less unpleasant and more effective; for example: (1) patches
shouldn't cause regressions; (2) commit messages have to be written to
very high standards; (3) reviewers' comments should be accepted
gratefully and taken very seriously.  Almost everybody in the Git
community accepts these standards.  Felipe, you do not seem to.  The
result is that reviewers' time and goodwill are wasted, and they
justifiably feel unvalued.  We can't afford to misuse reviewers; they
are the bedrock (and the bottleneck) of the project.

* Gaining and keeping contributors is important to maintaining the
success of the project.  The mailing list is the main forum for the
development community; therefore, it is important that the mailing list
be a place where people display a high degree of technical excellence,
but also respect for one another, friendliness (or at least a lack of
hostility), and discussions that do turn into flame wars.  It is
possible to have a profound technical disagreement without losing
respect for the other side; contrariwise it is NOT acceptable to twist a
technical disagreement into a personal attack, even by the slightest
insinuation.  Felipe, in my opinion your participation in the mailing
list lowers the tone dramatically, and will result in loss of other
contributors and the failure to attract new contributors.

Felipe, I wish that you would devote a small fraction of your prodigious
energy to the very difficult challenge of feeling empathy,
understanding, and respect for the other members of the community.  But
if things continue the way they have, I personally would, with sadness
in my heart, prefer to forgo your patches in exchange for the more
important benefit of a more collegial (and therefore overall more
productive and sustainable) community.

Michael

FWIW, from the meager but I hope not utterly irrelevant point
of view of a non-contrib-but-not-clueless user as I am:

  *a complete and hear-felt +1 on what Michael said here*

Until a couple of months ago, skimming this list was mostly a real
pleasure, and would often give me some valuable insight on the
upcoming features/incompatibilities of Git, help me organize my own
workflow as a Git user, and also steadily improve my understanding
and command of netiquette in both "generic" mailing lists and Open
Source and/or Free Software communities.

Now, when I open my mail and get to the "git" folder, I more and
more end up asking myself:

  1. "What kind of flame am I going to have to see today?"; and

  2. "How much chaff will I have to navigate through to finally
      to get to interesting stuff (if any is actually left)?"

*To reiterate:*

Sadly, the environment of the Git mailing list has been steadily
and slowly *sinking* -- sinking from being pleasant and useful
and even "educational", into being annoying and frustrating and
often somewhat toxic.  I usually jeer and despise he who makes
public accusations by simply adding his voice to the disapproval
of the "community", but this time, I feel compelled to do exactly
that:

  I do accuse Felipe's *attitude* to bring on and nourish such
  unpleasantness toxicity.  His technical merits and the possible
  qualities of his patches do *nothing* to remove or quell such
  issues.

Sorry for the extra potential controversy, but sometimes one has
to speak up,

  Stefano

On Sun, Jun 9, 2013 at 4:42 PM, Michael Haggerty [off-list ref] wrote:

Felipe, I wish that you would devote a small fraction of your prodigious
energy to the very difficult challenge of feeling empathy,

I do feel empathy, the problem is that you make the assumption that
other people are like you, and that somehow I like the same things as
you; to be treated nicely. I don't.

understanding, and respect for the other members of the community.

Respect is not automatic.

But
if things continue the way they have, I personally would, with sadness
in my heart, prefer to forgo your patches in exchange for the more
important benefit of a more collegial (and therefore overall more
productive and sustainable) community.

In other words; you prefer to talk to people that have a similar mind
than you, and avoid doing what the project actually needs; code.

I wrote tons of code that help the project. And you avoid that because what?

Can you put the needs of the project about your personal need for
others to be nice towards you?

-- 
Felipe Contreras

On Sun, Jun 9, 2013 at 6:40 PM, Stefano Lattarini
[off-list ref] wrote:

  I do accuse Felipe's *attitude* to bring on and nourish such
  unpleasantness toxicity.  His technical merits and the possible
  qualities of his patches do *nothing* to remove or quell such
  issues.

How convenient to accuse me and not the others who have as much fault
if not more. You need two sides to have an argument.

The difference is; I did actually send code. Code that is good, code
that works, and code that users need.

-- 
Felipe Contreras

On 06/10/2013 07:15 AM, Felipe Contreras wrote:

On Sun, Jun 9, 2013 at 6:40 PM, Stefano Lattarini
[off-list ref] wrote:

quoted

  I do accuse Felipe's *attitude* to bring on and nourish such
  unpleasantness toxicity.  His technical merits and the possible
  qualities of his patches do *nothing* to remove or quell such
  issues.

How convenient to accuse me

I accuse your *attitude*, which IMHO is now even damaging your
code (that is, the acceptance of your code on the part of the
community).

and not the others who have as much fault if not more.

Sorry, this is just your opinion.  Mine, by observing the proceeding
from the outside, is different: my opinion is that your attitude is
the problem.

You need two sides to have an argument.

I disagree.  Unless you mean than, whenever a part behaves in a
hostile and aggressive way, the other part should just silently
knuckle under.

The difference is; I did actually send code. Code that is good, code
that works, and code that users need.

As I said, as a *user* (since I'm definitely not a Git developer
in any sense of the word), I also need a calm and constructive
environment in the community.  Or are you interested only in
users that can benefit from things you are good at?

Regards,
  Stefano

On Mon, Jun 10, 2013 at 4:05 AM, Stefano Lattarini
[off-list ref] wrote:

quoted

You need two sides to have an argument.

I disagree.  Unless you mean than, whenever a part behaves in a
hostile and aggressive way, the other part should just silently
knuckle under.

You are wrong. If a bum in the street starts talking about you about
why you are going to hell, and you reply to him and argue. Who has the
fault of starting an argument?

Both. Maybe you have even more blame.

-- 
Felipe Contreras

On Mon, Jun 10, 2013 at 9:58 AM, Felipe Contreras
[off-list ref] wrote:

On Mon, Jun 10, 2013 at 4:05 AM, Stefano Lattarini
[off-list ref] wrote:

quoted

quoted

You need two sides to have an argument.

quoted

I disagree.  Unless you mean than, whenever a part behaves in a
hostile and aggressive way, the other part should just silently
knuckle under.

You are wrong. If a bum in the street starts talking about you about
why you are going to hell, and you reply to him and argue. Who has the
fault of starting an argument?

I'm not sure I follow the analogy. Are you the bum or the passer-by?

Sorry, couldn't help it. :-)

On Mon, Jun 10, 2013 at 2:11 PM, Martin von Zweigbergk
[off-list ref] wrote:

On Mon, Jun 10, 2013 at 9:58 AM, Felipe Contreras
[off-list ref] wrote:

quoted

On Mon, Jun 10, 2013 at 4:05 AM, Stefano Lattarini
[off-list ref] wrote:

quoted

quoted

You need two sides to have an argument.

quoted

I disagree.  Unless you mean than, whenever a part behaves in a
hostile and aggressive way, the other part should just silently
knuckle under.

You are wrong. If a bum in the street starts talking about you about
why you are going to hell, and you reply to him and argue. Who has the
fault of starting an argument?

I'm not sure I follow the analogy. Are you the bum or the passer-by?

http://xkcd.com/386/

Someone is wrong on the Internet!

Let it be.


m
--
 martin.langhoff@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff

Yes, sorry. I find this whole story quite amusing (albeit distracting
and unnecessary), but sorry for adding to the spam. I'll be quiet now.

On Mon, Jun 10, 2013 at 11:33 AM, Martin Langhoff
[off-list ref] wrote:

On Mon, Jun 10, 2013 at 2:11 PM, Martin von Zweigbergk
[off-list ref] wrote:

quoted

On Mon, Jun 10, 2013 at 9:58 AM, Felipe Contreras
[off-list ref] wrote:

quoted

On Mon, Jun 10, 2013 at 4:05 AM, Stefano Lattarini
[off-list ref] wrote:

quoted

quoted

You need two sides to have an argument.

quoted

I disagree.  Unless you mean than, whenever a part behaves in a
hostile and aggressive way, the other part should just silently
knuckle under.

You are wrong. If a bum in the street starts talking about you about
why you are going to hell, and you reply to him and argue. Who has the
fault of starting an argument?

I'm not sure I follow the analogy. Are you the bum or the passer-by?

http://xkcd.com/386/

Someone is wrong on the Internet!

Let it be.


m
--
 martin.langhoff@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff

On Mon, Jun 10, 2013 at 1:11 PM, Martin von Zweigbergk
[off-list ref] wrote:

On Mon, Jun 10, 2013 at 9:58 AM, Felipe Contreras
[off-list ref] wrote:

quoted

On Mon, Jun 10, 2013 at 4:05 AM, Stefano Lattarini
[off-list ref] wrote:

quoted

quoted

You need two sides to have an argument.

quoted

I disagree.  Unless you mean than, whenever a part behaves in a
hostile and aggressive way, the other part should just silently
knuckle under.

You are wrong. If a bum in the street starts talking about you about
why you are going to hell, and you reply to him and argue. Who has the
fault of starting an argument?

I'm not sure I follow the analogy. Are you the bum or the passer-by?

It doesn't matter. Both sides are at fault of an argument.

-- 
Felipe Contreras

On 2013-06-09 13:01:30 -0500, Felipe Contreras wrote:

quoted

quoted

You don't agree that 1) a collegial work environment is overrated, 2)
that the Linux kernel doesn't put an emphasis on being collegial, or
3) that it's the most successful software project in history?

Point 1.

Good, so we agree that a project doesn't need a collegial work
environment to be extremely and amazingly successful. In fact, any
rational person would keep an open mind to the fact that perhaps it
actually _helps_ to not have such environment, based on the evidence.

Just from skimming both lists, most of the time I find lkml to be nicer
(and more collegial) to read because it has a better atmosphere than
git@ had in the last year or two.

And yes, a good atmosphere plays an important role. One of the reasons
is that it makes it easier to discern arguments based on personality
disputes - which certainly exist on lk - from actual technical
disagreements that need to be resolved.

Greetings,

Andres Freund

On Tue, Jun 11, 2013 at 4:18 AM, Andres Freund [off-list ref] wrote:

On 2013-06-09 13:01:30 -0500, Felipe Contreras wrote:

quoted

quoted

quoted

You don't agree that 1) a collegial work environment is overrated, 2)
that the Linux kernel doesn't put an emphasis on being collegial, or
3) that it's the most successful software project in history?

Point 1.

Good, so we agree that a project doesn't need a collegial work
environment to be extremely and amazingly successful. In fact, any
rational person would keep an open mind to the fact that perhaps it
actually _helps_ to not have such environment, based on the evidence.

Just from skimming both lists, most of the time I find lkml to be nicer
(and more collegial) to read because it has a better atmosphere than
git@ had in the last year or two.

A better atmosphere, yes, because they know how to avoid flamewars,
and concentrate on technical issues, not because they have a collegial
work environment.

Unless you think this reply[1] is collegial. Even though I haven't
been following Linux mailing lists that closely lately, I still manage
to see a lot of these kinds of replies.

And yes, a good atmosphere plays an important role. One of the reasons
is that it makes it easier to discern arguments based on personality
disputes - which certainly exist on lk - from actual technical
disagreements that need to be resolved.

That's right, but that's not because everyone is collegial in LKML,
which they most certainly are not. Linus being one of many examples.

[1] http://article.gmane.org/gmane.linux.usb.general/85952

-- 
Felipe Contreras

May be because they (LKM) are more open to such architectural and
organization refactorings?

Some maintainers, like Greg Kroah-Hartman and possibly others accept
clean up patches, such thing seems to be unacceptable here on git.
Looks like there is space here only for features and bug fixes.
Nothing else. I'm not saying that is bad at all.