{"thread":{"id":"34057","subject":"[PATCH 0/2] Move sequencer","startedAt":"2013-06-07T22:16:47Z","lastAt":"2013-06-20T21:11:16Z","messageCount":82,"participants":["Felipe Contreras","Duy Nguyen","Ramkumar Ramachandra","Jonathan Nieder","Jeff King","Thomas Rast","Johan Herland","Junio C Hamano","Michael Haggerty","Stefano Lattarini","Matthieu Moy","Martin von Zweigbergk","Martin Langhoff","Andres Freund","Thiago Farina"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"219751","messageId":"1370643409-3431-1-git-send-email-felipe.contreras@gmail.com","threadId":"34057","inReplyTo":null,"subject":"[PATCH 0/2] Move sequencer","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-07T22:16:47Z","receivedAt":"2013-06-07T22:16:47Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Hi,\n\nThis patch series moves the sequencer code which is only useful for builtin\ncommands, to builtin. This also creates the concept of 'builtin helpers'.\n\nFelipe Contreras (2):\n log-tree: remove dependency from sequencer\n Move sequencer to builtin\n\n Makefile | 9 ++-\n sequencer.c => builtin/sequencer.c | 160 +-----------------------------------\n sequencer.h => builtin/sequencer.h | 4 -\n log-tree.c | 161 ++++++++++++++++++++++++++++++++++++-\n log-tree.h | 3 +\n 5 files changed, 172 insertions(+), 165 deletions(-)\n rename sequencer.c => builtin/sequencer.c (87%)\n rename sequencer.h => builtin/sequencer.h (88%)\n\n-- \n1.8.3.698.g079b096\n"},{"id":"219753","messageId":"1370643409-3431-2-git-send-email-felipe.contreras@gmail.com","threadId":"34057","inReplyTo":"1370643409-3431-1-git-send-email-felipe.contreras@gmail.com","subject":"[PATCH 1/2] log-tree: remove dependency from sequencer","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-07T22:16:48Z","receivedAt":"2013-06-07T22:16:48Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Move the relevant code from sequencer to log-tree. This code is not\nspecific to sequencer, and this allows the sequencer to move out of\nlibgit.\n\nSigned-off-by: Felipe Contreras \n---\n log-tree.c | 161 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-\n log-tree.h | 3 ++\n sequencer.c | 160 ++---------------------------------------------------------\n sequencer.h | 4 --\n 4 files changed, 166 insertions(+), 162 deletions(-)\n\ndiff --git a/log-tree.c b/log-tree.c\nindex 2eb69bc..654f5db 100644\n--- a/log-tree.c\n+++ b/log-tree.c\n@@ -9,10 +9,13 @@\n #include \"string-list.h\"\n #include \"color.h\"\n #include \"gpg-interface.h\"\n-#include \"sequencer.h\"\n #include \"line-log.h\"\n \n+#define APPEND_SIGNOFF_DEDUP (1u << 0)\n+\n struct decoration name_decoration = { \"object names\" };\n+const char sign_off_header[] = \"Signed-off-by: \";\n+static const char cherry_picked_prefix[] = \"(cherry picked from commit \";\n \n enum decoration_type {\n \tDECORATION_NONE = 0,\n@@ -472,6 +475,162 @@ static void show_mergetag(struct rev_info *opt, struct commit *commit)\n \tfree_commit_extra_headers(to_free);\n }\n \n+static int is_rfc2822_line(const char *buf, int len)\n+{\n+\tint i;\n+\n+\tfor (i = 0; i < len; i++) {\n+\t\tint ch = buf[i];\n+\t\tif (ch == ':')\n+\t\t\treturn 1;\n+\t\tif (!isalnum(ch) && ch != '-')\n+\t\t\tbreak;\n+\t}\n+\n+\treturn 0;\n+}\n+\n+static int is_cherry_picked_from_line(const char *buf, int len)\n+{\n+\t/*\n+\t * We only care that it looks roughly like (cherry picked from ...)\n+\t */\n+\treturn len > strlen(cherry_picked_prefix) + 1 &&\n+\t\t!prefixcmp(buf, cherry_picked_prefix) && buf[len - 1] == ')';\n+}\n+\n+/*\n+ * Returns 0 for non-conforming footer\n+ * Returns 1 for conforming footer\n+ * Returns 2 when sob exists within conforming footer\n+ * Returns 3 when sob exists within conforming footer as last entry\n+ */\n+int has_conforming_footer(struct strbuf *sb, struct strbuf *sob,\n+\tint ignore_footer)\n+{\n+\tchar prev;\n+\tint i, k;\n+\tint len = sb->len - ignore_footer;\n+\tconst char *buf = sb->buf;\n+\tint found_sob = 0;\n+\n+\t/* footer must end with newline */\n+\tif (!len || buf[len - 1] != '\\n')\n+\t\treturn 0;\n+\n+\tprev = '\\0';\n+\tfor (i = len - 1; i > 0; i--) {\n+\t\tchar ch = buf[i];\n+\t\tif (prev == '\\n' && ch == '\\n') /* paragraph break */\n+\t\t\tbreak;\n+\t\tprev = ch;\n+\t}\n+\n+\t/* require at least one blank line */\n+\tif (prev != '\\n' || buf[i] != '\\n')\n+\t\treturn 0;\n+\n+\t/* advance to start of last paragraph */\n+\twhile (i < len - 1 && buf[i] == '\\n')\n+\t\ti++;\n+\n+\tfor (; i < len; i = k) {\n+\t\tint found_rfc2822;\n+\n+\t\tfor (k = i; k < len && buf[k] != '\\n'; k++)\n+\t\t\t; /* do nothing */\n+\t\tk++;\n+\n+\t\tfound_rfc2822 = is_rfc2822_line(buf + i, k - i - 1);\n+\t\tif (found_rfc2822 && sob &&\n+\t\t !strncmp(buf + i, sob->buf, sob->len))\n+\t\t\tfound_sob = k;\n+\n+\t\tif (!(found_rfc2822 ||\n+\t\t is_cherry_picked_from_line(buf + i, k - i - 1)))\n+\t\t\treturn 0;\n+\t}\n+\tif (found_sob == i)\n+\t\treturn 3;\n+\tif (found_sob)\n+\t\treturn 2;\n+\treturn 1;\n+}\n+\n+void append_cherrypick(struct strbuf *msgbuf, struct object *obj)\n+{\n+\tif (!has_conforming_footer(msgbuf, NULL, 0))\n+\t\tstrbuf_addch(msgbuf, '\\n');\n+\tstrbuf_addstr(msgbuf, cherry_picked_prefix);\n+\tstrbuf_addstr(msgbuf, sha1_to_hex(obj->sha1));\n+\tstrbuf_addstr(msgbuf, \")\\n\");\n+}\n+\n+void append_signoff(struct strbuf *msgbuf, int ignore_footer, unsigned flag)\n+{\n+\tunsigned no_dup_sob = flag & APPEND_SIGNOFF_DEDUP;\n+\tstruct strbuf sob = STRBUF_INIT;\n+\tint has_footer;\n+\n+\tstrbuf_addstr(&sob, sign_off_header);\n+\tstrbuf_addstr(&sob, fmt_name(getenv(\"GIT_COMMITTER_NAME\"),\n+\t\t\t\tgetenv(\"GIT_COMMITTER_EMAIL\")));\n+\tstrbuf_addch(&sob, '\\n');\n+\n+\t/*\n+\t * If the whole message buffer is equal to the sob, pretend that we\n+\t * found a conforming footer with a matching sob\n+\t */\n+\tif (msgbuf->len - ignore_footer == sob.len &&\n+\t !strncmp(msgbuf->buf, sob.buf, sob.len))\n+\t\thas_footer = 3;\n+\telse\n+\t\thas_footer = has_conforming_footer(msgbuf, &sob, ignore_footer);\n+\n+\tif (!has_footer) {\n+\t\tconst char *append_newlines = NULL;\n+\t\tsize_t len = msgbuf->len - ignore_footer;\n+\n+\t\tif (!len) {\n+\t\t\t/*\n+\t\t\t * The buffer is completely empty. Leave foom for\n+\t\t\t * the title and body to be filled in by the user.\n+\t\t\t */\n+\t\t\tappend_newlines = \"\\n\\n\";\n+\t\t} else if (msgbuf->buf[len - 1] != '\\n') {\n+\t\t\t/*\n+\t\t\t * Incomplete line. Complete the line and add a\n+\t\t\t * blank one so that there is an empty line between\n+\t\t\t * the message body and the sob.\n+\t\t\t */\n+\t\t\tappend_newlines = \"\\n\\n\";\n+\t\t} else if (len == 1) {\n+\t\t\t/*\n+\t\t\t * Buffer contains a single newline. Add another\n+\t\t\t * so that we leave room for the title and body.\n+\t\t\t */\n+\t\t\tappend_newlines = \"\\n\";\n+\t\t} else if (msgbuf->buf[len - 2] != '\\n') {\n+\t\t\t/*\n+\t\t\t * Buffer ends with a single newline. Add another\n+\t\t\t * so that there is an empty line between the message\n+\t\t\t * body and the sob.\n+\t\t\t */\n+\t\t\tappend_newlines = \"\\n\";\n+\t\t} /* else, the buffer already ends with two newlines. */\n+\n+\t\tif (append_newlines)\n+\t\t\tstrbuf_splice(msgbuf, msgbuf->len - ignore_footer, 0,\n+\t\t\t\tappend_newlines, strlen(append_newlines));\n+\t}\n+\n+\tif (has_footer != 3 && (!no_dup_sob || has_footer != 2))\n+\t\tstrbuf_splice(msgbuf, msgbuf->len - ignore_footer, 0,\n+\t\t\t\tsob.buf, sob.len);\n+\n+\tstrbuf_release(&sob);\n+}\n+\n void show_log(struct rev_info *opt)\n {\n \tstruct strbuf msgbuf = STRBUF_INIT;\ndiff --git a/log-tree.h b/log-tree.h\nindex d6ecd4d..1039e49 100644\n--- a/log-tree.h\n+++ b/log-tree.h\n@@ -25,4 +25,7 @@ void load_ref_decorations(int flags);\n void fmt_output_commit(struct strbuf *, struct commit *, struct rev_info *);\n void fmt_output_subject(struct strbuf *, const char *subject, struct rev_info *);\n \n+void append_cherrypick(struct strbuf *msgbuf, struct object *obj);\n+void append_signoff(struct strbuf *msgbuf, int ignore_footer, unsigned flag);\n+\n #endif\ndiff --git a/sequencer.c b/sequencer.c\nindex ab6f8a7..e92e039 100644\n--- a/sequencer.c\n+++ b/sequencer.c\n@@ -14,94 +14,10 @@\n #include \"merge-recursive.h\"\n #include \"refs.h\"\n #include \"argv-array.h\"\n+#include \"log-tree.h\"\n \n #define GIT_REFLOG_ACTION \"GIT_REFLOG_ACTION\"\n \n-const char sign_off_header[] = \"Signed-off-by: \";\n-static const char cherry_picked_prefix[] = \"(cherry picked from commit \";\n-\n-static int is_rfc2822_line(const char *buf, int len)\n-{\n-\tint i;\n-\n-\tfor (i = 0; i < len; i++) {\n-\t\tint ch = buf[i];\n-\t\tif (ch == ':')\n-\t\t\treturn 1;\n-\t\tif (!isalnum(ch) && ch != '-')\n-\t\t\tbreak;\n-\t}\n-\n-\treturn 0;\n-}\n-\n-static int is_cherry_picked_from_line(const char *buf, int len)\n-{\n-\t/*\n-\t * We only care that it looks roughly like (cherry picked from ...)\n-\t */\n-\treturn len > strlen(cherry_picked_prefix) + 1 &&\n-\t\t!prefixcmp(buf, cherry_picked_prefix) && buf[len - 1] == ')';\n-}\n-\n-/*\n- * Returns 0 for non-conforming footer\n- * Returns 1 for conforming footer\n- * Returns 2 when sob exists within conforming footer\n- * Returns 3 when sob exists within conforming footer as last entry\n- */\n-static int has_conforming_footer(struct strbuf *sb, struct strbuf *sob,\n-\tint ignore_footer)\n-{\n-\tchar prev;\n-\tint i, k;\n-\tint len = sb->len - ignore_footer;\n-\tconst char *buf = sb->buf;\n-\tint found_sob = 0;\n-\n-\t/* footer must end with newline */\n-\tif (!len || buf[len - 1] != '\\n')\n-\t\treturn 0;\n-\n-\tprev = '\\0';\n-\tfor (i = len - 1; i > 0; i--) {\n-\t\tchar ch = buf[i];\n-\t\tif (prev == '\\n' && ch == '\\n') /* paragraph break */\n-\t\t\tbreak;\n-\t\tprev = ch;\n-\t}\n-\n-\t/* require at least one blank line */\n-\tif (prev != '\\n' || buf[i] != '\\n')\n-\t\treturn 0;\n-\n-\t/* advance to start of last paragraph */\n-\twhile (i < len - 1 && buf[i] == '\\n')\n-\t\ti++;\n-\n-\tfor (; i < len; i = k) {\n-\t\tint found_rfc2822;\n-\n-\t\tfor (k = i; k < len && buf[k] != '\\n'; k++)\n-\t\t\t; /* do nothing */\n-\t\tk++;\n-\n-\t\tfound_rfc2822 = is_rfc2822_line(buf + i, k - i - 1);\n-\t\tif (found_rfc2822 && sob &&\n-\t\t !strncmp(buf + i, sob->buf, sob->len))\n-\t\t\tfound_sob = k;\n-\n-\t\tif (!(found_rfc2822 ||\n-\t\t is_cherry_picked_from_line(buf + i, k - i - 1)))\n-\t\t\treturn 0;\n-\t}\n-\tif (found_sob == i)\n-\t\treturn 3;\n-\tif (found_sob)\n-\t\treturn 2;\n-\treturn 1;\n-}\n-\n static void remove_sequencer_state(void)\n {\n \tstruct strbuf seq_dir = STRBUF_INIT;\n@@ -578,13 +494,8 @@ static int do_pick_commit(struct commit *commit, struct replay_opts *opts)\n \t\t\tstrbuf_addstr(&msgbuf, p);\n \t\t}\n \n-\t\tif (opts->record_origin) {\n-\t\t\tif (!has_conforming_footer(&msgbuf, NULL, 0))\n-\t\t\t\tstrbuf_addch(&msgbuf, '\\n');\n-\t\t\tstrbuf_addstr(&msgbuf, cherry_picked_prefix);\n-\t\t\tstrbuf_addstr(&msgbuf, sha1_to_hex(commit->object.sha1));\n-\t\t\tstrbuf_addstr(&msgbuf, \")\\n\");\n-\t\t}\n+\t\tif (opts->record_origin)\n+\t\t\tappend_cherrypick(&msgbuf, &commit->object);\n \t}\n \n \tif (!opts->strategy || !strcmp(opts->strategy, \"recursive\") || opts->action == REPLAY_REVERT) {\n@@ -1123,68 +1034,3 @@ int sequencer_pick_revisions(struct replay_opts *opts)\n \tsave_opts(opts);\n \treturn pick_commits(todo_list, opts);\n }\n-\n-void append_signoff(struct strbuf *msgbuf, int ignore_footer, unsigned flag)\n-{\n-\tunsigned no_dup_sob = flag & APPEND_SIGNOFF_DEDUP;\n-\tstruct strbuf sob = STRBUF_INIT;\n-\tint has_footer;\n-\n-\tstrbuf_addstr(&sob, sign_off_header);\n-\tstrbuf_addstr(&sob, fmt_name(getenv(\"GIT_COMMITTER_NAME\"),\n-\t\t\t\tgetenv(\"GIT_COMMITTER_EMAIL\")));\n-\tstrbuf_addch(&sob, '\\n');\n-\n-\t/*\n-\t * If the whole message buffer is equal to the sob, pretend that we\n-\t * found a conforming footer with a matching sob\n-\t */\n-\tif (msgbuf->len - ignore_footer == sob.len &&\n-\t !strncmp(msgbuf->buf, sob.buf, sob.len))\n-\t\thas_footer = 3;\n-\telse\n-\t\thas_footer = has_conforming_footer(msgbuf, &sob, ignore_footer);\n-\n-\tif (!has_footer) {\n-\t\tconst char *append_newlines = NULL;\n-\t\tsize_t len = msgbuf->len - ignore_footer;\n-\n-\t\tif (!len) {\n-\t\t\t/*\n-\t\t\t * The buffer is completely empty. Leave foom for\n-\t\t\t * the title and body to be filled in by the user.\n-\t\t\t */\n-\t\t\tappend_newlines = \"\\n\\n\";\n-\t\t} else if (msgbuf->buf[len - 1] != '\\n') {\n-\t\t\t/*\n-\t\t\t * Incomplete line. Complete the line and add a\n-\t\t\t * blank one so that there is an empty line between\n-\t\t\t * the message body and the sob.\n-\t\t\t */\n-\t\t\tappend_newlines = \"\\n\\n\";\n-\t\t} else if (len == 1) {\n-\t\t\t/*\n-\t\t\t * Buffer contains a single newline. Add another\n-\t\t\t * so that we leave room for the title and body.\n-\t\t\t */\n-\t\t\tappend_newlines = \"\\n\";\n-\t\t} else if (msgbuf->buf[len - 2] != '\\n') {\n-\t\t\t/*\n-\t\t\t * Buffer ends with a single newline. Add another\n-\t\t\t * so that there is an empty line between the message\n-\t\t\t * body and the sob.\n-\t\t\t */\n-\t\t\tappend_newlines = \"\\n\";\n-\t\t} /* else, the buffer already ends with two newlines. */\n-\n-\t\tif (append_newlines)\n-\t\t\tstrbuf_splice(msgbuf, msgbuf->len - ignore_footer, 0,\n-\t\t\t\tappend_newlines, strlen(append_newlines));\n-\t}\n-\n-\tif (has_footer != 3 && (!no_dup_sob || has_footer != 2))\n-\t\tstrbuf_splice(msgbuf, msgbuf->len - ignore_footer, 0,\n-\t\t\t\tsob.buf, sob.len);\n-\n-\tstrbuf_release(&sob);\n-}\ndiff --git a/sequencer.h b/sequencer.h\nindex 1fc22dc..c341918 100644\n--- a/sequencer.h\n+++ b/sequencer.h\n@@ -6,8 +6,6 @@\n #define SEQ_TODO_FILE\t\"sequencer/todo\"\n #define SEQ_OPTS_FILE\t\"sequencer/opts\"\n \n-#define APPEND_SIGNOFF_DEDUP (1u << 0)\n-\n enum replay_action {\n \tREPLAY_REVERT,\n \tREPLAY_PICK\n@@ -50,6 +48,4 @@ int sequencer_pick_revisions(struct replay_opts *opts);\n \n extern const char sign_off_header[];\n \n-void append_signoff(struct strbuf *msgbuf, int ignore_footer, unsigned flag);\n-\n #endif\n-- \n1.8.3.698.g079b096\n"},{"id":"219752","messageId":"1370643409-3431-3-git-send-email-felipe.contreras@gmail.com","threadId":"34057","inReplyTo":"1370643409-3431-1-git-send-email-felipe.contreras@gmail.com","subject":"[PATCH 2/2] Move sequencer to builtin","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-07T22:16:49Z","receivedAt":"2013-06-07T22:16:49Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"This code is only useful for cherry-pick and revert built-ins, nothing\nelse, so let's make it a builtin object, but make sure 'git-sequencer'\nis not generated.\n\nSigned-off-by: Felipe Contreras \n---\n Makefile | 9 ++++++---\n sequencer.c => builtin/sequencer.c | 0\n sequencer.h => builtin/sequencer.h | 0\n 3 files changed, 6 insertions(+), 3 deletions(-)\n rename sequencer.c => builtin/sequencer.c (100%)\n rename sequencer.h => builtin/sequencer.h (100%)\n\ndiff --git a/Makefile b/Makefile\nindex 03524d0..d28bf7f 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -583,7 +583,8 @@ TEST_PROGRAMS = $(patsubst %,%$X,$(TEST_PROGRAMS_NEED_X))\n \n # List built-in command $C whose implementation cmd_$C() is not in\n # builtin/$C.o but is linked in as part of some other command.\n-BUILT_INS += $(patsubst builtin/%.o,git-%$X,$(BUILTIN_OBJS))\n+BUILT_INS_OBJS = $(filter-out $(BUILTIN_HELPER_OBJS),$(BUILTIN_OBJS))\n+BUILT_INS += $(patsubst builtin/%.o,git-%$X,$(BUILT_INS_OBJS))\n \n BUILT_INS += git-cherry$X\n BUILT_INS += git-cherry-pick$X\n@@ -714,7 +715,6 @@ LIB_H += resolve-undo.h\n LIB_H += revision.h\n LIB_H += run-command.h\n LIB_H += send-pack.h\n-LIB_H += sequencer.h\n LIB_H += sha1-array.h\n LIB_H += sha1-lookup.h\n LIB_H += shortlog.h\n@@ -856,7 +856,6 @@ LIB_OBJS += resolve-undo.o\n LIB_OBJS += revision.o\n LIB_OBJS += run-command.o\n LIB_OBJS += send-pack.o\n-LIB_OBJS += sequencer.o\n LIB_OBJS += server-info.o\n LIB_OBJS += setup.o\n LIB_OBJS += sha1-array.o\n@@ -894,6 +893,8 @@ LIB_OBJS += wt-status.o\n LIB_OBJS += xdiff-interface.o\n LIB_OBJS += zlib.o\n \n+BUILTIN_HELPER_OBJS += builtin/sequencer.o\n+\n BUILTIN_OBJS += builtin/add.o\n BUILTIN_OBJS += builtin/annotate.o\n BUILTIN_OBJS += builtin/apply.o\n@@ -990,6 +991,8 @@ BUILTIN_OBJS += builtin/verify-pack.o\n BUILTIN_OBJS += builtin/verify-tag.o\n BUILTIN_OBJS += builtin/write-tree.o\n \n+BUILTIN_OBJS += $(BUILTIN_HELPER_OBJS)\n+\n GITLIBS = $(LIB_FILE) $(XDIFF_LIB)\n EXTLIBS =\n \ndiff --git a/sequencer.c b/builtin/sequencer.c\nsimilarity index 100%\nrename from sequencer.c\nrename to builtin/sequencer.c\ndiff --git a/sequencer.h b/builtin/sequencer.h\nsimilarity index 100%\nrename from sequencer.h\nrename to builtin/sequencer.h\n-- \n1.8.3.698.g079b096\n"},{"id":"219779","messageId":"CACsJy8AMMCWSFC6EUHAgZdDA7E1kSPE3ZO6qGvS+WGji-di=Rw@mail.gmail.com","threadId":"34057","inReplyTo":"1370643409-3431-3-git-send-email-felipe.contreras@gmail.com","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2013-06-08T02:35:37Z","receivedAt":"2013-06-08T02:35:37Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Sat, Jun 8, 2013 at 5:16 AM, Felipe Contreras\n wrote:\n> This code is only useful for cherry-pick and revert built-ins, nothing\n> else, so let's make it a builtin object, but make sure 'git-sequencer'\n> is not generated.\n\nAs you can see, the convention is builtin/foo.c corresponds to git-foo\n(and maybe more). Why make an exception for sequencer? What do we gain\nfrom this? A lot of code in libgit.a is only used by builtin commands,\ne.g. fetch-pack.c, should we move it to? I ask because I moved\nfetch-pack from builtin out because of linking issues and I don't want\nthe same happen to sequencer.c.\n-- \nDuy\n"},{"id":"219783","messageId":"CALkWK0nbC3jfapvJKuh=m3s1n+GWfTYbhb5DWEjNrFDimQF-KA@mail.gmail.com","threadId":"34057","inReplyTo":"1370643409-3431-1-git-send-email-felipe.contreras@gmail.com","subject":"Re: [PATCH 0/2] Move sequencer","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-06-08T03:35:01Z","receivedAt":"2013-06-08T03:35:01Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Felipe Contreras wrote:\n> sequencer.c => builtin/sequencer.c | 160 +-----------------------------------\n> sequencer.h => builtin/sequencer.h | 4 -\n\nWhy exactly? The plan was to unify continuation semantics, and get\nall the continuation-commands to use the sequencer. That clearly\nhasn't materialized, but I don't know what this move buys us.\n"},{"id":"219795","messageId":"CAMP44s29GiGJq3wyXAzJNo0FJY+Vbgd18bpBJMYQ47h-3M6sWA@mail.gmail.com","threadId":"34057","inReplyTo":"CACsJy8AMMCWSFC6EUHAgZdDA7E1kSPE3ZO6qGvS+WGji-di=Rw@mail.gmail.com","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-08T10:14:46Z","receivedAt":"2013-06-08T10:14:46Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Fri, Jun 7, 2013 at 9:35 PM, Duy Nguyen wrote:\n> On Sat, Jun 8, 2013 at 5:16 AM, Felipe Contreras\n> wrote:\n>> This code is only useful for cherry-pick and revert built-ins, nothing\n>> else, so let's make it a builtin object, but make sure 'git-sequencer'\n>> is not generated.\n>\n> As you can see, the convention is builtin/foo.c corresponds to git-foo\n> (and maybe more). Why make an exception for sequencer?\n\nWhy not?\n\n> What do we gain from this?\n\nOrganization.\n\n> A lot of code in libgit.a is only used by builtin commands,\n> e.g. fetch-pack.c, should we move it to?\n\nYes.\n\n> I ask because I moved\n> fetch-pack from builtin out because of linking issues and I don't want\n> the same happen to sequencer.c.\n\nI'm sure those linking issues can be solved.\n\nI don't see why libgit.a couldn't eventually be the same as libgit2.\nWe need better organization tough (e.g. builtins/lib.a).\n\nIf you are arguing favor of a more messy setup, then we should link\nall the builtin/*.o to libgit.a, because the current situation just\ndoesn't cut it.\n\nFor example, init_copy_notes_for_rewrite() cannot be accessed by\nsequencer.c, and while it's possible to move that function (and\nothers) to libgit.a, it doesn't make sense, because it can only be\nused by builtins.\n\n-- \nFelipe Contreras\n"},{"id":"219798","messageId":"CAMP44s2VpqTDW0GzNMmEmxt-VVwnLEyTjHLV9MQhqd2yqpYFDA@mail.gmail.com","threadId":"34057","inReplyTo":"CALkWK0nbC3jfapvJKuh=m3s1n+GWfTYbhb5DWEjNrFDimQF-KA@mail.gmail.com","subject":"Re: [PATCH 0/2] Move sequencer","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-08T10:26:00Z","receivedAt":"2013-06-08T10:26:00Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Fri, Jun 7, 2013 at 10:35 PM, Ramkumar Ramachandra\n wrote:\n> Felipe Contreras wrote:\n>> sequencer.c => builtin/sequencer.c | 160 +-----------------------------------\n>> sequencer.h => builtin/sequencer.h | 4 -\n>\n> Why exactly? The plan was to unify continuation semantics, and get\n> all the continuation-commands to use the sequencer. That clearly\n> hasn't materialized, but I don't know what this move buys us.\n\nSo? The sequencer is only used by builtin commands, and other\ncontinuation commands are also builtins.\n\nThe sequencer needs to access methods from builtins/*.o, so unless you\npropose that libgit.a includes all the objects in builtins/*.o, this\nis the way to go.\n\n-- \nFelipe Contreras\n"},{"id":"219802","messageId":"CACsJy8A-qc0tHcsp5=syxv_7FjixahU7fGcZuUV=cGn_-qyWwg@mail.gmail.com","threadId":"34057","inReplyTo":"CAMP44s29GiGJq3wyXAzJNo0FJY+Vbgd18bpBJMYQ47h-3M6sWA@mail.gmail.com","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2013-06-08T11:42:29Z","receivedAt":"2013-06-08T11:42:29Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Sat, Jun 8, 2013 at 5:14 PM, Felipe Contreras\n wrote:\n> On Fri, Jun 7, 2013 at 9:35 PM, Duy Nguyen wrote:\n>> On Sat, Jun 8, 2013 at 5:16 AM, Felipe Contreras\n>> wrote:\n>>> This code is only useful for cherry-pick and revert built-ins, nothing\n>>> else, so let's make it a builtin object, but make sure 'git-sequencer'\n>>> is not generated.\n>>\n>> As you can see, the convention is builtin/foo.c corresponds to git-foo\n>> (and maybe more). Why make an exception for sequencer?\n>\n> Why not?\n\nAnd while we are at \"why not\", why don't you fork git?\n\n>> I ask because I moved\n>> fetch-pack from builtin out because of linking issues and I don't want\n>> the same happen to sequencer.c.\n>\n> I'm sure those linking issues can be solved.\n\nYeah, I scratched my head for hours and finally gave in. Maybe you are\nbetter at the toolchain than me.\n\n> I don't see why libgit.a couldn't eventually be the same as libgit2.\n> We need better organization tough (e.g. builtins/lib.a).\n>\n> If you are arguing favor of a more messy setup, then we should link\n> all the builtin/*.o to libgit.a, because the current situation just\n> doesn't cut it.\n>\n> For example, init_copy_notes_for_rewrite() cannot be accessed by\n> sequencer.c, and while it's possible to move that function (and\n> others) to libgit.a, it doesn't make sense, because it can only be\n> used by builtins.\n\nlibgit.a is just a way of grouping a bunch of objects together, not a\nreal library and not meant to be. If you aim something more organized,\nplease show at least a roadmap what to move where.\n--\nDuy\n"},{"id":"219810","messageId":"CAMP44s2fP4_=HtOsuwmxXG8qmp8CmpgEhz=BJFOFZxsTf_3gcQ@mail.gmail.com","threadId":"34057","inReplyTo":"CACsJy8A-qc0tHcsp5=syxv_7FjixahU7fGcZuUV=cGn_-qyWwg@mail.gmail.com","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-08T12:25:32Z","receivedAt":"2013-06-08T12:25:32Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sat, Jun 8, 2013 at 6:42 AM, Duy Nguyen wrote:\n> On Sat, Jun 8, 2013 at 5:14 PM, Felipe Contreras\n> wrote:\n>> On Fri, Jun 7, 2013 at 9:35 PM, Duy Nguyen wrote:\n>>> On Sat, Jun 8, 2013 at 5:16 AM, Felipe Contreras\n>>> wrote:\n>>>> This code is only useful for cherry-pick and revert built-ins, nothing\n>>>> else, so let's make it a builtin object, but make sure 'git-sequencer'\n>>>> is not generated.\n>>>\n>>> As you can see, the convention is builtin/foo.c corresponds to git-foo\n>>> (and maybe more). Why make an exception for sequencer?\n>>\n>> Why not?\n>\n> And while we are at \"why not\", why don't you fork git?\n\nThat's not an answer.\n\n>>> I ask because I moved\n>>> fetch-pack from builtin out because of linking issues and I don't want\n>>> the same happen to sequencer.c.\n>>\n>> I'm sure those linking issues can be solved.\n>\n> Yeah, I scratched my head for hours and finally gave in. Maybe you are\n> better at the toolchain than me.\n\nI gave it a try, but transport.c needs fetch_pack(), and transport\ndoes belong in libgit.a, so fetch_pack() belongs there too.\n\nThis is not the case for sequencer.c.\n\n>> I don't see why libgit.a couldn't eventually be the same as libgit2.\n>> We need better organization tough (e.g. builtins/lib.a).\n>>\n>> If you are arguing favor of a more messy setup, then we should link\n>> all the builtin/*.o to libgit.a, because the current situation just\n>> doesn't cut it.\n>>\n>> For example, init_copy_notes_for_rewrite() cannot be accessed by\n>> sequencer.c, and while it's possible to move that function (and\n>> others) to libgit.a, it doesn't make sense, because it can only be\n>> used by builtins.\n>\n> libgit.a is just a way of grouping a bunch of objects together, not a\n> real library\n\nThat's what a library is.\n\n> and not meant to be. If you aim something more organized,\n> please show at least a roadmap what to move where.\n\nI already did that; we move code from libgit.a to builtin/*.o until\nlibgit.a == libgit2. Done.\n\n-- \nFelipe Contreras\n"},{"id":"219811","messageId":"CACsJy8CQRWU0mFLVD6RrpzJiHBH=9zFwf5xDo7UhGW6A-OAzuw@mail.gmail.com","threadId":"34057","inReplyTo":"CAMP44s2fP4_=HtOsuwmxXG8qmp8CmpgEhz=BJFOFZxsTf_3gcQ@mail.gmail.com","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2013-06-08T12:34:03Z","receivedAt":"2013-06-08T12:34:03Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Sat, Jun 8, 2013 at 7:25 PM, Felipe Contreras\n wrote:\n> On Sat, Jun 8, 2013 at 6:42 AM, Duy Nguyen wrote:\n>> On Sat, Jun 8, 2013 at 5:14 PM, Felipe Contreras\n>> wrote:\n>>> On Fri, Jun 7, 2013 at 9:35 PM, Duy Nguyen wrote:\n>>>> On Sat, Jun 8, 2013 at 5:16 AM, Felipe Contreras\n>>>> wrote:\n>>>>> This code is only useful for cherry-pick and revert built-ins, nothing\n>>>>> else, so let's make it a builtin object, but make sure 'git-sequencer'\n>>>>> is not generated.\n>>>>\n>>>> As you can see, the convention is builtin/foo.c corresponds to git-foo\n>>>> (and maybe more). Why make an exception for sequencer?\n>>>\n>>> Why not?\n>>\n>> And while we are at \"why not\", why don't you fork git?\n>\n> That's not an answer.\n\nNeither is \"Why not?\"\n\n>> and not meant to be. If you aim something more organized,\n>> please show at least a roadmap what to move where.\n>\n> I already did that; we move code from libgit.a to builtin/*.o\n\nwhat code besides sequencer.c?\n\n> until libgit.a == libgit2. Done.\n\nRead up about the introduction of libgit2, why it was created in the\nfirst place instead of moving a few files around renaming libgit.a to\nlibgit2.a. Unless you have a different definition of \"==\" than I do.\n--\nDuy\n"},{"id":"219812","messageId":"CALkWK0mLoeO5fKezE5S1LEC2LNH9qCwxHnNi_ZJpYzC7rVTqmg@mail.gmail.com","threadId":"34057","inReplyTo":"CACsJy8CQRWU0mFLVD6RrpzJiHBH=9zFwf5xDo7UhGW6A-OAzuw@mail.gmail.com","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-06-08T12:55:22Z","receivedAt":"2013-06-08T12:55:22Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Duy Nguyen wrote:\n>> until libgit.a == libgit2. Done.\n>\n> Read up about the introduction of libgit2, why it was created in the\n> first place instead of moving a few files around renaming libgit.a to\n> libgit2.a. Unless you have a different definition of \"==\" than I do.\n\nAs far as I know, there was never an extensive on-list discussion\nabout why git.git cannot be lib'ified. The first appearance of\nlibgit2 is here [1]. I briefly read through the initial history of\nlibgit2.git too, but I cannot find a single discussion detailing why\nlib'ifying git.git is fundamentally unworkable (there's some vague\nmention of \"global state baggage\" and \"presence of die()\", but that's\nabout it). Unless you can point to some detailed discussions, or\nwrite out a really good reason yourself, I don't think there's any\nharm in letting fc try. Ofcourse, he still indicated any sort of plan\nyet, and I'm also waiting for that.\n\n[1]: http://thread.gmane.org/gmane.comp.version-control.git/99608\n"},{"id":"219814","messageId":"CACsJy8B=m95mpRn1dAwQZAvHRUeJVjKy1hKXv43EKX08ZODsDw@mail.gmail.com","threadId":"34057","inReplyTo":"CALkWK0mLoeO5fKezE5S1LEC2LNH9qCwxHnNi_ZJpYzC7rVTqmg@mail.gmail.com","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2013-06-08T13:15:56Z","receivedAt":"2013-06-08T13:15:56Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Sat, Jun 8, 2013 at 7:55 PM, Ramkumar Ramachandra wrote:\n> Duy Nguyen wrote:\n>>> until libgit.a == libgit2. Done.\n>>\n>> Read up about the introduction of libgit2, why it was created in the\n>> first place instead of moving a few files around renaming libgit.a to\n>> libgit2.a. Unless you have a different definition of \"==\" than I do.\n>\n> As far as I know, there was never an extensive on-list discussion\n> about why git.git cannot be lib'ified. The first appearance of\n> libgit2 is here [1]. I briefly read through the initial history of\n> libgit2.git too, but I cannot find a single discussion detailing why\n> lib'ifying git.git is fundamentally unworkable (there's some vague\n> mention of \"global state baggage\" and \"presence of die()\", but that's\n> about it). Unless you can point to some detailed discussions, or\n> write out a really good reason yourself, I don't think there's any\n> harm in letting fc try. Ofcourse, he still indicated any sort of plan\n> yet, and I'm also waiting for that.\n>\n> [1]: http://thread.gmane.org/gmane.comp.version-control.git/99608\n\nHm.. I thought Shawn wrote a bit more in that mail. Apparently I was\nwrong. I think it's discuessed in the list from time to time\n(otherwise I wouldn't know) but I don't keep bookmarks.\n\nI _think_ the reason is because git was never written as a reusable\nlibrary in mind from the beginning. So global states and die() exist.\nWorse, \"run once and let the OS clean eveything up at process exit\"\nleads to some deliberate memory leak if it's made a library. See\nalloc.c for example. The internal API is not really designed to be\nusuable/stable as a library. All of these made it very hard to convert\nthe current code base into a true library. So the effort was put into\ncreating a new library instead, copying code from git code base over\nwhen possible.\n\nSo instead of redoing it again, I think it's better that you help\nlibgit2 guys improve it to the extend that git commands can be easily\nreimplemented. Then bring up the discussion about using libgit2 in C\nGit again.\n--\nDuy\n"},{"id":"219818","messageId":"CAMP44s0EVESLfRUw7Aqz6VjXELcRG-6cETpcROTZXmPjU-Y8ig@mail.gmail.com","threadId":"34057","inReplyTo":"CACsJy8CQRWU0mFLVD6RrpzJiHBH=9zFwf5xDo7UhGW6A-OAzuw@mail.gmail.com","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-08T13:28:44Z","receivedAt":"2013-06-08T13:28:44Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sat, Jun 8, 2013 at 7:34 AM, Duy Nguyen wrote:\n> On Sat, Jun 8, 2013 at 7:25 PM, Felipe Contreras\n> wrote:\n>> On Sat, Jun 8, 2013 at 6:42 AM, Duy Nguyen wrote:\n>>> On Sat, Jun 8, 2013 at 5:14 PM, Felipe Contreras\n>>> wrote:\n>>>> On Fri, Jun 7, 2013 at 9:35 PM, Duy Nguyen wrote:\n>>>>> On Sat, Jun 8, 2013 at 5:16 AM, Felipe Contreras\n>>>>> wrote:\n>>>>>> This code is only useful for cherry-pick and revert built-ins, nothing\n>>>>>> else, so let's make it a builtin object, but make sure 'git-sequencer'\n>>>>>> is not generated.\n>>>>>\n>>>>> As you can see, the convention is builtin/foo.c corresponds to git-foo\n>>>>> (and maybe more). Why make an exception for sequencer?\n>>>>\n>>>> Why not?\n>>>\n>>> And while we are at \"why not\", why don't you fork git?\n>>\n>> That's not an answer.\n>\n> Neither is \"Why not?\"\n\nThe answer is the rest of the e-mail.\n\n>>> and not meant to be. If you aim something more organized,\n>>> please show at least a roadmap what to move where.\n>>\n>> I already did that; we move code from libgit.a to builtin/*.o\n>\n> what code besides sequencer.c?\n\nA roadmap doesn't require code. If you truly think that there's\nnothing else that is specific to builtins; alias.c.\n\n>> until libgit.a == libgit2. Done.\n>\n> Read up about the introduction of libgit2, why it was created in the\n> first place instead of moving a few files around renaming libgit.a to\n> libgit2.a. Unless you have a different definition of \"==\" than I do.\n\nAre you being obtuse on purpose? It doesn't matter how different\nlibgit.a and libgit2 currently are, there's always a path from one\ncode-base to another. Unless libgit2 has code for builtin commands,\nthe first step would invariably be to move the code that is specific\nfor builtins to builtin/*.o.\n\n-- \nFelipe Contreras\n"},{"id":"219819","messageId":"CAMP44s1Y++qNEDHHFX2Jhv7rm081SeZ=7bfbo1ZW+ctQgO2QBQ@mail.gmail.com","threadId":"34057","inReplyTo":"CACsJy8B=m95mpRn1dAwQZAvHRUeJVjKy1hKXv43EKX08ZODsDw@mail.gmail.com","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-08T13:32:04Z","receivedAt":"2013-06-08T13:32:04Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sat, Jun 8, 2013 at 8:15 AM, Duy Nguyen wrote:\n\n> So instead of redoing it again, I think it's better that you help\n> libgit2 guys improve it to the extend that git commands can be easily\n> reimplemented. Then bring up the discussion about using libgit2 in C\n> Git again.\n\nThere's no reason not to move libgit2 closer to libgit.a, and libgit.a\ncloser to libgit2, both at the same time. I have rewritten a lot of\ncode using this strategy.\n\n-- \nFelipe Contreras\n"},{"id":"219820","messageId":"CALkWK0mw8=CMuyw5-E0fzh+c6Om_NCgHohqa_p=J_kw3UfJCJQ@mail.gmail.com","threadId":"34057","inReplyTo":"CACsJy8B=m95mpRn1dAwQZAvHRUeJVjKy1hKXv43EKX08ZODsDw@mail.gmail.com","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-06-08T13:34:17Z","receivedAt":"2013-06-08T13:34:17Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Duy Nguyen wrote:\n> I _think_ the reason is because git was never written as a reusable\n> library in mind from the beginning.\n\nWe cannot reverse-engineer intents, but I tend to agree with this. My\nquestion is: so what? Is it impossible to do now?\n\n> So global states and die() exist.\n> Worse, \"run once and let the OS clean eveything up at process exit\"\n> leads to some deliberate memory leak if it's made a library. See\n> alloc.c for example. The internal API is not really designed to be\n> usuable/stable as a library. All of these made it very hard to convert\n> the current code base into a true library. So the effort was put into\n> creating a new library instead, copying code from git code base over\n> when possible.\n\nI'm not saying that we can convert libgit.a into something that's\nusable as a long-running process by production servers tomorrow. All\nI'm saying is that it might be possible to get ruby (and possibly\nother languages) to call into git-core, to make scripting more sane\nthan shell-spawning everything like brutes. I think this is what fc\nis aiming at, atleast in the foreseeable future.\n\nAs far as long-running server-side implementations go, I think jgit is\nthe way forward (sop is more interested in that now, I believe).\nlibgit2 might work for GitHub now, but I don't know if they will be\nforced to move to the jvm in the future.\n\n> So instead of redoing it again, I think it's better that you help\n> libgit2 guys improve it to the extend that git commands can be easily\n> reimplemented. Then bring up the discussion about using libgit2 in C\n> Git again.\n\nPlease look at the code in libgit2.git briefly. It's _very_ different\nfrom git.git, and the amount of glue code that would be needed to\npiece them together is unfathomable.\n\nThere are no git.git contributors committing to libgit2.git, or\nvice-versa. libgit2 is primarily developed by vmg, cmn, and (more\nrecently) rb. It's quite an active project that's diverging from the\ngit.git design with every passing day.\n"},{"id":"219827","messageId":"CAMP44s0gbddk+UQXqj8D1U4L8jBRciWkJT_g4CbzcTP1oQrzLQ@mail.gmail.com","threadId":"34057","inReplyTo":"CALkWK0mw8=CMuyw5-E0fzh+c6Om_NCgHohqa_p=J_kw3UfJCJQ@mail.gmail.com","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-08T14:10:47Z","receivedAt":"2013-06-08T14:10:47Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sat, Jun 8, 2013 at 8:34 AM, Ramkumar Ramachandra wrote:\n> Duy Nguyen wrote:\n>> I _think_ the reason is because git was never written as a reusable\n>> library in mind from the beginning.\n>\n> We cannot reverse-engineer intents, but I tend to agree with this. My\n> question is: so what? Is it impossible to do now?\n\nNothing is impossible.\n\nMy feeling is that no Git developers are interested in libgit2, so the\nidea of me contributing to libgit2 and leave libgit.a alone is more\nlike a \"we don't want no reorganization\". Then wait until libgit2 is\nready before considering using it in Git's core, but that's never\ngoing to happen if we don't first start to bring the two code-bases\ncloser together.\n\nIOW; sweep the issue under the carpet.\n\n-- \nFelipe Contreras\n"},{"id":"219828","messageId":"CACsJy8AtH6PQ06_-UgumV0dRdq28qKn-Oj7EAy3g+eOTGhOyYw@mail.gmail.com","threadId":"34057","inReplyTo":"CALkWK0mw8=CMuyw5-E0fzh+c6Om_NCgHohqa_p=J_kw3UfJCJQ@mail.gmail.com","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2013-06-08T14:10:55Z","receivedAt":"2013-06-08T14:10:55Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Sat, Jun 8, 2013 at 8:34 PM, Ramkumar Ramachandra wrote:\n> I'm not saying that we can convert libgit.a into something that's\n> usable as a long-running process by production servers tomorrow. All\n> I'm saying is that it might be possible to get ruby (and possibly\n> other languages) to call into git-core, to make scripting more sane\n> than shell-spawning everything like brutes. I think this is what fc\n> is aiming at, atleast in the foreseeable future.\n\nIt's technically possible. You can already call into libgit.a as fc\ndemonstrated with his ruby binding. Assuming that you are willing to\ndig in and fix all the problems (in a non-intrusive way) when a call\ninto libgit.a does not work, there's still API issue. Do we want to\nfreeze libgit.a API so that scripts will not be audited and changed\nunncessarily? Freezing the API at cmd_* level loses a lot of\nflexibility. Freezing at lower level may prevent us from making some\nchanges. I still think that binding new languages to a clean library\nlike libgit2 is better than to libgit.a. Just thinking of what might\nwork and what might not is already a headache.\n-- \nDuy\n"},{"id":"219831","messageId":"CAMP44s2uV6CwdyadnJXSd+3mhOdApDxqdtjNyOPj3CbdsEyG0Q@mail.gmail.com","threadId":"34057","inReplyTo":"CACsJy8AtH6PQ06_-UgumV0dRdq28qKn-Oj7EAy3g+eOTGhOyYw@mail.gmail.com","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-08T14:20:54Z","receivedAt":"2013-06-08T14:20:54Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sat, Jun 8, 2013 at 9:10 AM, Duy Nguyen wrote:\n\n> Do we want to\n> freeze libgit.a API so that scripts will not be audited and changed\n> unncessarily?\n\nNo. Until we ship libgit.so the API remains internal, and free to change.\n\n> I still think that binding new languages to a clean library\n> like libgit2 is better than to libgit.a. Just thinking of what might\n> work and what might not is already a headache.\n\nLet the code speak. Show me a script in any language that does\nsomething useful using libgit2, doing the equivalent to at least a\ncouple of 'git foo' commands.\n\n-- \nFelipe Contreras\n"},{"id":"219837","messageId":"20130608164902.GA3109@elie.Belkin","threadId":"34057","inReplyTo":"CACsJy8A-qc0tHcsp5=syxv_7FjixahU7fGcZuUV=cGn_-qyWwg@mail.gmail.com","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-06-08T16:49:02Z","receivedAt":"2013-06-08T16:49:02Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Duy Nguyen wrote:\n\n> libgit.a is just a way of grouping a bunch of objects together, not a\n> real library and not meant to be. If you aim something more organized,\n> please show at least a roadmap what to move where.\n\nExactly. There are some rough plans I would like to help with in the\ndirection of a more organized source tree (so \"ls\" output can be less\nintimidating --- see Nico Pitre's mail on this a while ago for more\nhints), but randomly moving files one at a time to builtin/ destroys\nconsistency and just makes things *worse*. So if you'd like to work\non this, you'll need to start with a description of the endpoint, to\nhelp people work with you to ensure it is something consistent and\nusable.\n\nActually, Felipe, I doubt that would work well. This project requires\nunderstanding how a variety of people use the git source code, which\nrequires listening carefully to them and not alienating them so you\ncan find out what they need. Someone good at moderating a discussion\ncould do that on-list, but based on my experience of how threads with\nyou go, a better strategy might be to cultivate a wiki page somewhere\nwith a plan and give it some time (a month, maybe) to collect input.\n\nNAK to changing the meaning of builtin/ to \"built-in commands, plus\nsequencer\", which seriously hurts consistency.\n\nSincerely,\nJonathan\n"},{"id":"219840","messageId":"CAMP44s06DaV2G0rbhzJRMujEJnqeGYYv2G-a90pLL6AOS0gp+w@mail.gmail.com","threadId":"34057","inReplyTo":"20130608164902.GA3109@elie.Belkin","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-08T17:06:52Z","receivedAt":"2013-06-08T17:06:52Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sat, Jun 8, 2013 at 11:49 AM, Jonathan Nieder wrote:\n> Duy Nguyen wrote:\n>\n>> libgit.a is just a way of grouping a bunch of objects together, not a\n>> real library and not meant to be. If you aim something more organized,\n>> please show at least a roadmap what to move where.\n>\n> Exactly. There are some rough plans I would like to help with in the\n> direction of a more organized source tree (so \"ls\" output can be less\n> intimidating --- see Nico Pitre's mail on this a while ago for more\n> hints), but randomly moving files one at a time to builtin/ destroys\n> consistency and just makes things *worse*. So if you'd like to work\n> on this, you'll need to start with a description of the endpoint, to\n> help people work with you to ensure it is something consistent and\n> usable.\n\nSo lets stash everything together.\n\n--- a/Makefile\n+++ b/Makefile\n@@ -990,6 +990,8 @@ BUILTIN_OBJS += builtin/verify-pack.o\n BUILTIN_OBJS += builtin/verify-tag.o\n BUILTIN_OBJS += builtin/write-tree.o\n\n+LIB_OBJS += $(BUILTIN_OBJS)\n+\n GITLIBS = $(LIB_FILE) $(XDIFF_LIB)\n EXTLIBS =\n\n@@ -1712,9 +1714,9 @@ git.sp git.s git.o: EXTRA_CPPFLAGS = \\\n '-DGIT_MAN_PATH=\"$(mandir_relative_SQ)\"' \\\n '-DGIT_INFO_PATH=\"$(infodir_relative_SQ)\"'\n\n-git$X: git.o GIT-LDFLAGS $(BUILTIN_OBJS) $(GITLIBS)\n+git$X: git.o GIT-LDFLAGS $(GITLIBS)\n $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ git.o \\\n- $(BUILTIN_OBJS) $(ALL_LDFLAGS) $(LIBS)\n+ $(ALL_LDFLAGS) $(LIBS)\n\n help.sp help.s help.o: common-cmds.h\n\n@@ -1892,7 +1894,7 @@ VCSSVN_OBJS += vcs-svn/svndiff.o\n VCSSVN_OBJS += vcs-svn/svndump.o\n\n TEST_OBJS := $(patsubst test-%$X,test-%.o,$(TEST_PROGRAMS))\n-OBJECTS := $(LIB_OBJS) $(BUILTIN_OBJS) $(PROGRAM_OBJS) $(TEST_OBJS) \\\n+OBJECTS := $(LIB_OBJS) $(PROGRAM_OBJS) $(TEST_OBJS) \\\n $(XDIFF_OBJS) \\\n $(VCSSVN_OBJS) \\\n git.o\n\nAnd stop any delusions that libgit.a has any meaning at all, and along\nthe way get rid of any hopes of ever having an official public library\nsimilar to libgit2.\n\n> Actually, Felipe, I doubt that would work well. This project requires\n> understanding how a variety of people use the git source code, which\n> requires listening carefully to them and not alienating them so you\n> can find out what they need.\n\nMy patch covers every need. Nobody has come forward with a reason not\nto organize the object files. Everything works after my patch the same\nway it has worked before.\n\n> Someone good at moderating a discussion\n> could do that on-list, but based on my experience of how threads with\n> you go, a better strategy might be to cultivate a wiki page somewhere\n> with a plan and give it some time (a month, maybe) to collect input.\n\nThis has nothing to do with better strategy, it has everything to do\nwith gut feelings and tradition. Not reasons.\n\n> NAK to changing the meaning of builtin/ to \"built-in commands, plus\n> sequencer\", which seriously hurts consistency.\n\nThen apply the patch above and stop wasting our time with a \"library\".\nGit is nothing but a bunch of disorganized object files, all squashed\ntogether, there's no library, nor will ever be; libgit.a is a\nmisnomer.\n\n-- \nFelipe Contreras\n"},{"id":"219846","messageId":"20130608173447.GA4381@elie.Belkin","threadId":"34057","inReplyTo":"CAMP44s06DaV2G0rbhzJRMujEJnqeGYYv2G-a90pLL6AOS0gp+w@mail.gmail.com","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-06-08T17:34:47Z","receivedAt":"2013-06-08T17:34:47Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Felipe Contreras wrote:\n\n> This has nothing to do with better strategy, it has everything to do\n> with gut feelings and tradition. Not reasons.\n\nI try to help you, and you insult me. I don't think this is worth it.\n\nIf I were managing this list, I would ban mails from you, since this\ndiscussion style does more harm than good. If I were maintaining git,\nI'd still accept your contributions, waiting until times when I had\nmore patience to read them and sending them to the list when\nappropriate to get more feedback. Of course I am neither managing the\nlist nor maintaining git, but I thought I should put that out there...\n\nAnnoyed,\nJonathan\n"},{"id":"219848","messageId":"CAMP44s1pSTZrv5hp85+N=Jx3ZevWSYo3BArT7oZKrftC-gnMeA@mail.gmail.com","threadId":"34057","inReplyTo":"20130608173447.GA4381@elie.Belkin","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-08T17:44:44Z","receivedAt":"2013-06-08T17:44:44Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sat, Jun 8, 2013 at 12:34 PM, Jonathan Nieder wrote:\n> Felipe Contreras wrote:\n>\n>> This has nothing to do with better strategy, it has everything to do\n>> with gut feelings and tradition. Not reasons.\n>\n> I try to help you, and you insult me. I don't think this is worth it.\n\nI didn't direct that comment to you; you took the pellet and threw it\nat yourself.\n\nMoreover, following gut feelings and traditions without reason is not\nan insult, that's what human beings do.\n\n-- \nFelipe Contreras\n"},{"id":"219858","messageId":"CAMP44s0n0qEk+1HhpAm-fMn+BWFwOeZCp7pgq9==09COVoNNEw@mail.gmail.com","threadId":"34057","inReplyTo":"20130608173447.GA4381@elie.Belkin","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-08T19:15:47Z","receivedAt":"2013-06-08T19:15:47Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sat, Jun 8, 2013 at 12:34 PM, Jonathan Nieder wrote:\n\n> If I were managing this list, I would ban mails from you, since this\n> discussion style does more harm than good.\n\nThere is a nice motto around: \"Talk is cheap. Show me the code.\"\n\nJust the past three months I've probably done more work than anybody\nelse[1], and you would ban me because you don't like my words? At the\nend of the day the project has benefited from my patches, and a wise\nmaintainer would do what is best for the project. If you don't like my\nwords, ignore them.\n\nTaking things personal is more often than not the wrong thing to do.\nSpecially when they were not even directed to you.\n\n[1] https://www.ohloh.net/p/git/contributors?query=&sort=commits_12_mo\n\n-- \nFelipe Contreras\n"},{"id":"219866","messageId":"20130609014049.GA10375@google.com","threadId":"34057","inReplyTo":"CAMP44s0n0qEk+1HhpAm-fMn+BWFwOeZCp7pgq9==09COVoNNEw@mail.gmail.com","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-06-09T01:40:49Z","receivedAt":"2013-06-09T01:40:49Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Felipe Contreras wrote:\n\n> Just the past three months I've probably done more work than anybody\n> else[1], and you would ban me because you don't like my words?\n\nDefinitely, yes. Even if you look at the impact on code alone and\ndon't care about the people, destroying a collegial work environment\nis harmful enough to the code to outweigh the (admittedly often\nuseful) patches.\n\nBut I am not the mailing list owner, so what I would do is not too\nimportant.\n\nJonathan\n"},{"id":"219868","messageId":"CAMP44s3CGHVLnkUxo=PR_b+_dTuaz5rwems_pd9GE1_vcEaYRA@mail.gmail.com","threadId":"34057","inReplyTo":"20130609014049.GA10375@google.com","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-09T02:17:56Z","receivedAt":"2013-06-09T02:17:56Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sat, Jun 8, 2013 at 8:40 PM, Jonathan Nieder wrote:\n> Felipe Contreras wrote:\n>\n>> Just the past three months I've probably done more work than anybody\n>> else[1], and you would ban me because you don't like my words?\n>\n> Definitely, yes. Even if you look at the impact on code alone and\n> don't care about the people, destroying a collegial work environment\n> is harmful enough to the code to outweigh the (admittedly often\n> useful) patches.\n\nA collegial work environment is overrated, and proof of that the Linux\nkernel, where honest and straight talk is the bread and butter of the\nmailing list. And the Linux kernel is the most successful software\nproject in history by far. It's code that speaks.\n\nAnd I have not destroyed anything, except maybe your sense of fairness\nand balance when reviewing my patches, but that is not my fault.\n\n-- \nFelipe Contreras\n"},{"id":"219876","messageId":"20130609032143.GA18678@google.com","threadId":"34057","inReplyTo":"CAMP44s3CGHVLnkUxo=PR_b+_dTuaz5rwems_pd9GE1_vcEaYRA@mail.gmail.com","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-06-09T03:21:43Z","receivedAt":"2013-06-09T03:21:43Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Felipe Contreras wrote:\n\n> A collegial work environment is overrated, and proof of that the Linux\n> kernel, where honest and straight talk is the bread and butter of the\n> mailing list.\n\nAn aside, since it doesn't bear too much on the topic at hand:\n\nFor what it's worth, in my experience the people working on the kernel\nare quite sensible and friendly on-list. Probably you are referring\nto some high-profile cases of flames, which perhaps I have just been\nlucky to avoid. I do not think the way the list works normally is a\ncounterexample to common decency being useful.\n\nSo no, I don't find \"But they are mean, and look how well they are\ndoing!\" to be a compelling argument here.\n\nJonathan\n"},{"id":"219877","messageId":"CAMP44s0n0=boPM0ZYtAHyvDfu45eyU9--_bR5JNobbT9AKM1=Q@mail.gmail.com","threadId":"34057","inReplyTo":"20130609032143.GA18678@google.com","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-09T03:34:14Z","receivedAt":"2013-06-09T03:34:14Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sat, Jun 8, 2013 at 10:21 PM, Jonathan Nieder wrote:\n> Felipe Contreras wrote:\n>\n>> A collegial work environment is overrated, and proof of that the Linux\n>> kernel, where honest and straight talk is the bread and butter of the\n>> mailing list.\n>\n> An aside, since it doesn't bear too much on the topic at hand:\n>\n> For what it's worth, in my experience the people working on the kernel\n> are quite sensible and friendly on-list.\n\nThey are professional. When they need to be straight-forward, they\nare, even if that hurts the feelings of the colleagues.\n\n> Probably you are referring to some high-profile cases of flames,\n\nNo, I'm not. Heated discussions happen all the time, specially when\nthe issue at hand is important.\n\n> I do not think the way the list works normally is a\n> counterexample to common decency being useful.\n\nOf course you wouldn't, but you are purposely ignoring the facts.\n\nThe Linux kernel mailing lists concentrates on *the code*; he who\nwrites the code has a voice, he who only has words doesn't. Personal\nbeefs are not relevant. When there's something horribly wrong with the\ncode, so are the responses.\n\n> So no, I don't find \"But they are mean, and look how well they are\n> doing!\" to be a compelling argument here.\n\nBecause you dismiss the premise a priori.\n\n-- \nFelipe Contreras\n"},{"id":"219878","messageId":"20130609043444.GA561@sigill.intra.peff.net","threadId":"34057","inReplyTo":"CAMP44s2uV6CwdyadnJXSd+3mhOdApDxqdtjNyOPj3CbdsEyG0Q@mail.gmail.com","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-06-09T04:34:44Z","receivedAt":"2013-06-09T04:34:44Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Jun 08, 2013 at 09:20:54AM -0500, Felipe Contreras wrote:\n\n> Let the code speak. Show me a script in any language that does\n> something useful using libgit2, doing the equivalent to at least a\n> couple of 'git foo' commands.\n\nSorry that I cannot show you the source code, but you may interested to\nknow that libgit2 powers:\n\n 1. Microsoft's \"Visual Studio Tools for Git\" plugin\n\n 2. GitHub's native Mac and Windows clients (using Objective C and C#\n bindings); some operations still shell out to git where the\n functionality is not yet implemented in libgit2.\n\n 3. Parts of the web view of GitHub.com via Ruby bindings\n\nIt is definitely not feature-complete when compared with git.git. But I\ndo think it is in a state that is usable for quite a few tasks.\n\n-Peff\n"},{"id":"219885","messageId":"20130609052624.GB561@sigill.intra.peff.net","threadId":"34057","inReplyTo":"CAMP44s3CGHVLnkUxo=PR_b+_dTuaz5rwems_pd9GE1_vcEaYRA@mail.gmail.com","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-06-09T05:26:24Z","receivedAt":"2013-06-09T05:26:24Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Jun 08, 2013 at 09:17:56PM -0500, Felipe Contreras wrote:\n\n> > Definitely, yes. Even if you look at the impact on code alone and\n> > don't care about the people, destroying a collegial work environment\n> > is harmful enough to the code to outweigh the (admittedly often\n> > useful) patches.\n> \n> A collegial work environment is overrated, and proof of that the Linux\n> kernel, where honest and straight talk is the bread and butter of the\n> mailing list. And the Linux kernel is the most successful software\n> project in history by far. It's code that speaks.\n\nSorry, but I don't agree, and I want to publicly state my opinion so\nthat Jonathan (and other bystanders on the list) knows that he is not\nalone in his opinions.\n\nI have consistently found your demeanor on the list to be very\nunfriendly and difficult to work with. It is one thing to have honest\nand straight talk, and another thing to be obstinate, unmindful of\nfeedback (both with respect to technical details, as well as to\ncommunication styles), and disrespectful of other people.\n\nYou have accused others of assuming you make comments in bad faith.\nPerhaps it is true that you are very pleasant and easy to work with in\nperson, but in my opinion that is not the case, at least by email. I may\nbe wrong, of course, and I certainly do not claim to be perfect myself.\nBut I find it telling that many of the list participants seem to have\nhad conflicts with you, and not with anyone else. So perhaps you may\nwant to reconsider your style of communication.\n\nUnlike Jonathan, I would not ban you from the list. I do not believe in\ncensoring anybody who is not a direct and constant nuisance (like a\nspammer). But personally I have a limited capacity for discussion with\nyou, as it seems to have a knack for going back and forth, consuming a\nlot of time, and ending nowhere productive.\n\nIt is certainly your choice about how you will communicate. But likewise\nit is the choice of readers and reviewers to choose how much of their\ntime to give to your writings.\n\n-Peff\n"},{"id":"219948","messageId":"CALkWK0kkGO8zoLSpZkaYgVr5eBX6AovYFxQZkgJKugSw0CmdXQ@mail.gmail.com","threadId":"34057","inReplyTo":"20130609043444.GA561@sigill.intra.peff.net","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-06-09T09:58:48Z","receivedAt":"2013-06-09T09:58:48Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Jeff King wrote:\n> Sorry that I cannot show you the source code, but you may interested to\n> know that libgit2 powers:\n\nYes, I'm well aware of these: libgit2 is LGPL, because of which these\nthree proprietary applications have been made possible. Isn't it\ncompletely orthogonal to the discussion about how best to lib'ify\ngit.git though? From what I understand, fc is not interested in\nbuilding another application leveraging libgit.a or libgit2; he's\ninterested in improving libgit.a and getting more users.\n\n> It is definitely not feature-complete when compared with git.git. But I\n> do think it is in a state that is usable for quite a few tasks.\n\nWhat is this task you are discussing? fc is talking about improving\nlibgit.a and getting an official git library with many users. Answer\nthe question: what should we do now?\n\n1. Start moving irrelevant code out of libgit.a, and use inspiration\nfrom libgit2 to improve it (this might or might not involve taking\ncode from libgit2). Get _users_ of libgit.a via ruby bindings (or\nsomething) asap, so it puts pressure on fixing it.\n\n2. Wait indefinitely until libgit2.git magically becomes ready to be\nusable by git.git as-is. Then throw libgit.a out the window, and\nrewrite git.git to call into libgit2.a instead [*1*].\n\nWhat you seem to be saying is \"3. Work on libgit2 (and abandon\ngit.git?)\" [*2*], or worse: 2. fc is in favor of 1. Unless you are\nin favor of _not_ improving libgit.a, don't stand in his way: you\nmight personally think that it is a difficult (or impossible) task,\nbut that's no reason to stop fc from trying. I personally think his\ngoal is admirable, and I'm nobody to say that it cannot be done:\ntherefore, I will review his patches and help him in whatever little\nway I can.\n\n[Footnote]\n\n*1* You have dismissed 1 as being unworkable, but do you realize how\nunrealistic this sounds?\n\n*2* git.git has _far_ more users and a _lot_ more contributors. Don't\nbe unwelcoming to contributors by asking them to go away and work on\nsomething else. The three proprietary applications you have given as\ncounter-examples (?) is not helping anyone.\n"},{"id":"219954","messageId":"CAMP44s04nU+GBQchK0D0ExKTCp_B0oitSxzGUo++3Q_XbGv9sw@mail.gmail.com","threadId":"34057","inReplyTo":"20130609043444.GA561@sigill.intra.peff.net","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-09T12:09:27Z","receivedAt":"2013-06-09T12:09:27Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sat, Jun 8, 2013 at 11:34 PM, Jeff King wrote:\n> On Sat, Jun 08, 2013 at 09:20:54AM -0500, Felipe Contreras wrote:\n>\n>> Let the code speak. Show me a script in any language that does\n>> something useful using libgit2, doing the equivalent to at least a\n>> couple of 'git foo' commands.\n>\n> Sorry that I cannot show you the source code, but you may interested to\n> know that libgit2 powers:\n>\n> 1. Microsoft's \"Visual Studio Tools for Git\" plugin\n>\n> 2. GitHub's native Mac and Windows clients (using Objective C and C#\n> bindings); some operations still shell out to git where the\n> functionality is not yet implemented in libgit2.\n>\n> 3. Parts of the web view of GitHub.com via Ruby bindings\n>\n> It is definitely not feature-complete when compared with git.git. But I\n> do think it is in a state that is usable for quite a few tasks.\n\nThat's not what a I asked. We have perl, and shell, and python, and\nruby scripts in git.git, they all use 'git foo' commands to get things\ndone. But to do that, forks are needed, many of them, constantly. The\nproposal was to use libgit2 to avoid such forks. Well, show me a\n*script* that does that and is worthy of inclusion to git.git, even if\nit's to contrib.\n\nI didn't ask for irrelevant 3rd parties, I asked for something worthy\nof inclusion into git.git, a script that does something useful using\nlibgit2.\n\nDuy Nguyen seems to think it's easy to do that. I'm waiting.\n\n-- \nFelipe Contreras\n"},{"id":"219955","messageId":"CAMP44s3NhNUuCvW37UaMo9KbHHxZqBE8S15h845vtRi89Bu6WA@mail.gmail.com","threadId":"34057","inReplyTo":"20130609052624.GB561@sigill.intra.peff.net","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-09T12:15:45Z","receivedAt":"2013-06-09T12:15:45Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sun, Jun 9, 2013 at 12:26 AM, Jeff King wrote:\n> On Sat, Jun 08, 2013 at 09:17:56PM -0500, Felipe Contreras wrote:\n>\n>> > Definitely, yes. Even if you look at the impact on code alone and\n>> > don't care about the people, destroying a collegial work environment\n>> > is harmful enough to the code to outweigh the (admittedly often\n>> > useful) patches.\n>>\n>> A collegial work environment is overrated, and proof of that the Linux\n>> kernel, where honest and straight talk is the bread and butter of the\n>> mailing list. And the Linux kernel is the most successful software\n>> project in history by far. It's code that speaks.\n>\n> Sorry, but I don't agree, and I want to publicly state my opinion so\n> that Jonathan (and other bystanders on the list) knows that he is not\n> alone in his opinions.\n\nYou don't agree that 1) a collegial work environment is overrated, 2)\nthat the Linux kernel doesn't put an emphasis on being collegial, or\n3) that it's the most successful software project in history?\n\n> I have consistently found your demeanor on the list to be very\n> unfriendly and difficult to work with. It is one thing to have honest\n> and straight talk, and another thing to be obstinate, unmindful of\n> feedback (both with respect to technical details, as well as to\n> communication styles), and disrespectful of other people.\n\nGo back to my 261 commits, show me one that is \"unmindful of technical details\".\n\n> It is certainly your choice about how you will communicate. But likewise\n> it is the choice of readers and reviewers to choose how much of their\n> time to give to your writings.\n\nExactly. Nobody is forcing you to read my emails. But somehow you\nalready know that ignoring them is not in the best interest of the\nproject. And by that I mean it's in the best interest of our users,\nwithout which our project is nothing.\n\n-- \nFelipe Contreras\n"},{"id":"219959","messageId":"CALkWK0mu2_9M5aTczcEkv37eLaAg5_mGDZ_W9nqQFoesB4wc3g@mail.gmail.com","threadId":"34057","inReplyTo":"20130609052624.GB561@sigill.intra.peff.net","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-06-09T12:48:51Z","receivedAt":"2013-06-09T12:48:51Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Jeff King wrote:\n>> > Definitely, yes. Even if you look at the impact on code alone and\n>> > don't care about the people, destroying a collegial work environment\n>> > is harmful enough to the code to outweigh the (admittedly often\n>> > useful) patches.\n>>\n>> A collegial work environment is overrated, and proof of that the Linux\n>> kernel, where honest and straight talk is the bread and butter of the\n>> mailing list. And the Linux kernel is the most successful software\n>> project in history by far. It's code that speaks.\n>\n> I have consistently found your demeanor on the list to be very\n> unfriendly and difficult to work with. It is one thing to have honest\n> and straight talk, and another thing to be obstinate, unmindful of\n> feedback (both with respect to technical details, as well as to\n> communication styles), and disrespectful of other people.\n\nWhile I agree that being rude and obstinate is definitely undesirable,\nand that a healthy on-list environment is important, I have something\nto add:\n\nBeing super-tactful comes at a cost. Regulars on the mailing list\nhave to spend 3~4x the amount of time to compose an email (reading and\nre-reading their drafts to see how to express them in a more friendly\nway); this leads to a lot of inefficiency and creates a suffocating\nenvironment in which people don't have freedom of expression. I would\nmuch rather prefer straight talk where nobody reads into what is\nwritten and takes offense. In this case, jrn took offense and talked\nabout how he would ban fc from the list if he were managing it: while\nI'm not defending fc's tone, I'm not defending jrn's comment either.\njrn has been around since mid-2008, and fc has been around since\nearly-2009. It's mid-2013, and they still haven't learnt to work with\neach other.\n\nDisagreement is healthy, and is the foundation of progress. When it\ncomes to sensitive issues, stern disagreement is often mis-interpreted\nas disrespect (or worse). If we keep beating up disagreements on the\nbasis of tone and demeanor, git.git would go nowhere. Sure, it would\nbe more ideal if fc's tone were friendlier [*1*], but it isn't: let's\ndeal with the issue instead of constantly whining about it.\n\n[Footnotes]\n\n*1* Oh, and mine too. I've been told several times off-list that my\ntone is unfriendly. I'm working on fixing the issue, but I don't\nenjoy the constant suffocation: I should be able to say what I want\nwithout too much effort.\n"},{"id":"219960","messageId":"CAMP44s32Aa0zCPB0X_XoR3i6wdRLrV2gccuMGb9zpdObS10AaA@mail.gmail.com","threadId":"34057","inReplyTo":"CALkWK0mu2_9M5aTczcEkv37eLaAg5_mGDZ_W9nqQFoesB4wc3g@mail.gmail.com","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-09T13:08:55Z","receivedAt":"2013-06-09T13:08:55Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sun, Jun 9, 2013 at 7:48 AM, Ramkumar Ramachandra wrote:\n> Jeff King wrote:\n>>> > Definitely, yes. Even if you look at the impact on code alone and\n>>> > don't care about the people, destroying a collegial work environment\n>>> > is harmful enough to the code to outweigh the (admittedly often\n>>> > useful) patches.\n>>>\n>>> A collegial work environment is overrated, and proof of that the Linux\n>>> kernel, where honest and straight talk is the bread and butter of the\n>>> mailing list. And the Linux kernel is the most successful software\n>>> project in history by far. It's code that speaks.\n>>\n>> I have consistently found your demeanor on the list to be very\n>> unfriendly and difficult to work with. It is one thing to have honest\n>> and straight talk, and another thing to be obstinate, unmindful of\n>> feedback (both with respect to technical details, as well as to\n>> communication styles), and disrespectful of other people.\n>\n> While I agree that being rude and obstinate is definitely undesirable,\n> and that a healthy on-list environment is important, I have something\n> to add:\n>\n> Being super-tactful comes at a cost. Regulars on the mailing list\n> have to spend 3~4x the amount of time to compose an email (reading and\n> re-reading their drafts to see how to express them in a more friendly\n> way); this leads to a lot of inefficiency and creates a suffocating\n> environment in which people don't have freedom of expression.\n\nThat's exactly the reason why they don't put emphasis on that in the\nLinux kernel mailing list.\n\nBesides, when something is really fucked up, the most effective way to\nconvey the fact that you think it's totally fucked up, is to say\nprecisely that. If somebody's feelings get hurt along the way, and\nthey decide to leave the project, they were not cut for Linux\ndevelopment anyway.\n\n> I would\n> much rather prefer straight talk where nobody reads into what is\n> written and takes offense. In this case, jrn took offense and talked\n> about how he would ban fc from the list if he were managing it: while\n> I'm not defending fc's tone, I'm not defending jrn's comment either.\n> jrn has been around since mid-2008, and fc has been around since\n> early-2009. It's mid-2013, and they still haven't learnt to work with\n> each other.\n\nWe don't _need_ to work with each other. If he helps the project, and\nI help the project, what's wrong with that?\n\n> Disagreement is healthy, and is the foundation of progress. When it\n> comes to sensitive issues, stern disagreement is often mis-interpreted\n> as disrespect (or worse). If we keep beating up disagreements on the\n> basis of tone and demeanor, git.git would go nowhere. Sure, it would\n> be more ideal if fc's tone were friendlier [*1*], but it isn't: let's\n> deal with the issue instead of constantly whining about it.\n\nCompletely agree. Disagreement is not disrespect. Besides, ideas don't\nhave feelings, ideas don't need respect; ideas should be criticized.\nAny rational person, specially scientists, understand that it's not\nhealthy to have an emotional attachment to ideas; they might be wrong,\nand they need scrutiny. If one doesn't tolerate criticism of one's\nideas (however straightforward or delicate it might be), one is never\ngoing to find the truth.\n\n-- \nFelipe Contreras\n"},{"id":"220047","messageId":"20130609174049.GA1039@sigill.intra.peff.net","threadId":"34057","inReplyTo":"CAMP44s3NhNUuCvW37UaMo9KbHHxZqBE8S15h845vtRi89Bu6WA@mail.gmail.com","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-06-09T17:40:49Z","receivedAt":"2013-06-09T17:40:49Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Jun 09, 2013 at 07:15:45AM -0500, Felipe Contreras wrote:\n\n> > Sorry, but I don't agree, and I want to publicly state my opinion so\n> > that Jonathan (and other bystanders on the list) knows that he is not\n> > alone in his opinions.\n> \n> You don't agree that 1) a collegial work environment is overrated, 2)\n> that the Linux kernel doesn't put an emphasis on being collegial, or\n> 3) that it's the most successful software project in history?\n\nPoint 1.\n\n> Go back to my 261 commits, show me one that is \"unmindful of technical details\".\n\nI do not have an interest in cataloguing past conflicts I and others\nhave had with you; the list archive has done so. I have already made my\ncomments there, and I see no point in starting a new argument.\n\n> Exactly. Nobody is forcing you to read my emails. But somehow you\n> already know that ignoring them is not in the best interest of the\n> project. And by that I mean it's in the best interest of our users,\n> without which our project is nothing.\n\nI never claimed that you contribute nothing. But every minute spent\narguing with you is a minute that could be spent on something more\nproductive. It is certainly possible that community members reading your\nemails could be a net negative for the users, if it leaves them no time\nfor other code.\n\n-Peff\n"},{"id":"220052","messageId":"87wqq39nmr.fsf@hexa.v.cablecom.net","threadId":"34057","inReplyTo":"CAMP44s3NhNUuCvW37UaMo9KbHHxZqBE8S15h845vtRi89Bu6WA@mail.gmail.com","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Thomas Rast","fromEmail":"trast@inf.ethz.ch","sentAt":"2013-06-09T17:53:32Z","receivedAt":"2013-06-09T17:53:32Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Felipe Contreras writes:\n\n> On Sun, Jun 9, 2013 at 12:26 AM, Jeff King wrote:\n>> On Sat, Jun 08, 2013 at 09:17:56PM -0500, Felipe Contreras wrote:\n>>\n>>> > Definitely, yes. Even if you look at the impact on code alone and\n>>> > don't care about the people, destroying a collegial work environment\n>>> > is harmful enough to the code to outweigh the (admittedly often\n>>> > useful) patches.\n>>>\n>>> A collegial work environment is overrated, and proof of that the Linux\n>>> kernel, where honest and straight talk is the bread and butter of the\n>>> mailing list. And the Linux kernel is the most successful software\n>>> project in history by far. It's code that speaks.\n>>\n>> Sorry, but I don't agree, and I want to publicly state my opinion so\n>> that Jonathan (and other bystanders on the list) knows that he is not\n>> alone in his opinions.\n\nFWIW, I'll add my voice here.\n\nIn addition to what has been said by Jeff and Jonathan already (and with\nwhich I agree), I would like to point out one observation about your\nstyle of discussion that I find particularly unproductive.\n\nYou have a tendency, when facing arguments by someone who does not agree\nwith you, of picking out one (usually minor) point of their statement\nand attacking just *that* on grounds that are usually much harder to\nargue, without regard for the bigger issue. In effect you are\nattempting to shift a significant burden of proof back to the other\nparty.\n\nCase in point:\n\n>> I have consistently found your demeanor on the list to be very\n>> unfriendly and difficult to work with. It is one thing to have honest\n>> and straight talk, and another thing to be obstinate, unmindful of\n>> feedback (both with respect to technical details, as well as to\n>> communication styles), and disrespectful of other people.\n>\n> Go back to my 261 commits, show me one that is \"unmindful of technical details\".\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"220055","messageId":"20130609175554.GA810@sigill.intra.peff.net","threadId":"34057","inReplyTo":"CALkWK0kkGO8zoLSpZkaYgVr5eBX6AovYFxQZkgJKugSw0CmdXQ@mail.gmail.com","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-06-09T17:55:54Z","receivedAt":"2013-06-09T17:55:54Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Jun 09, 2013 at 03:28:48PM +0530, Ramkumar Ramachandra wrote:\n\n> Jeff King wrote:\n> > Sorry that I cannot show you the source code, but you may interested to\n> > know that libgit2 powers:\n> \n> Yes, I'm well aware of these: libgit2 is LGPL, because of which these\n> three proprietary applications have been made possible. Isn't it\n> completely orthogonal to the discussion about how best to lib'ify\n> git.git though? From what I understand, fc is not interested in\n> building another application leveraging libgit.a or libgit2; he's\n> interested in improving libgit.a and getting more users.\n\nPerhaps I misunderstood the discussion, but it looked to me that there\nwas an assertion that libgit2 was not ready for useful work. I do not\nthink that is true, and I tried to counter it with facts.\n\nIf that was not useful to the discussion, I apologize for leading it\nastray.\n\n> > It is definitely not feature-complete when compared with git.git. But I\n> > do think it is in a state that is usable for quite a few tasks.\n> \n> What is this task you are discussing?\n\nYou snipped the part of Felipe's message that I quoted:\n\n Let the code speak. Show me a script in any language that does\n something useful using libgit2, doing the equivalent to at least a\n couple of 'git foo' commands.\n\nI meant tasks that were \"equivalent to at least a couple of 'git foo'\ncommands\" as performed by the programs I mentioned. Like cloning,\ncheckout, commit, revision traversal, diffs, etc.\n\n> fc is talking about improving libgit.a and getting an official git\n> library with many users. Answer the question: what should we do now?\n\nI do not think I was addressing that point at all in my email. But since\nyou ask...\n\n> 1. Start moving irrelevant code out of libgit.a, and use inspiration\n> from libgit2 to improve it (this might or might not involve taking\n> code from libgit2). Get _users_ of libgit.a via ruby bindings (or\n> something) asap, so it puts pressure on fixing it.\n\nI already mentioned elsewhere that I think it would be fine to massage\nlibgit.a in that direction. I even joined the conversation pointing out\nsome cases where Felipe's ruby module would break. But I do not think\nthat moving code in and out of libgit.a is an important first step at\nall. That is simply code that no library users would want to call, and\nis easy to deal with: move it out. The hard part is code that users\n_would_ want to call, and is totally broken. Patches dealing with that\nare the hard obstacle that people working in this direction would need\nto overcome. But I do not see any such patches under discussion.\n\n> 2. Wait indefinitely until libgit2.git magically becomes ready to be\n> usable by git.git as-is. Then throw libgit.a out the window, and\n> rewrite git.git to call into libgit2.a instead [*1*].\n\nI think the \"magically\" here could be \"work on libgit2 to move it\ntowards being useful for git.git\". I also do not think there needs to be\na \"throw out libgit.a\" flag day. We can make a decision later to start\nadopting bits of libgit2 inside git.git (the big downside being an\nincreased dependency).\n\nMaybe the code style will diverge too much and it will never be\nappropriate to do so. We'll have to see.\n\n> What you seem to be saying is \"3. Work on libgit2 (and abandon\n> git.git?)\" [*2*], or worse: 2.\n\nI didn't say that at all. If the two projects co-exist forever, working\ncompatibly on the same repositories, and git.git is the command line and\nlibgit2 is the library, I do not see that as the end of the world. The\ndownside there is is code duplication, which is why it may eventually\nmake sense for libgit.a to start adopting bits of libgit2 (it is usually\nhard to go the other way, both for licensing reasons, and for the fact\nthat the library code tends to be more reusable).\n\n> fc is in favor of 1. Unless you are\n> in favor of _not_ improving libgit.a, don't stand in his way:\n\nI'm not. I tried to give pointers on the path that I think would be\nuseful (e.g., what would break with his ruby patch).\n\n> *1* You have dismissed 1 as being unworkable, but do you realize how\n> unrealistic this sounds?\n\nI don't think I dismissed it as unworkable. I said it was a lot of work,\ntried to describe some examples, and said that I think the other route\nmay be _less_ work.\n\n> *2* git.git has _far_ more users and a _lot_ more contributors. Don't\n> be unwelcoming to contributors by asking them to go away and work on\n> something else. The three proprietary applications you have given as\n> counter-examples (?) is not helping anyone.\n\nThey were counter-examples to the point \"libgit2 is not ready for real\nwork\", which I thought was being made. If that was not the point being\nmade, then no, they are not helping anyone.\n\n-Peff\n"},{"id":"220072","messageId":"CAMP44s35w_ysvd5c8oANF8YpWvsquY50bUjSfjOxtujdpgBCPQ@mail.gmail.com","threadId":"34057","inReplyTo":"20130609174049.GA1039@sigill.intra.peff.net","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-09T18:01:30Z","receivedAt":"2013-06-09T18:01:30Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sun, Jun 9, 2013 at 12:40 PM, Jeff King wrote:\n> On Sun, Jun 09, 2013 at 07:15:45AM -0500, Felipe Contreras wrote:\n>\n>> > Sorry, but I don't agree, and I want to publicly state my opinion so\n>> > that Jonathan (and other bystanders on the list) knows that he is not\n>> > alone in his opinions.\n>>\n>> You don't agree that 1) a collegial work environment is overrated, 2)\n>> that the Linux kernel doesn't put an emphasis on being collegial, or\n>> 3) that it's the most successful software project in history?\n>\n> Point 1.\n\nGood, so we agree that a project doesn't need a collegial work\nenvironment to be extremely and amazingly successful. In fact, any\nrational person would keep an open mind to the fact that perhaps it\nactually _helps_ to not have such environment, based on the evidence.\n\n>> Go back to my 261 commits, show me one that is \"unmindful of technical details\".\n>\n> I do not have an interest in cataloguing past conflicts I and others\n> have had with you; the list archive has done so.\n\nNo. There is no such catalog. You made a claim, it's not backed by\nevidence, merely by your subjective experience. And memory is a pretty\nbad indicator of reality.\n\n\"The first principle is that you must not fool yourself—and you are\nthe easiest person to fool\" -- Richard Feynman\n\n-- \nFelipe Contreras\n"},{"id":"220073","messageId":"CAMP44s1kjqgcfLkOdOYA4xAUMGsvJXQvd01j=y9ybs_LyCEdYA@mail.gmail.com","threadId":"34057","inReplyTo":"87wqq39nmr.fsf@hexa.v.cablecom.net","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-09T18:03:07Z","receivedAt":"2013-06-09T18:03:07Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sun, Jun 9, 2013 at 12:53 PM, Thomas Rast wrote:\n\n> You have a tendency, when facing arguments by someone who does not agree\n> with you, of picking out one (usually minor) point of their statement\n> and attacking just *that* on grounds that are usually much harder to\n> argue, without regard for the bigger issue. In effect you are\n> attempting to shift a significant burden of proof back to the other\n> party.\n\nHe who makes a claim has the burden of proof.\n\nThat which can be asserted without evidence, can be dismissed without evidence.\n\n-- \nFelipe Contreras\n"},{"id":"220074","messageId":"20130609180437.GB810@sigill.intra.peff.net","threadId":"34057","inReplyTo":"CALkWK0mu2_9M5aTczcEkv37eLaAg5_mGDZ_W9nqQFoesB4wc3g@mail.gmail.com","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-06-09T18:04:37Z","receivedAt":"2013-06-09T18:04:37Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Jun 09, 2013 at 06:18:51PM +0530, Ramkumar Ramachandra wrote:\n\n> > I have consistently found your demeanor on the list to be very\n> > unfriendly and difficult to work with. It is one thing to have honest\n> > and straight talk, and another thing to be obstinate, unmindful of\n> > feedback (both with respect to technical details, as well as to\n> > communication styles), and disrespectful of other people.\n> \n> While I agree that being rude and obstinate is definitely undesirable,\n> and that a healthy on-list environment is important, I have something\n> to add:\n> \n> Being super-tactful comes at a cost.\n\nI actually think word choice and politeness is only a small part of it,\nand one that I live without. It is not just _how_ something is said,\nbut _what_ is said. And sometimes what is said does not lead in a\nproductive direction. I found Thomas's comment here:\n\n http://article.gmane.org/gmane.comp.version-control.git/227053\n\nsums up the core of many of the conflicts I've seen on the list.\n\nI am less interested in people's feelings than I am in discussions\ntrying to reach a productive position of agreement, rather than turning\nit into a point by point debate that may no longer have any use for the\nproject (sometimes individual points need to be refuted or discussed, of\ncourse, but it is easy to lose sight of the purpose of an email).\n\n-Peff\n"},{"id":"220076","messageId":"CALkWK0n0kkNZo_Xt1oT5GL-TxZP0faDExxyH3vU-+hy4uEUEtQ@mail.gmail.com","threadId":"34057","inReplyTo":"20130609175554.GA810@sigill.intra.peff.net","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-06-09T18:06:42Z","receivedAt":"2013-06-09T18:06:42Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Jeff King wrote:\n> I already mentioned elsewhere that I think it would be fine to massage\n> libgit.a in that direction. I even joined the conversation pointing out\n> some cases where Felipe's ruby module would break. But I do not think\n> that moving code in and out of libgit.a is an important first step at\n> all. That is simply code that no library users would want to call, and\n> is easy to deal with: move it out. The hard part is code that users\n> _would_ want to call, and is totally broken. Patches dealing with that\n> are the hard obstacle that people working in this direction would need\n> to overcome. But I do not see any such patches under discussion.\n\nForget the rest; this makes it clear. Thanks, and sorry for all the confusion.\n\nSo, reorganization is not the first step. Can you please post an\nexample patch illustrating what needs to be done, so we can follow?\n"},{"id":"220075","messageId":"CAMP44s2umN3prdPnb=kuvH4OrQqcKDyu8ExfkXHAR2nC=a6weA@mail.gmail.com","threadId":"34057","inReplyTo":"20130609175554.GA810@sigill.intra.peff.net","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-09T18:07:25Z","receivedAt":"2013-06-09T18:07:25Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sun, Jun 9, 2013 at 12:55 PM, Jeff King wrote:\n> On Sun, Jun 09, 2013 at 03:28:48PM +0530, Ramkumar Ramachandra wrote:\n>\n>> Jeff King wrote:\n>> > Sorry that I cannot show you the source code, but you may interested to\n>> > know that libgit2 powers:\n>>\n>> Yes, I'm well aware of these: libgit2 is LGPL, because of which these\n>> three proprietary applications have been made possible. Isn't it\n>> completely orthogonal to the discussion about how best to lib'ify\n>> git.git though? From what I understand, fc is not interested in\n>> building another application leveraging libgit.a or libgit2; he's\n>> interested in improving libgit.a and getting more users.\n>\n> Perhaps I misunderstood the discussion, but it looked to me that there\n> was an assertion that libgit2 was not ready for useful work. I do not\n> think that is true, and I tried to counter it with facts.\n\nThat was not the point. Take 'contrib/related/git-related', or any\nuseful script, and make it so it uses libgit2 instead of forking 'git\nfoo' commands.\n\nIt's not going to happen.\n\n-- \nFelipe Contreras\n"},{"id":"220077","messageId":"20130609181002.GC810@sigill.intra.peff.net","threadId":"34057","inReplyTo":"CAMP44s35w_ysvd5c8oANF8YpWvsquY50bUjSfjOxtujdpgBCPQ@mail.gmail.com","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-06-09T18:10:02Z","receivedAt":"2013-06-09T18:10:02Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Jun 09, 2013 at 01:01:30PM -0500, Felipe Contreras wrote:\n\n> >> > Sorry, but I don't agree, and I want to publicly state my opinion so\n> >> > that Jonathan (and other bystanders on the list) knows that he is not\n> >> > alone in his opinions.\n> >>\n> >> You don't agree that 1) a collegial work environment is overrated, 2)\n> >> that the Linux kernel doesn't put an emphasis on being collegial, or\n> >> 3) that it's the most successful software project in history?\n> >\n> > Point 1.\n> \n> Good, so we agree that a project doesn't need a collegial work\n> environment to be extremely and amazingly successful.\n\nNo, I said that point 1 was the point I was not agreeing with. I do not\nhave an opinion on 2, as I do not interact with the kernel community\nenough to know.\n\n> In fact, any rational person would keep an open mind to the fact that\n> perhaps it actually _helps_ to not have such environment, based on the\n> evidence.\n\nIn my experience, dealing with you has been a giant time sink. For\nexample, this thread. Without needing to get into the exact definition\nof \"such an environment\", the above statement is certainly my backed by\nempirical experience.\n\n> > I do not have an interest in cataloguing past conflicts I and others\n> > have had with you; the list archive has done so.\n> \n> No. There is no such catalog. You made a claim, it's not backed by\n> evidence, merely by your subjective experience. And memory is a pretty\n> bad indicator of reality.\n\nI think this thread is an excellent example all by itself.\n\n-Peff\n"},{"id":"220078","messageId":"CAMP44s33wC0p_K8zhovWrgMua9qzZ3064BFxJ+m00Lt39ZPPQQ@mail.gmail.com","threadId":"34057","inReplyTo":"CALkWK0n0kkNZo_Xt1oT5GL-TxZP0faDExxyH3vU-+hy4uEUEtQ@mail.gmail.com","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-09T18:11:16Z","receivedAt":"2013-06-09T18:11:16Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sun, Jun 9, 2013 at 1:06 PM, Ramkumar Ramachandra wrote:\n> Jeff King wrote:\n>> I already mentioned elsewhere that I think it would be fine to massage\n>> libgit.a in that direction. I even joined the conversation pointing out\n>> some cases where Felipe's ruby module would break. But I do not think\n>> that moving code in and out of libgit.a is an important first step at\n>> all. That is simply code that no library users would want to call, and\n>> is easy to deal with: move it out. The hard part is code that users\n>> _would_ want to call, and is totally broken. Patches dealing with that\n>> are the hard obstacle that people working in this direction would need\n>> to overcome. But I do not see any such patches under discussion.\n>\n> Forget the rest; this makes it clear. Thanks, and sorry for all the confusion.\n>\n> So, reorganization is not the first step. Can you please post an\n> example patch illustrating what needs to be done, so we can follow?\n\nIf you have a code-base with 100 functions, 10 of which make sense in\na public library, instead of going ahead to fix those 10 functions, it\nmakes sense to *first* separate those 10 functions, and *then* clean\nthem up for public usage.\n\nBut let's assume that Jeff is right and this is not the first step. It\ndoesn't matter; I already started that step and created builtin/lib.a.\nAre you going to throw away that because it's not \"the first step\"?\n\n-- \nFelipe Contreras\n"},{"id":"220081","messageId":"CAMP44s0ky7ad3cGBQs0DNht4Uo4MR08VrNx+PigcNraDP76CLA@mail.gmail.com","threadId":"34057","inReplyTo":"20130609181002.GC810@sigill.intra.peff.net","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-09T18:16:37Z","receivedAt":"2013-06-09T18:16:37Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sun, Jun 9, 2013 at 1:10 PM, Jeff King wrote:\n> On Sun, Jun 09, 2013 at 01:01:30PM -0500, Felipe Contreras wrote:\n\n>> > I do not have an interest in cataloguing past conflicts I and others\n>> > have had with you; the list archive has done so.\n>>\n>> No. There is no such catalog. You made a claim, it's not backed by\n>> evidence, merely by your subjective experience. And memory is a pretty\n>> bad indicator of reality.\n>\n> I think this thread is an excellent example all by itself.\n\nIt's an excellent example of your personal issues clouding your judgement.\n\nThe topic was this (which you just snipped):\n\n> Go back to my 261 commits, show me one that is \"unmindful of technical details\".\n\nAnd you say this thread is an excellent example of your point that I'm\nunmindful of technical details?\n\nIt's not. There are no technical details I was unmindful of in this thread.\n\nOnce more, you have no evidence of that claim. Only subjective\npersonal experience.\n\n-- \nFelipe Contreras\n"},{"id":"220084","messageId":"20130609182246.GE810@sigill.intra.peff.net","threadId":"34057","inReplyTo":"CALkWK0n0kkNZo_Xt1oT5GL-TxZP0faDExxyH3vU-+hy4uEUEtQ@mail.gmail.com","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-06-09T18:22:46Z","receivedAt":"2013-06-09T18:22:46Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Jun 09, 2013 at 11:36:42PM +0530, Ramkumar Ramachandra wrote:\n\n> Jeff King wrote:\n> > I already mentioned elsewhere that I think it would be fine to massage\n> > libgit.a in that direction. I even joined the conversation pointing out\n> > some cases where Felipe's ruby module would break. But I do not think\n> > that moving code in and out of libgit.a is an important first step at\n> > all. That is simply code that no library users would want to call, and\n> > is easy to deal with: move it out. The hard part is code that users\n> > _would_ want to call, and is totally broken. Patches dealing with that\n> > are the hard obstacle that people working in this direction would need\n> > to overcome. But I do not see any such patches under discussion.\n> \n> Forget the rest; this makes it clear. Thanks, and sorry for all the confusion.\n> \n> So, reorganization is not the first step. Can you please post an\n> example patch illustrating what needs to be done, so we can follow?\n\nSorry, I don't have patches. It is a hard problem for which I do not\nhave the solution, which is kind of my point.\n\nFor the record, I am not _against_ any code organization that might be\nuseful for lib-ification later. I just do not see it as an interesting\nstep to be discussing if you want to know whether such a lib-ification\neffort is feasible.\n\n-Peff\n"},{"id":"220086","messageId":"CAMP44s21=gMH9wPXN9-dXxM6=jR68ctBXQZzi_G9PL-gMPGN+Q@mail.gmail.com","threadId":"34057","inReplyTo":"20130609182246.GE810@sigill.intra.peff.net","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-09T18:29:50Z","receivedAt":"2013-06-09T18:29:50Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sun, Jun 9, 2013 at 1:22 PM, Jeff King wrote:\n> On Sun, Jun 09, 2013 at 11:36:42PM +0530, Ramkumar Ramachandra wrote:\n>\n>> Jeff King wrote:\n>> > I already mentioned elsewhere that I think it would be fine to massage\n>> > libgit.a in that direction. I even joined the conversation pointing out\n>> > some cases where Felipe's ruby module would break. But I do not think\n>> > that moving code in and out of libgit.a is an important first step at\n>> > all. That is simply code that no library users would want to call, and\n>> > is easy to deal with: move it out. The hard part is code that users\n>> > _would_ want to call, and is totally broken. Patches dealing with that\n>> > are the hard obstacle that people working in this direction would need\n>> > to overcome. But I do not see any such patches under discussion.\n>>\n>> Forget the rest; this makes it clear. Thanks, and sorry for all the confusion.\n>>\n>> So, reorganization is not the first step. Can you please post an\n>> example patch illustrating what needs to be done, so we can follow?\n>\n> Sorry, I don't have patches. It is a hard problem for which I do not\n> have the solution, which is kind of my point.\n\nWouldn't it make sense then to concentrate on the patches that we do have?\n\n> For the record, I am not _against_ any code organization that might be\n> useful for lib-ification later. I just do not see it as an interesting\n> step to be discussing if you want to know whether such a lib-ification\n> effort is feasible.\n\nIf you don't find it interesting, don't do it. I already did this step\n(Move sequencer to builtin), the question is; does it go forward, or\nshould it be rejected?\n\n-- \nFelipe Contreras\n"},{"id":"220089","messageId":"CALkWK0kkhDOSSdF=E4PvO24hg++_FpP3YFaGRD3yq80XG0TRJA@mail.gmail.com","threadId":"34057","inReplyTo":"20130609180437.GB810@sigill.intra.peff.net","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-06-09T18:32:11Z","receivedAt":"2013-06-09T18:32:11Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Jeff King wrote:\n> I actually think word choice and politeness is only a small part of it,\n> and one that I live without. It is not just _how_ something is said,\n> but _what_ is said. And sometimes what is said does not lead in a\n> productive direction. I found Thomas's comment here:\n>\n> http://article.gmane.org/gmane.comp.version-control.git/227053\n>\n> sums up the core of many of the conflicts I've seen on the list.\n\nThis is all very good, Jeff. Various people have expressed what's\nwrong with fc's \"demeanour\", \"tone\", and \"style of discussion\" in\nvarious different ways at various different points in time. This goes\non and on and on with no end in sight. WHAT do we do?\n\nI'll be frank: I'm a pragmatic person, and I want to see work.\nDespite all this mess, who has shown me the most number of patches\nwith some direction? Felipe. Who gets the most number of patches\ninto git.git, by far? Felipe. And who is wasting time theorizing\nabout what's wrong with Felipe in various ways? Everyone else.\n\n> I am less interested in people's feelings than I am in discussions\n> trying to reach a productive position of agreement, rather than turning\n> it into a point by point debate that may no longer have any use for the\n> project (sometimes individual points need to be refuted or discussed, of\n> course, but it is easy to lose sight of the purpose of an email).\n\nFelipe has discussed the {sequencer.c -> builtin/sequencer.c} move\nwith a bunch of us (and sent a patch), discussed how to write tests\nproperly with me (with a patch), and discussed how ruby can be used to\ncall into libgit.a (with code that I'm currently playing with).\n"},{"id":"220091","messageId":"CALkWK0nsJ5ds5v7auoqN7_vXhOoasJ3y99njZt5btPVqRCF2zA@mail.gmail.com","threadId":"34057","inReplyTo":"20130609182246.GE810@sigill.intra.peff.net","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-06-09T18:44:36Z","receivedAt":"2013-06-09T18:44:36Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Jeff King wrote:\n> Sorry, I don't have patches. It is a hard problem for which I do not\n> have the solution, which is kind of my point.\n\nSo, what is the problem? We are moving towards what we think is the\nway forward. Nobody said that it is the theoretical best, but it's\n_much_ better than doing nothing, no?\n\n> For the record, I am not _against_ any code organization that might be\n> useful for lib-ification later. I just do not see it as an interesting\n> step to be discussing if you want to know whether such a lib-ification\n> effort is feasible.\n\nThen whom are we to ask about this feasibility? All the core\ncontributors (including Junio) are in the CC. Nobody has said\nanything. So, are you proposing that we sit and ponder over our\ntheoretically-indeterminate-feasibility problem? There is no magic\nbullet, Jeff. We write code, and we fix bugs as and when they crop\nup; there's really not much else anyone can do. Help by writing code,\nor reviewing someone else's code.\n"},{"id":"220092","messageId":"20130609184553.GG810@sigill.intra.peff.net","threadId":"34057","inReplyTo":"CALkWK0kkhDOSSdF=E4PvO24hg++_FpP3YFaGRD3yq80XG0TRJA@mail.gmail.com","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-06-09T18:45:54Z","receivedAt":"2013-06-09T18:45:54Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jun 10, 2013 at 12:02:11AM +0530, Ramkumar Ramachandra wrote:\n\n> This is all very good, Jeff. Various people have expressed what's\n> wrong with fc's \"demeanour\", \"tone\", and \"style of discussion\" in\n> various different ways at various different points in time. This goes\n> on and on and on with no end in sight. WHAT do we do?\n\nMy advice would be to ignore him when the discussion proceeds in an\nunproductive direction.\n\nBut I never wanted to tell other people what to do with respect to\nFelipe. My point was to express public agreement with Jonathan, and show\nthat individual members of the community may be less interested in\nhelping you if you behave in certain ways. At this point, I do not have\nany hope of impacting Felipe's behavior, but I thought it might be\ndemonstrative to other list members. We do not have an explicit code of\nconduct on the list, but it is not as if behavior is without\nconsequences. If you are not easy to work with, people will get tired of\ndealing with you eventually[1].\n\n-Peff\n\n[1] Or maybe not. Maybe there are enough people interested in what\n Felipe has to say that he will continue to get review. I even try to\n review his patches myself when there is something factually and\n obviously wrong to point out, and it won't suck me into a\n time-wasting argument that goes nowhere.\n\n But the point is that each individual can make the choice\n themselves, and then the problem is solved for them.\n"},{"id":"220093","messageId":"CAMP44s3HaV-V3FZFrsX3rR1FWy-Tzxqibr138bBUizNfhJM9UQ@mail.gmail.com","threadId":"34057","inReplyTo":"CALkWK0kkhDOSSdF=E4PvO24hg++_FpP3YFaGRD3yq80XG0TRJA@mail.gmail.com","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-09T18:48:39Z","receivedAt":"2013-06-09T18:48:39Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sun, Jun 9, 2013 at 1:32 PM, Ramkumar Ramachandra wrote:\n> Jeff King wrote:\n>> I actually think word choice and politeness is only a small part of it,\n>> and one that I live without. It is not just _how_ something is said,\n>> but _what_ is said. And sometimes what is said does not lead in a\n>> productive direction. I found Thomas's comment here:\n>>\n>> http://article.gmane.org/gmane.comp.version-control.git/227053\n>>\n>> sums up the core of many of the conflicts I've seen on the list.\n>\n> This is all very good, Jeff. Various people have expressed what's\n> wrong with fc's \"demeanour\", \"tone\", and \"style of discussion\" in\n> various different ways at various different points in time. This goes\n> on and on and on with no end in sight. WHAT do we do?\n\nWhat really puzzles me is that I think discussion and disagreement are\nhealthy, not only in open source projects, but in any organization; If\neveryone always agrees, you know something is really wrong. But if\nothers think disagreement is not helpful, why do they bother replying\nat all? Arguing. And they think their time is better spent not\ndiscussing, but writing code (or something else), why don't they spend\ntheir time that way. Why blame me for their choices?\n\nWe disagree, that's fine, move on.\n\n> I'll be frank: I'm a pragmatic person, and I want to see work.\n> Despite all this mess, who has shown me the most number of patches\n> with some direction? Felipe. Who gets the most number of patches\n> into git.git, by far? Felipe. And who is wasting time theorizing\n> about what's wrong with Felipe in various ways? Everyone else.\n\nThanks! \"Talk is cheap, show me the code.\"\n\n>> I am less interested in people's feelings than I am in discussions\n>> trying to reach a productive position of agreement, rather than turning\n>> it into a point by point debate that may no longer have any use for the\n>> project (sometimes individual points need to be refuted or discussed, of\n>> course, but it is easy to lose sight of the purpose of an email).\n>\n> Felipe has discussed the {sequencer.c -> builtin/sequencer.c} move\n> with a bunch of us (and sent a patch), discussed how to write tests\n> properly with me (with a patch), and discussed how ruby can be used to\n> call into libgit.a (with code that I'm currently playing with).\n\nInteresting. In case it might help you, this is the extconf.rb I used:\n\n---\nruby/extconf.rb:\n#!/usr/bin/env ruby\n\nrequire 'mkmf'\n\n$INCFLAGS = \"-I.. #{$INCFLAGS}\"\n$CFLAGS += \" -DSHA1_HEADER=''\"\n\n# libs\n$LOCAL_LIBS += ' ../builtin/lib.a ../libgit.a ../xdiff/lib.a'\n$LIBS += ' -lssl -lcrypto -lz'\n\n# make sure there are no undefined symbols\n$LDFLAGS += ' -Wl,--no-undefined'\n\n# Create Makefile\ndir_config('git')\ncreate_makefile('git')\n--\n\nI have to build all the objects with -fPIC though.\n\n-- \nFelipe Contreras\n"},{"id":"220095","messageId":"20130609184943.GH810@sigill.intra.peff.net","threadId":"34057","inReplyTo":"CALkWK0nsJ5ds5v7auoqN7_vXhOoasJ3y99njZt5btPVqRCF2zA@mail.gmail.com","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-06-09T18:49:43Z","receivedAt":"2013-06-09T18:49:43Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jun 10, 2013 at 12:14:36AM +0530, Ramkumar Ramachandra wrote:\n\n> Jeff King wrote:\n> > Sorry, I don't have patches. It is a hard problem for which I do not\n> > have the solution, which is kind of my point.\n> \n> So, what is the problem? We are moving towards what we think is the\n> way forward. Nobody said that it is the theoretical best, but it's\n> _much_ better than doing nothing, no?\n\nI thought I already said: there is a lot of global state that is assumed\nto be wiped between various functions and git commands. For example, you\ncannot just call cmd_log twice in the same process and get the right\nanswers. I haven't seen a proposal for dealing with that.\n\n> Then whom are we to ask about this feasibility? All the core\n> contributors (including Junio) are in the CC. Nobody has said\n> anything. So, are you proposing that we sit and ponder over our\n> theoretically-indeterminate-feasibility problem? There is no magic\n> bullet, Jeff. We write code, and we fix bugs as and when they crop\n> up; there's really not much else anyone can do. Help by writing code,\n> or reviewing someone else's code.\n\nI mentioned a bug above. How are you going to fix it? Where is your\npatch to review?\n\n-Peff\n"},{"id":"220096","messageId":"CAMP44s0i_wcreL024F92HfeKEngEUcW3AKM+qD+TjtVPsZj4aQ@mail.gmail.com","threadId":"34057","inReplyTo":"20130609184943.GH810@sigill.intra.peff.net","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-09T18:54:30Z","receivedAt":"2013-06-09T18:54:30Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sun, Jun 9, 2013 at 1:49 PM, Jeff King wrote:\n> On Mon, Jun 10, 2013 at 12:14:36AM +0530, Ramkumar Ramachandra wrote:\n>\n>> Jeff King wrote:\n>> > Sorry, I don't have patches. It is a hard problem for which I do not\n>> > have the solution, which is kind of my point.\n>>\n>> So, what is the problem? We are moving towards what we think is the\n>> way forward. Nobody said that it is the theoretical best, but it's\n>> _much_ better than doing nothing, no?\n>\n> I thought I already said: there is a lot of global state that is assumed\n> to be wiped between various functions and git commands. For example, you\n> cannot just call cmd_log twice in the same process and get the right\n> answers. I haven't seen a proposal for dealing with that.\n>\n>> Then whom are we to ask about this feasibility? All the core\n>> contributors (including Junio) are in the CC. Nobody has said\n>> anything. So, are you proposing that we sit and ponder over our\n>> theoretically-indeterminate-feasibility problem? There is no magic\n>> bullet, Jeff. We write code, and we fix bugs as and when they crop\n>> up; there's really not much else anyone can do. Help by writing code,\n>> or reviewing someone else's code.\n>\n> I mentioned a bug above. How are you going to fix it? Where is your\n> patch to review?\n\n--- a/git.c\n+++ b/git.c\n@@ -359,7 +359,7 @@ static void handle_internal_command(int argc,\nconst char **argv)\n { \"index-pack\", cmd_index_pack, RUN_SETUP_GENTLY },\n { \"init\", cmd_init_db },\n { \"init-db\", cmd_init_db },\n- { \"log\", cmd_log, RUN_SETUP },\n+ { \"log\", cmd_log, RUN_SETUP | NEEDS_FORK },\n { \"ls-files\", cmd_ls_files, RUN_SETUP },\n { \"ls-remote\", cmd_ls_remote, RUN_SETUP_GENTLY },\n { \"ls-tree\", cmd_ls_tree, RUN_SETUP },\n\nDone.\n\nBut either way, that's orthogonal to the builtin/lib.a issue. It has\nabsolutely nothing to do with Ruby, or my experiment. It's about the\nsequencer and notes, and all that stuff for which I just sent\nforty-something patches. If you have a better idea how to fix that,\nlet's see it.\n\n-- \nFelipe Contreras\n"},{"id":"220101","messageId":"CALKQrgc5K0U2qCHjjzgxw1=70FbmHdokU3H0tfB_=+7gDVNzsA@mail.gmail.com","threadId":"34057","inReplyTo":"CAMP44s0ky7ad3cGBQs0DNht4Uo4MR08VrNx+PigcNraDP76CLA@mail.gmail.com","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2013-06-09T19:11:44Z","receivedAt":"2013-06-09T19:11:44Z","isPatch":true,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Sun, Jun 9, 2013 at 8:16 PM, Felipe Contreras\n wrote:\n> On Sun, Jun 9, 2013 at 1:10 PM, Jeff King wrote:\n>> Go back to my 261 commits, show me one that is \"unmindful of technical details\".\n>\n> And you say this thread is an excellent example of your point that I'm\n> unmindful of technical details?\n>\n> It's not. There are no technical details I was unmindful of in this thread.\n\nOk, I'll bite (against my better judgment). From a related thread, a\nfew minutes ago:\n\nOn Sun, Jun 9, 2013 at 7:46 PM, Felipe Contreras\n wrote:\n> On Sun, Jun 9, 2013 at 12:32 PM, Thomas Rast wrote:\n>> So you would deliberately break a bisection on this test file?\n> No, this patch series won't be applied.\n\nThomas points out a technical detail with the patch series, and the\nanswer given is 100% non-constructive.\n\nFWIW, I'd like to express my support for the opinions expressed by\nJonathan, Jeff and Thomas. They accurately describe my impression of\nthese discussion threads.\n\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"220107","messageId":"87zjuz84tp.fsf@hexa.v.cablecom.net","threadId":"34057","inReplyTo":"CALkWK0kkhDOSSdF=E4PvO24hg++_FpP3YFaGRD3yq80XG0TRJA@mail.gmail.com","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Thomas Rast","fromEmail":"trast@inf.ethz.ch","sentAt":"2013-06-09T19:25:06Z","receivedAt":"2013-06-09T19:25:06Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Ramkumar Ramachandra writes:\n\n> Jeff King wrote:\n>> I actually think word choice and politeness is only a small part of it,\n>> and one that I live without. It is not just _how_ something is said,\n>> but _what_ is said. And sometimes what is said does not lead in a\n>> productive direction. I found Thomas's comment here:\n>>\n>> http://article.gmane.org/gmane.comp.version-control.git/227053\n>>\n>> sums up the core of many of the conflicts I've seen on the list.\n>\n> This is all very good, Jeff. Various people have expressed what's\n> wrong with fc's \"demeanour\", \"tone\", and \"style of discussion\" in\n> various different ways at various different points in time. This goes\n> on and on and on with no end in sight. WHAT do we do?\n>\n> I'll be frank: I'm a pragmatic person, and I want to see work.\n> Despite all this mess, who has shown me the most number of patches\n> with some direction? Felipe. Who gets the most number of patches\n> into git.git, by far? Felipe. And who is wasting time theorizing\n> about what's wrong with Felipe in various ways? Everyone else.\n\nAt what cost?\n\nThe arguments arise to a large degree from attempting to review his\nwork. Not doing so is not an option, see e.g.:\n\n http://article.gmane.org/gmane.comp.version-control.git/223279\n http://article.gmane.org/gmane.comp.version-control.git/225969\n http://article.gmane.org/gmane.comp.version-control.git/226125\n\nAnd that's not even counting the part of the argument that arises purely\nfrom deliberate flaunting of the project's guidelines.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"220146","messageId":"CAMP44s3pAUi9G4BU39bMo5nJ+YyrJ0FS+UY1c5yJsu5+x0k7Gw@mail.gmail.com","threadId":"34057","inReplyTo":"CALKQrgc5K0U2qCHjjzgxw1=70FbmHdokU3H0tfB_=+7gDVNzsA@mail.gmail.com","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-09T19:29:51Z","receivedAt":"2013-06-09T19:29:51Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sun, Jun 9, 2013 at 2:11 PM, Johan Herland wrote:\n> On Sun, Jun 9, 2013 at 8:16 PM, Felipe Contreras\n> wrote:\n>> On Sun, Jun 9, 2013 at 1:10 PM, Jeff King wrote:\n>>> Go back to my 261 commits, show me one that is \"unmindful of technical details\".\n>>\n>> And you say this thread is an excellent example of your point that I'm\n>> unmindful of technical details?\n>>\n>> It's not. There are no technical details I was unmindful of in this thread.\n>\n> Ok, I'll bite (against my better judgment). From a related thread, a\n> few minutes ago:\n>\n> On Sun, Jun 9, 2013 at 7:46 PM, Felipe Contreras\n> wrote:\n>> On Sun, Jun 9, 2013 at 12:32 PM, Thomas Rast wrote:\n>>> So you would deliberately break a bisection on this test file?\n>> No, this patch series won't be applied.\n>\n> Thomas points out a technical detail with the patch series, and the\n> answer given is 100% non-constructive.\n\nGeezus!\n\nhttp://thread.gmane.org/gmane.comp.version-control.git/227109\n\nThere. Are you happy?\n\nI dropped the patches that are not part of the series.\n\nWho benefits from this? NOBODY. Certainly not the users.\n\n-- \nFelipe Contreras\n"},{"id":"220156","messageId":"CALkWK0kX1E9A9q1ptfx-QA1LiBf4UEeHF92xR21am=vv_zKZZA@mail.gmail.com","threadId":"34057","inReplyTo":"87zjuz84tp.fsf@hexa.v.cablecom.net","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-06-09T19:54:09Z","receivedAt":"2013-06-09T19:54:09Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Thomas Rast wrote:\n> The arguments arise to a large degree from attempting to review his\n> work. Not doing so is not an option, see e.g.:\n\nI don't recall saying that you shouldn't review his work (?). What I\n_am_ saying is that there is absolutely no point belaboring over\nwhat's wrong with Felipe's \"tone\", \"demeanour\" and \"style of\ndiscussion\". It has been discussed a zillion times now. You're doing\nit under the pretext of \"agreement\" and \"setting a good example\" (in\njk's words); in reality, you're setting a bad example by showing\neveryone that it is okay to do the same thing (welcome jh!) and waste\neveryone's time.\n\n> http://article.gmane.org/gmane.comp.version-control.git/223279\n> http://article.gmane.org/gmane.comp.version-control.git/225969\n> http://article.gmane.org/gmane.comp.version-control.git/226125\n\nAll these are legitimate reviews, and they and everyone's getting\nalong just fine. What argument are you talking about? *scratches\nhead*\n\n> And that's not even counting the part of the argument that arises purely\n> from deliberate flaunting of the project's guidelines.\n\nWhat guidelines?\n"},{"id":"220157","messageId":"20130609195706.GA2919@elie.Belkin","threadId":"34057","inReplyTo":"20130609184553.GG810@sigill.intra.peff.net","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-06-09T19:57:06Z","receivedAt":"2013-06-09T19:57:06Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Jeff King wrote:\n\n> My advice would be to ignore him when the discussion proceeds in an\n> unproductive direction.\n\nThere is something appealing about that option. The problem is that\nit doesn't work, at least for someone that relies on the list as a way\nof understanding patches that have been applied (which often don't\nhave self-contained descriptions, sadly) and the context of other\npatches.\n\nOf course that's not the intent: the intent of ignoring someone is to\nhope they'll go away. :)\n\nIn the context of other unhealthy behaviors (like alcoholism) there is\na concept of enabling behavior. One of an addict's friends might\nconfront her and try to help her understand that things have gone too\nfar. Another friend says, \"What a mess. Let's go to a bar and talk\"\nand they are drinking again. The usual approach for avoiding this is\nan intervention, where a large group of people that care about a\nperson together agree to confront the addict and make sure she\nactually understands and work together to find a real way out.\n\nOf course the git development community is not organized enough for an\nintervention, but as context I thought I'd mention that that's what\nworks.\n\nRamkumar Ramachandra wrote:\n\n> I'll be frank: I'm a pragmatic person, and I want to see work.\n> Despite all this mess, who has shown me the most number of patches\n> with some direction? Felipe. Who gets the most number of patches\n> into git.git, by far? Felipe. And who is wasting time theorizing\n> about what's wrong with Felipe in various ways? Everyone else.\n\nIn that case, I can see a simple solution. Felipe, who provides the\nmost patches in git.git, by far (I don't know what that means, but\nI'll take it as an assumption), can put up a fork of git that you run.\nHe can solicit whatever level of review he is comfortable with before\npushing out changes, and then the result is available, without the\npesky middle-man of those theorizers that were trying to develop git a\ndifferent way and then got annoyed.\n\nNo harm done, right? It doesn't have to involve the list, because\nwhat's relevant in this worldview is code, not the people.\n\nSo why aren't I privately ignoring his messages and letting the list\nbecome what it may? It would seem that I'm making the problem much\nworse, by starting discussions that focus of how to stop pushing other\ncontributors away instead of (what's important) code!\n\nJonathan\n"},{"id":"220158","messageId":"CAMP44s3Ps9MaiYnNbMOZwU8H4zZ1zoHwscJGHsxjbXomXT-2fA@mail.gmail.com","threadId":"34057","inReplyTo":"CALkWK0kX1E9A9q1ptfx-QA1LiBf4UEeHF92xR21am=vv_zKZZA@mail.gmail.com","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-09T20:02:00Z","receivedAt":"2013-06-09T20:02:00Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sun, Jun 9, 2013 at 2:54 PM, Ramkumar Ramachandra wrote:\n\n>> http://article.gmane.org/gmane.comp.version-control.git/225969\n\nThis is a good example of an evolving discussion. René Scharfe has\naccepted that the API indeed needs work. How exactly it's going to be\nfixed is not entirely clear, but at least there's a patch that\nessentially tackles what I tried to tackle.\n\nSo it's good for the users.\n\n>> http://article.gmane.org/gmane.comp.version-control.git/226125\n\nThis also evolved rather nicely, since there is discussion about\nexactly how the signals should be presented to Windows users, because\nit's clear currently most of the codes only work in Linux.\n\nAgain, users benefit from this.\n\n>> http://article.gmane.org/gmane.comp.version-control.git/223279\n\nUnfortunately nobody took the charge on this ones, so we will remain\nforever in a non-ideal situation.\n\nIt's not my fault though. I sent the patch that fixes the problem, and\nthere's only so much I can do.\n\nNot that it matters much, because the important patches were applied.\n\nBut what does this have to do with anything? How are you helping the\nGit project by bringing this up? How does this help our users?\n\n-- \nFelipe Contreras\n"},{"id":"220159","messageId":"CAMP44s3w0JuV1rryZP_UDzTseX3KjUnHtqPNbw3Qj4EbjqSdYQ@mail.gmail.com","threadId":"34057","inReplyTo":"20130609195706.GA2919@elie.Belkin","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-09T20:07:17Z","receivedAt":"2013-06-09T20:07:17Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sun, Jun 9, 2013 at 2:57 PM, Jonathan Nieder wrote:\n> Jeff King wrote:\n\n> Of course that's not the intent: the intent of ignoring someone is to\n> hope they'll go away. :)\n>\n> In the context of other unhealthy behaviors (like alcoholism) there is\n> a concept of enabling behavior.\n\nThe only one that can enable me is Junio. If he stops merging my\npatches I would stop sending them.\n\nIt appears Junio is a good maintainer though, as he puts the needs of\nthe project, and thus our users, above your personal issues.\n\n>> I'll be frank: I'm a pragmatic person, and I want to see work.\n>> Despite all this mess, who has shown me the most number of patches\n>> with some direction? Felipe. Who gets the most number of patches\n>> into git.git, by far? Felipe. And who is wasting time theorizing\n>> about what's wrong with Felipe in various ways? Everyone else.\n>\n> In that case, I can see a simple solution. Felipe, who provides the\n> most patches in git.git, by far (I don't know what that means, but\n> I'll take it as an assumption),\n\nMaybe this will help understand the meaning of that:\n\n% git shortlog -n -s --no-merges --since '3 months ago'\n 221\tFelipe Contreras\n 83\tJunio C Hamano\n 71\tJeff King\n 62\tMichael Haggerty\n 48\tRamkumar Ramachandra\n 35\tThomas Rast\n 33\tNguyễn Thái Ngọc Duy\n 32\tJohn Keeping\n 30\tRené Scharfe\n 23\tKevin Bracey\n\n-- \nFelipe Contreras\n"},{"id":"220163","messageId":"CALkWK0kMdQEXMTAwFLdz=FXEFiJfemM-+80SCALqS8q9yyr2Qw@mail.gmail.com","threadId":"34057","inReplyTo":"20130609195706.GA2919@elie.Belkin","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-06-09T20:34:36Z","receivedAt":"2013-06-09T20:34:36Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Jonathan Nieder wrote:\n> Of course the git development community is not organized enough for an\n> intervention, but as context I thought I'd mention that that's what\n> works.\n\nAtleast this is more interesting that the canned\nFelipe-demeanour-complaint people constantly bring up boring everyone\nto death.\n\n> In that case, I can see a simple solution. Felipe, who provides the\n> most patches in git.git, by far (I don't know what that means, but\n> I'll take it as an assumption), can put up a fork of git that you run.\n> He can solicit whatever level of review he is comfortable with before\n> pushing out changes, and then the result is available, without the\n> pesky middle-man of those theorizers that were trying to develop git a\n> different way and then got annoyed.\n>\n> No harm done, right? It doesn't have to involve the list, because\n> what's relevant in this worldview is code, not the people.\n\nI'm still scratching my head over what you interpreted. People are\nnot unimportant! Code is result of everyone in the community\nscratching their itches. I value each and every community member, and\ngit.git wouldn't be what it is today without everyone. How did you\ninterpret that as \"I am only interested in Felipe's work, and everyone\nelse is a theorizing buffoon\"? I specifically said theorizing about\nFelipe's behavior over and over and over again is not changing\nanything. Stay on topic, and discuss how to improve libgit.a.\n\nTo me, it is important that everyone stays productive, so we can\nmaximize output. I want more review, more discussions, more code. I\nget bored out of my mind when Junio does feature freezes and nothing\ngoes in. Obviously, people getting offended and writing long\nemotional rants on the list is unproductive and undesirable.\n\n> So why aren't I privately ignoring his messages and letting the list\n> become what it may? It would seem that I'm making the problem much\n> worse, by starting discussions that focus of how to stop pushing other\n> contributors away instead of (what's important) code!\n\nIt is imperative that you express your opinion and discuss it, if\nsomething is troubling you. What is this dichotomy between\ncontributors and code? When did I discuss pushing contributors away?\n"},{"id":"220170","messageId":"7vppvvnetw.fsf@alter.siamese.dyndns.org","threadId":"34057","inReplyTo":"20130609184553.GG810@sigill.intra.peff.net","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-06-09T21:39:55Z","receivedAt":"2013-06-09T21:39:55Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> ... We do not have an explicit code of\n> conduct on the list, but it is not as if behavior is without\n> consequences. If you are not easy to work with, people will get tired of\n> dealing with you eventually[1].\n\nFWIW, I have already reached that point and learned to kill certain\ntypes of threads in my MUA. There is no point wasting time arguing,\nrather than tending to patches from other people.\n\nOne example of killing the entire thread is when I see \"This patch\nwill not be applied\" by Felipe in a thread started with his patch.\nI understand that it is his way to say \"this patch is retracted\"\nwithout having to explicitly say that he now understands that\nreviews showed why the patch was wrong or that he thanks the\nreviewer for enlightening him.\n\nThe patch will come back, with corrections as necessary, if it has\nmerit, so we do not lose anything of value anyway by discarding the\nthread.\n"},{"id":"220171","messageId":"51B4F6CA.8020807@alum.mit.edu","threadId":"34057","inReplyTo":"CALKQrgc5K0U2qCHjjzgxw1=70FbmHdokU3H0tfB_=+7gDVNzsA@mail.gmail.com","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2013-06-09T21:42:34Z","receivedAt":"2013-06-09T21:42:34Z","isPatch":true,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 06/09/2013 09:11 PM, Johan Herland wrote:\n> [...]\n> FWIW, I'd like to express my support for the opinions expressed by\n> Jonathan, Jeff and Thomas. They accurately describe my impression of\n> these discussion threads.\n\nI also agree. In my opinion, Felipe, your abrasiveness, your disregard\nof project standards, and your eternal argumentativeness outweigh the\nbenefit of your contributions, large though they may be.\n\nWriting code is only a small part of keeping the Git project going.\n\n* Reviewing code is an essential, more thankless, and therefore more\nprecious, contribution. Therefore the Git project has standards to make\ncode review less unpleasant and more effective; for example: (1) patches\nshouldn't cause regressions; (2) commit messages have to be written to\nvery high standards; (3) reviewers' comments should be accepted\ngratefully and taken very seriously. Almost everybody in the Git\ncommunity accepts these standards. Felipe, you do not seem to. The\nresult is that reviewers' time and goodwill are wasted, and they\njustifiably feel unvalued. We can't afford to misuse reviewers; they\nare the bedrock (and the bottleneck) of the project.\n\n* Gaining and keeping contributors is important to maintaining the\nsuccess of the project. The mailing list is the main forum for the\ndevelopment community; therefore, it is important that the mailing list\nbe a place where people display a high degree of technical excellence,\nbut also respect for one another, friendliness (or at least a lack of\nhostility), and discussions that do turn into flame wars. It is\npossible to have a profound technical disagreement without losing\nrespect for the other side; contrariwise it is NOT acceptable to twist a\ntechnical disagreement into a personal attack, even by the slightest\ninsinuation. Felipe, in my opinion your participation in the mailing\nlist lowers the tone dramatically, and will result in loss of other\ncontributors and the failure to attract new contributors.\n\nFelipe, I wish that you would devote a small fraction of your prodigious\nenergy to the very difficult challenge of feeling empathy,\nunderstanding, and respect for the other members of the community. But\nif things continue the way they have, I personally would, with sadness\nin my heart, prefer to forgo your patches in exchange for the more\nimportant benefit of a more collegial (and therefore overall more\nproductive and sustainable) community.\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"220216","messageId":"51B51256.5060602@gmail.com","threadId":"34057","inReplyTo":"51B4F6CA.8020807@alum.mit.edu","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Stefano Lattarini","fromEmail":"stefano.lattarini@gmail.com","sentAt":"2013-06-09T23:40:06Z","receivedAt":"2013-06-09T23:40:06Z","isPatch":true,"sender":{"key":"stefano.lattarini@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1429199?v=4"},"body":"[Sorry for the full quote, but sometimes, repetita iuvant]\n\nOn 06/09/2013 11:42 PM, Michael Haggerty wrote:\n> On 06/09/2013 09:11 PM, Johan Herland wrote:\n>> [...]\n>> FWIW, I'd like to express my support for the opinions expressed by\n>> Jonathan, Jeff and Thomas. They accurately describe my impression of\n>> these discussion threads.\n> \n> I also agree. In my opinion, Felipe, your abrasiveness, your disregard\n> of project standards, and your eternal argumentativeness outweigh the\n> benefit of your contributions, large though they may be.\n> \n> Writing code is only a small part of keeping the Git project going.\n> \n> * Reviewing code is an essential, more thankless, and therefore more\n> precious, contribution. Therefore the Git project has standards to make\n> code review less unpleasant and more effective; for example: (1) patches\n> shouldn't cause regressions; (2) commit messages have to be written to\n> very high standards; (3) reviewers' comments should be accepted\n> gratefully and taken very seriously. Almost everybody in the Git\n> community accepts these standards. Felipe, you do not seem to. The\n> result is that reviewers' time and goodwill are wasted, and they\n> justifiably feel unvalued. We can't afford to misuse reviewers; they\n> are the bedrock (and the bottleneck) of the project.\n> \n> * Gaining and keeping contributors is important to maintaining the\n> success of the project. The mailing list is the main forum for the\n> development community; therefore, it is important that the mailing list\n> be a place where people display a high degree of technical excellence,\n> but also respect for one another, friendliness (or at least a lack of\n> hostility), and discussions that do turn into flame wars. It is\n> possible to have a profound technical disagreement without losing\n> respect for the other side; contrariwise it is NOT acceptable to twist a\n> technical disagreement into a personal attack, even by the slightest\n> insinuation. Felipe, in my opinion your participation in the mailing\n> list lowers the tone dramatically, and will result in loss of other\n> contributors and the failure to attract new contributors.\n> \n> Felipe, I wish that you would devote a small fraction of your prodigious\n> energy to the very difficult challenge of feeling empathy,\n> understanding, and respect for the other members of the community. But\n> if things continue the way they have, I personally would, with sadness\n> in my heart, prefer to forgo your patches in exchange for the more\n> important benefit of a more collegial (and therefore overall more\n> productive and sustainable) community.\n> \n> Michael\n> \nFWIW, from the meager but I hope not utterly irrelevant point\nof view of a non-contrib-but-not-clueless user as I am:\n\n *a complete and hear-felt +1 on what Michael said here*\n\nUntil a couple of months ago, skimming this list was mostly a real\npleasure, and would often give me some valuable insight on the\nupcoming features/incompatibilities of Git, help me organize my own\nworkflow as a Git user, and also steadily improve my understanding\nand command of netiquette in both \"generic\" mailing lists and Open\nSource and/or Free Software communities.\n\nNow, when I open my mail and get to the \"git\" folder, I more and\nmore end up asking myself:\n\n 1. \"What kind of flame am I going to have to see today?\"; and\n\n 2. \"How much chaff will I have to navigate through to finally\n to get to interesting stuff (if any is actually left)?\"\n\n*To reiterate:*\n\nSadly, the environment of the Git mailing list has been steadily\nand slowly *sinking* -- sinking from being pleasant and useful\nand even \"educational\", into being annoying and frustrating and\noften somewhat toxic. I usually jeer and despise he who makes\npublic accusations by simply adding his voice to the disapproval\nof the \"community\", but this time, I feel compelled to do exactly\nthat:\n\n I do accuse Felipe's *attitude* to bring on and nourish such\n unpleasantness toxicity. His technical merits and the possible\n qualities of his patches do *nothing* to remove or quell such\n issues.\n\nSorry for the extra potential controversy, but sometimes one has\nto speak up,\n\n Stefano\n"},{"id":"220233","messageId":"CAMP44s3p1atFz52-mKaKpZkLGp+Uoehc1ovTUQAN-raxWzWd8Q@mail.gmail.com","threadId":"34057","inReplyTo":"7vppvvnetw.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-10T05:06:15Z","receivedAt":"2013-06-10T05:06:15Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sun, Jun 9, 2013 at 4:39 PM, Junio C Hamano wrote:\n\n> One example of killing the entire thread is when I see \"This patch\n> will not be applied\" by Felipe in a thread started with his patch.\n> I understand that it is his way to say \"this patch is retracted\"\n> without having to explicitly say that he now understands that\n> reviews showed why the patch was wrong or that he thanks the\n> reviewer for enlightening him.\n\nYou are wrong. There's nothing wrong with the patch.\n\n> The patch will come back, with corrections as necessary, if it has\n> merit, so we do not lose anything of value anyway by discarding the\n> thread.\n\nWrong again. It seems nobody is interested in improving 'git rebase',\nspecially not to reduce the number of forks, and use C code instead\n(git cherry-pick). Instead, people want to complain about the number\nof forks, but not lift a finger about it, not even to review patches.\nGood luck getting them to actually do something about it.\n\nBut thanks for letting me know, I'm dropping right now this series of\nperfectly good 36 patches that move us forward towards our ideal; more\nC code, less script code, improves 'git cherry-pick', simplifies and\nfixes 'git rebase', and makes it more consistent.\n\nI thought you understood that code should speak, but apparently you don't.\n\n-- \nFelipe Contreras\n"},{"id":"220234","messageId":"CAMP44s3XXzGtVQx8x-56iFQ4ph9VOrzoBczpy-xqXKdiRxRU3Q@mail.gmail.com","threadId":"34057","inReplyTo":"51B4F6CA.8020807@alum.mit.edu","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-10T05:12:39Z","receivedAt":"2013-06-10T05:12:39Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sun, Jun 9, 2013 at 4:42 PM, Michael Haggerty wrote:\n\n> Felipe, I wish that you would devote a small fraction of your prodigious\n> energy to the very difficult challenge of feeling empathy,\n\nI do feel empathy, the problem is that you make the assumption that\nother people are like you, and that somehow I like the same things as\nyou; to be treated nicely. I don't.\n\n> understanding, and respect for the other members of the community.\n\nRespect is not automatic.\n\n> But\n> if things continue the way they have, I personally would, with sadness\n> in my heart, prefer to forgo your patches in exchange for the more\n> important benefit of a more collegial (and therefore overall more\n> productive and sustainable) community.\n\nIn other words; you prefer to talk to people that have a similar mind\nthan you, and avoid doing what the project actually needs; code.\n\nI wrote tons of code that help the project. And you avoid that because what?\n\nCan you put the needs of the project about your personal need for\nothers to be nice towards you?\n\n-- \nFelipe Contreras\n"},{"id":"220235","messageId":"CAMP44s3qn2vTQ1oDnAe6m5AzZ_tAK0fe1=-nN=_=fv7TXGnMbw@mail.gmail.com","threadId":"34057","inReplyTo":"51B51256.5060602@gmail.com","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-10T05:15:55Z","receivedAt":"2013-06-10T05:15:55Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sun, Jun 9, 2013 at 6:40 PM, Stefano Lattarini\n wrote:\n\n> I do accuse Felipe's *attitude* to bring on and nourish such\n> unpleasantness toxicity. His technical merits and the possible\n> qualities of his patches do *nothing* to remove or quell such\n> issues.\n\nHow convenient to accuse me and not the others who have as much fault\nif not more. You need two sides to have an argument.\n\nThe difference is; I did actually send code. Code that is good, code\nthat works, and code that users need.\n\n-- \nFelipe Contreras\n"},{"id":"220260","messageId":"7v8v2il62c.fsf@alter.siamese.dyndns.org","threadId":"34057","inReplyTo":"CAMP44s3p1atFz52-mKaKpZkLGp+Uoehc1ovTUQAN-raxWzWd8Q@mail.gmail.com","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-06-10T08:32:11Z","receivedAt":"2013-06-10T08:32:11Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> On Sun, Jun 9, 2013 at 4:39 PM, Junio C Hamano wrote:\n>\n>> One example of killing the entire thread is when I see \"This patch\n>> will not be applied\" by Felipe in a thread started with his patch.\n>> I understand that it is his way to say \"this patch is retracted\"\n>> without having to explicitly say that he now understands that\n>> reviews showed why the patch was wrong or that he thanks the\n>> reviewer for enlightening him.\n>\n> You are wrong. There's nothing wrong with the patch.\n> ...\n> I thought you understood that code should speak, but apparently you don't.\n\nThat is exactly the point Peff raised (and I agreed with), isn't it?\n\nBad behaviour (being difficult to work with) has consequences. E.g.\nconvincing people that it is not worth their time interacting with\nyou, especially when there are better things to do like tending to\nother topics, and you lose the chance to show that your patches are\ngood when they indeed are (I don't even know if these patches in\nquestion are good, and I am not going to find out).\n"},{"id":"220265","messageId":"51B596E9.9080307@gmail.com","threadId":"34057","inReplyTo":"CAMP44s3qn2vTQ1oDnAe6m5AzZ_tAK0fe1=-nN=_=fv7TXGnMbw@mail.gmail.com","subject":"Bad attitudes and problems in the Git community (was: Re: [PATCH 2/2] Move sequencer to builtin)","fromName":"Stefano Lattarini","fromEmail":"stefano.lattarini@gmail.com","sentAt":"2013-06-10T09:05:45Z","receivedAt":"2013-06-10T09:05:45Z","isPatch":true,"sender":{"key":"stefano.lattarini@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1429199?v=4"},"body":"On 06/10/2013 07:15 AM, Felipe Contreras wrote:\n> On Sun, Jun 9, 2013 at 6:40 PM, Stefano Lattarini\n> wrote:\n> \n>> I do accuse Felipe's *attitude* to bring on and nourish such\n>> unpleasantness toxicity. His technical merits and the possible\n>> qualities of his patches do *nothing* to remove or quell such\n>> issues.\n> \n> How convenient to accuse me\n>\nI accuse your *attitude*, which IMHO is now even damaging your\ncode (that is, the acceptance of your code on the part of the\ncommunity).\n\n> and not the others who have as much fault if not more.\n>\nSorry, this is just your opinion. Mine, by observing the proceeding\nfrom the outside, is different: my opinion is that your attitude is\nthe problem.\n\n> You need two sides to have an argument.\n>\nI disagree. Unless you mean than, whenever a part behaves in a\nhostile and aggressive way, the other part should just silently\nknuckle under.\n\n> The difference is; I did actually send code. Code that is good, code\n> that works, and code that users need.\n> \nAs I said, as a *user* (since I'm definitely not a Git developer\nin any sense of the word), I also need a calm and constructive\nenvironment in the community. Or are you interested only in\nusers that can benefit from things you are good at?\n\nRegards,\n Stefano\n"},{"id":"220319","messageId":"CAMP44s1x4Dm2KwyuN=oisSFdoCPxYzu+ZjZjHN45_=i7b=z0_Q@mail.gmail.com","threadId":"34057","inReplyTo":"7v8v2il62c.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-10T16:53:05Z","receivedAt":"2013-06-10T16:53:05Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Mon, Jun 10, 2013 at 3:32 AM, Junio C Hamano wrote:\n> Felipe Contreras writes:\n>\n>> On Sun, Jun 9, 2013 at 4:39 PM, Junio C Hamano wrote:\n>>\n>>> One example of killing the entire thread is when I see \"This patch\n>>> will not be applied\" by Felipe in a thread started with his patch.\n>>> I understand that it is his way to say \"this patch is retracted\"\n>>> without having to explicitly say that he now understands that\n>>> reviews showed why the patch was wrong or that he thanks the\n>>> reviewer for enlightening him.\n>>\n>> You are wrong. There's nothing wrong with the patch.\n>> ...\n>> I thought you understood that code should speak, but apparently you don't.\n>\n> That is exactly the point Peff raised (and I agreed with), isn't it?\n>\n> Bad behaviour (being difficult to work with) has consequences.\n\nIt is not bad behavior. It is bad behavior *in your opinion*, an\nopinion that wouldn't be shared by other projects, like the Linux\nkernel.\n\n> E.g.\n> convincing people that it is not worth their time interacting with\n> you, especially when there are better things to do like tending to\n> other topics, and you lose the chance to show that your patches are\n> good when they indeed are (I don't even know if these patches in\n> question are good, and I am not going to find out).\n\nYou are hurting the Git project by doing that, and our users,\nspecially our Windows users.\n\nI thought you were a good maintainer. But apparently you would rather\nlisten to the people that only complain, rather than actual code, that\nactually improves things.\n\n-- \nFelipe Contreras\n"},{"id":"220320","messageId":"CAMP44s2tqY7k0=8xHW3R1GzG9MrdmF3D=ewmn6etKi5uUvQSrw@mail.gmail.com","threadId":"34057","inReplyTo":"CAMP44s1x4Dm2KwyuN=oisSFdoCPxYzu+ZjZjHN45_=i7b=z0_Q@mail.gmail.com","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-10T16:55:26Z","receivedAt":"2013-06-10T16:55:26Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Mon, Jun 10, 2013 at 11:53 AM, Felipe Contreras\n wrote:\n> On Mon, Jun 10, 2013 at 3:32 AM, Junio C Hamano wrote:\n\n>> E.g.\n>> convincing people that it is not worth their time interacting with\n>> you, especially when there are better things to do like tending to\n>> other topics, and you lose the chance to show that your patches are\n>> good when they indeed are (I don't even know if these patches in\n>> question are good, and I am not going to find out).\n>\n> You are hurting the Git project by doing that, and our users,\n> specially our Windows users.\n>\n> I thought you were a good maintainer. But apparently you would rather\n> listen to the people that only complain, rather than actual code, that\n> actually improves things.\n\nAnd this in fact has a name; *bias*. It is bad in any human endeavor,\nand in logic and argumentation, letting yourself be blinded by who is\nmaking the arguments, rather than the arguments themselves has a name;\nad hominem.\n\nThat is a mistake.\n\n-- \nFelipe Contreras\n"},{"id":"220322","messageId":"CAMP44s3LXrp5_6eHvsFp-4oyoX5FQY0TF_w+ZfQXNS89YzaXaQ@mail.gmail.com","threadId":"34057","inReplyTo":"51B596E9.9080307@gmail.com","subject":"Re: Bad attitudes and problems in the Git community (was: Re: [PATCH 2/2] Move sequencer to builtin)","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-10T16:58:10Z","receivedAt":"2013-06-10T16:58:10Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Mon, Jun 10, 2013 at 4:05 AM, Stefano Lattarini\n wrote:\n\n>> You need two sides to have an argument.\n\n> I disagree. Unless you mean than, whenever a part behaves in a\n> hostile and aggressive way, the other part should just silently\n> knuckle under.\n\nYou are wrong. If a bum in the street starts talking about you about\nwhy you are going to hell, and you reply to him and argue. Who has the\nfault of starting an argument?\n\nBoth. Maybe you have even more blame.\n\n-- \nFelipe Contreras\n"},{"id":"220331","messageId":"vpq7gi1eupf.fsf@anie.imag.fr","threadId":"34057","inReplyTo":"CAMP44s1x4Dm2KwyuN=oisSFdoCPxYzu+ZjZjHN45_=i7b=z0_Q@mail.gmail.com","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-06-10T17:34:04Z","receivedAt":"2013-06-10T17:34:04Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Felipe Contreras writes:\n\n> It is not bad behavior. It is bad behavior *in your opinion*,\n\nAnd in essentially everyone else on this list, it seems.\n\n> an opinion that wouldn't be shared by other projects, like the Linux\n> kernel.\n\nGoogling your name and LKML gives me this in the first page (addressed\nto you):\n\nhttps://lkml.org/lkml/2012/4/12/434\n\"I'm stupider for just reading your email. Go away.\"\n\nhttps://lkml.org/lkml/2012/4/15/112\n\"I'll make one more try at explaining to you, but then I'll just set my\nmail reader to ignore you, because judging by past performance (not\njust in this thread) you will just continue to argue.\"\n\nI don't follow the lkml so maybe I've just been unlucky and Google\ndidn't show me an accurate sample, but arguing that your behavior is\nwelcome on the LKML seems weird.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"220335","messageId":"CALkWK0=A478RNR7v1qQ_xzVhHRRBEF96XHDS_a-dOwv5E0aF-A@mail.gmail.com","threadId":"34057","inReplyTo":"vpq7gi1eupf.fsf@anie.imag.fr","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-06-10T18:09:15Z","receivedAt":"2013-06-10T18:09:15Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Matthieu Moy wrote:\n> https://lkml.org/lkml/2012/4/12/434\n> https://lkml.org/lkml/2012/4/15/112\n\nWe don't want things taken out of context now, do we? Follow up this\nthread [1], if you're interested in that discussion. I did clip out\nthe quotes you chose on purpose, in the interest of presenting\nevidence in an unbiased manner.\n\n> I don't follow the lkml so maybe I've just been unlucky and Google\n> didn't show me an accurate sample, but arguing that your behavior is\n> welcome on the LKML seems weird.\n\nAre people criticizing his discussion style, tone, and demeanour,\ninstead of focusing on the argument?\n\n[1]: http://thread.gmane.org/gmane.linux.kernel/1280458/focus=8675\n"},{"id":"220336","messageId":"CANiSa6iTJuXnKTL50GOv7b=pLLUqA4vc-EsSLi3trh4Ehh3xTg@mail.gmail.com","threadId":"34057","inReplyTo":"CAMP44s3LXrp5_6eHvsFp-4oyoX5FQY0TF_w+ZfQXNS89YzaXaQ@mail.gmail.com","subject":"Re: Bad attitudes and problems in the Git community (was: Re: [PATCH 2/2] Move sequencer to builtin)","fromName":"Martin von Zweigbergk","fromEmail":"martinvonz@gmail.com","sentAt":"2013-06-10T18:11:16Z","receivedAt":"2013-06-10T18:11:16Z","isPatch":true,"sender":{"key":"martinvonz@gmail.com","avatar":"https://avatars.githubusercontent.com/u/891642?v=4"},"body":"On Mon, Jun 10, 2013 at 9:58 AM, Felipe Contreras\n wrote:\n> On Mon, Jun 10, 2013 at 4:05 AM, Stefano Lattarini\n> wrote:\n>\n>>> You need two sides to have an argument.\n>\n>> I disagree. Unless you mean than, whenever a part behaves in a\n>> hostile and aggressive way, the other part should just silently\n>> knuckle under.\n>\n> You are wrong. If a bum in the street starts talking about you about\n> why you are going to hell, and you reply to him and argue. Who has the\n> fault of starting an argument?\n\nI'm not sure I follow the analogy. Are you the bum or the passer-by?\n\nSorry, couldn't help it. :-)\n"},{"id":"220345","messageId":"CACPiFCKJCfw3UDz0jUvE_E-qTvgN_Y3ut_mi_ZubEpxqFdTJYA@mail.gmail.com","threadId":"34057","inReplyTo":"CANiSa6iTJuXnKTL50GOv7b=pLLUqA4vc-EsSLi3trh4Ehh3xTg@mail.gmail.com","subject":"Re: Bad attitudes and problems in the Git community (was: Re: [PATCH 2/2] Move sequencer to builtin)","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2013-06-10T18:33:16Z","receivedAt":"2013-06-10T18:33:16Z","isPatch":true,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On Mon, Jun 10, 2013 at 2:11 PM, Martin von Zweigbergk\n wrote:\n> On Mon, Jun 10, 2013 at 9:58 AM, Felipe Contreras\n> wrote:\n>> On Mon, Jun 10, 2013 at 4:05 AM, Stefano Lattarini\n>> wrote:\n>>\n>>>> You need two sides to have an argument.\n>>\n>>> I disagree. Unless you mean than, whenever a part behaves in a\n>>> hostile and aggressive way, the other part should just silently\n>>> knuckle under.\n>>\n>> You are wrong. If a bum in the street starts talking about you about\n>> why you are going to hell, and you reply to him and argue. Who has the\n>> fault of starting an argument?\n>\n> I'm not sure I follow the analogy. Are you the bum or the passer-by?\n\nhttp://xkcd.com/386/\n\nSomeone is wrong on the Internet!\n\nLet it be.\n\n\nm\n--\n martin.langhoff@gmail.com\n - ask interesting questions\n - don't get distracted with shiny stuff - working code first\n ~ http://docs.moodle.org/en/User:Martin_Langhoff\n"},{"id":"220354","messageId":"CANiSa6h+YAj0MBZtFHurU5JKHUB7X0SQDtqXLCuKjWVro43n1Q@mail.gmail.com","threadId":"34057","inReplyTo":"CACPiFCKJCfw3UDz0jUvE_E-qTvgN_Y3ut_mi_ZubEpxqFdTJYA@mail.gmail.com","subject":"Re: Bad attitudes and problems in the Git community (was: Re: [PATCH 2/2] Move sequencer to builtin)","fromName":"Martin von Zweigbergk","fromEmail":"martinvonz@gmail.com","sentAt":"2013-06-10T18:40:15Z","receivedAt":"2013-06-10T18:40:15Z","isPatch":true,"sender":{"key":"martinvonz@gmail.com","avatar":"https://avatars.githubusercontent.com/u/891642?v=4"},"body":"Yes, sorry. I find this whole story quite amusing (albeit distracting\nand unnecessary), but sorry for adding to the spam. I'll be quiet now.\n\nOn Mon, Jun 10, 2013 at 11:33 AM, Martin Langhoff\n wrote:\n> On Mon, Jun 10, 2013 at 2:11 PM, Martin von Zweigbergk\n> wrote:\n>> On Mon, Jun 10, 2013 at 9:58 AM, Felipe Contreras\n>> wrote:\n>>> On Mon, Jun 10, 2013 at 4:05 AM, Stefano Lattarini\n>>> wrote:\n>>>\n>>>>> You need two sides to have an argument.\n>>>\n>>>> I disagree. Unless you mean than, whenever a part behaves in a\n>>>> hostile and aggressive way, the other part should just silently\n>>>> knuckle under.\n>>>\n>>> You are wrong. If a bum in the street starts talking about you about\n>>> why you are going to hell, and you reply to him and argue. Who has the\n>>> fault of starting an argument?\n>>\n>> I'm not sure I follow the analogy. Are you the bum or the passer-by?\n>\n> http://xkcd.com/386/\n>\n> Someone is wrong on the Internet!\n>\n> Let it be.\n>\n>\n> m\n> --\n> martin.langhoff@gmail.com\n> - ask interesting questions\n> - don't get distracted with shiny stuff - working code first\n> ~ http://docs.moodle.org/en/User:Martin_Langhoff\n"},{"id":"220385","messageId":"CAMP44s3e=-Ce_Vo3pahCSq5MRftWzypiGwcYs=1_6tGaVZuf9g@mail.gmail.com","threadId":"34057","inReplyTo":"CANiSa6iTJuXnKTL50GOv7b=pLLUqA4vc-EsSLi3trh4Ehh3xTg@mail.gmail.com","subject":"Re: Bad attitudes and problems in the Git community (was: Re: [PATCH 2/2] Move sequencer to builtin)","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-10T21:34:04Z","receivedAt":"2013-06-10T21:34:04Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Mon, Jun 10, 2013 at 1:11 PM, Martin von Zweigbergk\n wrote:\n> On Mon, Jun 10, 2013 at 9:58 AM, Felipe Contreras\n> wrote:\n>> On Mon, Jun 10, 2013 at 4:05 AM, Stefano Lattarini\n>> wrote:\n>>\n>>>> You need two sides to have an argument.\n>>\n>>> I disagree. Unless you mean than, whenever a part behaves in a\n>>> hostile and aggressive way, the other part should just silently\n>>> knuckle under.\n>>\n>> You are wrong. If a bum in the street starts talking about you about\n>> why you are going to hell, and you reply to him and argue. Who has the\n>> fault of starting an argument?\n>\n> I'm not sure I follow the analogy. Are you the bum or the passer-by?\n\nIt doesn't matter. Both sides are at fault of an argument.\n\n-- \nFelipe Contreras\n"},{"id":"220386","messageId":"CAMP44s2mu4Q4Gb0f+hsifaDP8CnT2VNHZO7e6dYvYhiyH30PQQ@mail.gmail.com","threadId":"34057","inReplyTo":"vpq7gi1eupf.fsf@anie.imag.fr","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-10T21:43:11Z","receivedAt":"2013-06-10T21:43:11Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Mon, Jun 10, 2013 at 12:34 PM, Matthieu Moy\n wrote:\n> Felipe Contreras writes:\n>\n>> It is not bad behavior. It is bad behavior *in your opinion*,\n>\n> And in essentially everyone else on this list, it seems.\n\nSo? An opinion shared by a billion people is still an opinion, not a\nfact. To think otherwise is to fall in the argumentum ad populum\nfallacy.\n\n>> an opinion that wouldn't be shared by other projects, like the Linux\n>> kernel.\n>\n> Googling your name and LKML gives me this in the first page (addressed\n> to you):\n>\n> https://lkml.org/lkml/2012/4/12/434\n> \"I'm stupider for just reading your email. Go away.\"\n>\n> https://lkml.org/lkml/2012/4/15/112\n> \"I'll make one more try at explaining to you, but then I'll just set my\n> mail reader to ignore you, because judging by past performance (not\n> just in this thread) you will just continue to argue.\"\n>\n> I don't follow the lkml so maybe I've just been unlucky and Google\n> didn't show me an accurate sample, but arguing that your behavior is\n> welcome on the LKML seems weird.\n\nNow you are committing two fallacies at the same time; argument from\nauthority and hasty generalization.\n\nYes, Linus Torvalds lost his temper with me, he has done so with so\nmany people that's hardly surprising. I still think he is wrong, but\nto prove it I need information that is not readily available, and it's\nnot that important anyway.\n\nThat doesn't mean that Linus' opinion is shared by the list (or any\nother Linux mailing list); if you think so you are committing the\nhasty generalization fallacy.\n\nAnd if you think Linus' opinion means something is a fact you commit\nthe argument from authority fallacy.\n\nNone of this mean that my patches are not welcome in LKML, or any\nother Linux mailing list.\n\nI repeat what Linus said:\n\nTalk is cheap, show me the code.\n\n-- \nFelipe Contreras\n"},{"id":"220421","messageId":"20130611091807.GA11361@alap2.anarazel.de","threadId":"34057","inReplyTo":"CAMP44s35w_ysvd5c8oANF8YpWvsquY50bUjSfjOxtujdpgBCPQ@mail.gmail.com","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Andres Freund","fromEmail":"andres@anarazel.de","sentAt":"2013-06-11T09:18:07Z","receivedAt":"2013-06-11T09:18:07Z","isPatch":true,"sender":{"key":"andres@anarazel.de","avatar":null},"body":"On 2013-06-09 13:01:30 -0500, Felipe Contreras wrote:\n> >> You don't agree that 1) a collegial work environment is overrated, 2)\n> >> that the Linux kernel doesn't put an emphasis on being collegial, or\n> >> 3) that it's the most successful software project in history?\n> >\n> > Point 1.\n> \n> Good, so we agree that a project doesn't need a collegial work\n> environment to be extremely and amazingly successful. In fact, any\n> rational person would keep an open mind to the fact that perhaps it\n> actually _helps_ to not have such environment, based on the evidence.\n\nJust from skimming both lists, most of the time I find lkml to be nicer\n(and more collegial) to read because it has a better atmosphere than\ngit@ had in the last year or two.\n\nAnd yes, a good atmosphere plays an important role. One of the reasons\nis that it makes it easier to discern arguments based on personality\ndisputes - which certainly exist on lk - from actual technical\ndisagreements that need to be resolved.\n\nGreetings,\n\nAndres Freund\n"},{"id":"220422","messageId":"CAMP44s2eUiZx6MaZ52Z0Ns40YapiEtzzZK6NJP8pNLiT5Z-pAg@mail.gmail.com","threadId":"34057","inReplyTo":"20130611091807.GA11361@alap2.anarazel.de","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-11T09:29:11Z","receivedAt":"2013-06-11T09:29:11Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, Jun 11, 2013 at 4:18 AM, Andres Freund wrote:\n> On 2013-06-09 13:01:30 -0500, Felipe Contreras wrote:\n>> >> You don't agree that 1) a collegial work environment is overrated, 2)\n>> >> that the Linux kernel doesn't put an emphasis on being collegial, or\n>> >> 3) that it's the most successful software project in history?\n>> >\n>> > Point 1.\n>>\n>> Good, so we agree that a project doesn't need a collegial work\n>> environment to be extremely and amazingly successful. In fact, any\n>> rational person would keep an open mind to the fact that perhaps it\n>> actually _helps_ to not have such environment, based on the evidence.\n>\n> Just from skimming both lists, most of the time I find lkml to be nicer\n> (and more collegial) to read because it has a better atmosphere than\n> git@ had in the last year or two.\n\nA better atmosphere, yes, because they know how to avoid flamewars,\nand concentrate on technical issues, not because they have a collegial\nwork environment.\n\nUnless you think this reply[1] is collegial. Even though I haven't\nbeen following Linux mailing lists that closely lately, I still manage\nto see a lot of these kinds of replies.\n\n> And yes, a good atmosphere plays an important role. One of the reasons\n> is that it makes it easier to discern arguments based on personality\n> disputes - which certainly exist on lk - from actual technical\n> disagreements that need to be resolved.\n\nThat's right, but that's not because everyone is collegial in LKML,\nwhich they most certainly are not. Linus being one of many examples.\n\n[1] http://article.gmane.org/gmane.linux.usb.general/85952\n\n-- \nFelipe Contreras\n"},{"id":"221521","messageId":"CACnwZYdLLJpcLJfagN=Xny3TLX=R6jcVF=o9yPoZoFZ38od0sA@mail.gmail.com","threadId":"34057","inReplyTo":"CAMP44s2eUiZx6MaZ52Z0Ns40YapiEtzzZK6NJP8pNLiT5Z-pAg@mail.gmail.com","subject":"Re: [PATCH 2/2] Move sequencer to builtin","fromName":"Thiago Farina","fromEmail":"tfransosi@gmail.com","sentAt":"2013-06-20T21:11:16Z","receivedAt":"2013-06-20T21:11:16Z","isPatch":true,"sender":{"key":"tfransosi@gmail.com","avatar":"https://avatars.githubusercontent.com/u/970071?v=4"},"body":"May be because they (LKM) are more open to such architectural and\norganization refactorings?\n\nSome maintainers, like Greg Kroah-Hartman and possibly others accept\nclean up patches, such thing seems to be unacceptable here on git.\nLooks like there is space here only for features and bug fixes.\nNothing else. I'm not saying that is bad at all.\n"}]}