{"thread":{"id":"19387","subject":"What's cooking in git.git (May 2009, #02; Sun, 17)","startedAt":"2009-05-17T08:05:18Z","lastAt":"2009-05-25T23:15:46Z","messageCount":23,"participants":["Junio C Hamano","Jakub Narebski","David Aguilar","Johan Herland","Markus Heidelberg","Johannes Schindelin","Avery Pennarun","Peter Hutterer"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"114124","messageId":"7vab5ci281.fsf@alter.siamese.dyndns.org","threadId":"19387","inReplyTo":null,"subject":"What's cooking in git.git (May 2009, #02; Sun, 17)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-05-17T08:05:18Z","receivedAt":"2009-05-17T08:05:18Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Here are the topics that have been cooking.  Commits prefixed with '-' are\nonly in 'pu' while commits prefixed with '+' are in 'next'.  The ones\nmarked with '.' do not appear in any of the branches, but I am still\nholding onto them.\n\nThe topics list the commits in reverse chronological order.  The topics\nmeant to be merged to the maintenance series have \"maint-\" in their names.\n\n----------------------------------------------------------------\n[New Topics]\n\n* jc/mktree (Thu May 14 15:49:10 2009 -0700) 9 commits\n - mktree: validate entry type in input\n - mktree --batch: build more than one tree object\n - mktree --missing: updated usage message and man page\n - mktree --missing: allow missing objects\n - t1010: add mktree test\n - mktree: do not barf on a submodule commit\n - builtin-mktree.c: use a helper function to handle one line of\n   input\n - mktree: use parse-options\n - build-in git-mktree\n\n* ar/maint-1.6.2-merge-recursive-d-f (Mon May 11 21:25:36 2009 +0200) 2 commits\n - Fix for a merge where a branch has an F->D transition\n - Add a reminder test case for a merge with F/D transition\n\nAlthough the reported breakage is covered with the patch, Alex feels the\nsolution unsatisfactory. Cleaning up D/F conflict handling in merge-recursive\nmay be long overdue but seems to be a hard problem.\n\n* jc/maint-add-p-coalesce-fix (Sat May 16 10:48:23 2009 -0700) 2 commits\n + Revert \"git-add--interactive: remove hunk coalescing\"\n + Splitting a hunk that adds a line at the top fails in \"add -p\"\n\n* sb/format-patch-parseopt (Sat May 16 02:24:46 2009 -0700) 1 commit\n - format-patch: migrate to parse-options API\n\n* fc/decorate-tag (Thu May 14 00:32:53 2009 +0300) 2 commits\n + Prettify log decorations even more\n + Change prettify_ref to prettify_refname\n\n* mg/track (Mon May 11 16:42:54 2009 +0200) 2 commits\n + Fix behavior with non-commit upstream references\n + Test tracking of non-commit upstreams\n\n* jn/gitweb-cleanup (Mon May 11 19:45:11 2009 +0200) 8 commits\n + gitweb: Remove unused $hash_base parameter from\n   normalize_link_target\n + gitweb: Simplify snapshot format detection logic in\n   evaluate_path_info\n + gitweb: Use capturing parentheses only when you intend to capture\n + gitweb: Replace wrongly added tabs with spaces\n + gitweb: Use block form of map/grep in a few cases more\n + gitweb: Always use three argument form of open\n + gitweb: Always use three argument form of open\n + gitweb: Do not use bareword filehandles\n\n* js/maint-no-ln-across-libexec-and-bin (Mon May 11 13:02:18 2009 +0200) 1 commit\n + Add NO_CROSS_DIRECTORY_HARDLINKS support to the Makefile\n\n* jh/notes (Sat May 16 13:44:17 2009 +0200) 5 commits\n - Teach \"-m <msg>\" and \"-F <file>\" to \"git notes edit\"\n - Add an expensive test for git-notes\n - Speed up git notes lookup\n - Add a script to edit/inspect notes\n - Introduce commit notes\n\n* tp/send-email-from-config (Tue May 12 15:48:56 2009 -0700) 1 commit\n + send-email: Add config option for sender address\n\n* lt/read-directory (Fri May 15 12:01:29 2009 -0700) 3 commits\n - Add initial support for pathname conversion to UTF-8\n - read_directory(): infrastructure for pathname character set\n   conversion\n - Add 'fill_directory()' helper function for directory traversal\n\n----------------------------------------------------------------\n[Will merge to \"master\" soon]\n\n* mw/send-email (Mon Apr 13 13:23:52 2009 -0500) 6 commits\n + send-email: Remove superfluous `my $editor = ...'\n + send-email: 'References:' should only reference what is sent\n + send-email: Handle \"GIT:\" rather than \"GIT: \" during --compose\n + Docs: send-email: --smtp-server-port can take symbolic ports\n + Docs: send-email: Refer to CONFIGURATION section for\n   sendemail.multiedit\n + Docs: send-email: Put options back into alphabetical order\n\n* ae/anon-fetch-info (Fri Apr 17 10:20:11 2009 +0200) 1 commit\n + fetch: Strip usernames from url's before storing them\n\n* ac/graph-horizontal-line (Tue Apr 21 08:47:01 2009 -0400) 1 commit\n + graph API: Use horizontal lines for more compact graphs\n\n* ph/submodule-rebase (Fri Apr 24 09:06:38 2009 +1000) 1 commit\n + git-submodule: add support for --rebase.\n\n* mh/show-branch-color (Sat Apr 25 13:46:14 2009 +0200) 2 commits\n + bash completion: show-branch color support\n + show-branch: color the commit status signs\n\n* mh/diff-stat-color (Sat Apr 25 00:06:47 2009 +0200) 1 commit\n + diff: do not color --stat output like patch context\n\n* js/add-edit (Mon Apr 27 19:51:42 2009 +0200) 2 commits\n + t3702: fix reliance on SHELL_PATH being '/bin/sh'\n + git-add: introduce --edit (to edit the diff vs. the index)\n\n* jk/maint-add-empty (Tue Apr 28 23:21:01 2009 -0400) 1 commit\n + add: don't complain when adding empty project root\n\nWhen you say \"git add .\" in an empty directory, you get \"No path matches\n''\", instead of \"No path matches '.'\", and this \"fixes\" it by hiding the\nerror and making the command silently succeed.  Strictly speaking it\nintroduces inconsistency, but I think an empty directory is so\nuninteresting special case that not signalling it as an error is Ok.\n\n* ar/unlink-err (Wed Apr 29 23:24:52 2009 +0200) 3 commits\n + print unlink(2) errno in copy_or_link_directory\n + replace direct calls to unlink(2) with unlink_or_warn\n + Introduce an unlink(2) wrapper which gives warning if unlink\n   failed\n\n* ar/merge-one-file-diag (Wed Apr 29 23:40:50 2009 +0200) 1 commit\n + Clarify kind of conflict in merge-one-file helper\n\n* np/push-delta (Fri May 1 16:56:47 2009 -0400) 1 commit\n + allow OFS_DELTA objects during a push\n\n* mt/submodule-reference (Mon May 4 22:30:01 2009 +0300) 1 commit\n + Add --reference option to git submodule.\n\n* fl/git-pm (Thu May 7 15:41:28 2009 +0200) 2 commits\n + Git.pm: Always set Repository to absolute path if autodetecting\n + Git.pm: Set GIT_WORK_TREE if we set GIT_DIR\n\n* rs/grep-parseopt (Thu May 7 21:46:48 2009 +0200) 5 commits\n + grep: use parseopt\n + grep: remove global variable builtin_grep\n + parseopt: add PARSE_OPT_NODASH\n + parseopt: add OPT_NUMBER_CALLBACK\n + parseopt: add OPT_NEGBIT\n\n* jk/no-no-no-empty-directory (Fri May 8 01:01:17 2009 -0400) 2 commits\n + parseopt: add OPT_NEGBIT\n + parseopt: add OPT_NEGBIT\n\nI somehow botched the commit log message of the top one; it is about\nfixing \"ls-files --no-empty-directory\".\n\n* jk/maint-1.6.0-trace-argv (Fri May 8 05:06:15 2009 -0400) 1 commit\n + fix GIT_TRACE segfault with shell-quoted aliases\n\n* hv/sample-update (Fri May 8 17:22:30 2009 +0200) 1 commit\n + Extend sample update hook, disable modifying of existing tags\n\n* rr/forbid-bs-in-ref (Fri May 8 07:32:37 2009 +0200) 1 commit\n + Disallow '\\' in ref names\n\nThis retroactively forbids use of what people could have been using\nhappily, which, strictly speaking, is a no-no, but makes sense in the\nlonger term.\n\n* do/maint-merge-recursive-fix (Sat May 9 14:49:59 2009 -0700) 1 commit\n + merge-recursive: never leave index unmerged while recursing\n\n* jm/format-patch-no-auto-n-when-k-is-given (Sat May 9 10:12:01 2009 +0200) 1 commit\n + format-patch let -k override a config-specified format.numbered\n\n* lt/maint-diff-reduce-lstat (Sat May 9 15:11:17 2009 -0700) 2 commits\n + Teach 'git checkout' to preload the index contents\n + Avoid unnecessary 'lstat()' calls in 'get_stat_data()'\n\n* cc/bisect (Sat May 9 17:55:47 2009 +0200) 20 commits\n + bisect: make \"git bisect\" use new \"--next-all\" bisect-helper\n   function\n + bisect: add \"check_good_are_ancestors_of_bad\" function\n + bisect: implement the \"check_merge_bases\" function\n + bisect: automatically sort sha1_array if needed when looking it up\n + bisect: make skipped array functions more generic\n + bisect: remove too much function nesting\n + bisect: use new \"struct argv_array\" to prepare argv for\n   \"setup_revisions\"\n + bisect: store good revisions in a \"sha1_array\"\n + bisect: implement \"rev_argv_push\" to fill an argv with revs\n + bisect: use \"sha1_array\" to store skipped revisions\n + am: simplify \"sq\" function by using \"git rev-parse --sq-quote\"\n + bisect: use \"git rev-parse --sq-quote\" instead of a custom \"sq\"\n   function\n + rev-parse: add --sq-quote to shell quote arguments\n + rev-list: remove stringed output flag from \"show_bisect_vars\"\n + bisect--helper: remove \"--next-vars\" option as it is now useless\n + bisect: use \"git bisect--helper --next-exit\" in \"git-bisect.sh\"\n + bisect--helper: add \"--next-exit\" to output bisect results\n + bisect: move common bisect functionality to \"bisect_common\"\n + rev-list: refactor printing bisect vars\n + rev-list: make \"estimate_bisect_steps\" non static\n\nRewriting major part of \"git-bisect\" shell script continues.  The patches\nseem to be reasonably clean.\n\n----------------------------------------------------------------\n[Stalled and may need help and prodding to go forward]\n\n* ps/blame (Thu Mar 12 21:30:03 2009 +1100) 1 commit\n - blame.c: start libifying the blame infrastructure\n\nA few minor point remains in this initial one.  I hate to do these minor\nfix-ups myself, but I may end up doing so...\n\n* jc/log-tz (Tue Mar 3 00:45:37 2009 -0800) 1 commit\n - Allow --date=local --date=other-format to work as expected\n\nThe one I posted had a few corner-case bugs that was caught with the test\nsuite; this one has them fixed.  People did not like the UI so it is kept\nout of 'next'\n\n* jc/merge-convert (Mon Jan 26 16:45:01 2009 -0800) 1 commit\n - git-merge-file: allow converting the results for the work tree\n\nThis is a feature waiting for a user.\n\nWe did not give scripted Porcelains a way to say \"this temporary file I am\nusing for merging is for this path, so use the core.autocrlf and attributes\nrules for that final path\".  Instead, merge-file simply wrote out the\ndata in the canonical repository representation.\n\nrerere has the same issue, but it is a lot worse.  It reads the three\nfiles (preimage, postimage and thisimage) from the work tree in the work\ntree representation, merges them without converting them to the canonical\nrepresentation first but inserts the conflict markers with the canonical\nrepresentation and writes the resulting mess out.  It needs to be fixed to\nread with convert_to_git(), merge them while they are still in the\ncanonical representation and possibly add conflict markers, and then write\nthe results out after convert_to_working_tree().  It also needs to write\nin binary mode as well.\n\n* db/foreign-scm (Tue Mar 24 23:04:12 2009 -0400) 3 commits\n - Add option for using a foreign VCS\n - Document details of transport function APIs\n - Allow late reporting of fetched hashes\n\n* hv/cvsps-tests (Sun Apr 5 01:40:50 2009 -0700) 8 commits\n - t/t9600: remove exit after test_done\n - cvsimport: extend testcase about patchset order to contain\n   branches\n - cvsimport: add test illustrating a bug in cvsps\n - Add a test of \"git cvsimport\"'s handling of tags and branches\n - Add some tests of git-cvsimport's handling of vendor branches\n - Test contents of entire cvsimported \"master\" tree contents\n - Use CVS's -f option if available (ignore user's ~/.cvsrc file)\n - Start a library for cvsimport-related tests\n\n----------------------------------------------------------------\n[Actively cooking]\n\n* da/mergetool-lib (Sat May 2 01:57:21 2009 -0700) 1 commit\n - mergetool--lib: specialize diff options for emerge and ecmerge\n\nCan somebody tell me what the current status of this is?  I thought there\nwas some objection, but I lost track...\n\n* rc/http-push (Sat May 16 11:51:52 2009 +0800) 12 commits\n - http*: add fetch_http_pack_index\n - http: create function end_url_with_slash\n - http*: move common variables and macros to http.[ch]\n - http-push: do not SEGV after fetching a bad pack idx file\n - http*: copy string returned by sha1_to_hex\n - http-walker: verify remote packs\n - http-push, http-walker: style fixes\n - t5550-http-fetch: test fetching of packed objects\n - http-push: fix missing \"#ifdef USE_CURL_MULTI\" around\n   \"is_running_queue\"\n - http-push: send out fetch requests on queue\n - t5540-http-push: test fetching of packed objects\n - t5540-http-push: test fetching of loose objects\n\nThere was an 11-patch updates but in the middle there were some\ncompilation breakage issues; only early part of that series is queued.\n\n* cc/replace (Tue Apr 14 00:36:59 2009 +0200) 13 commits\n - Documentation: add documentation for \"git replace\"\n - Add git-replace to .gitignore\n - builtin-replace: use \"usage_msg_opt\" to give better error messages\n - parse-options: add new function \"usage_msg_opt\"\n - builtin-replace: teach \"git replace\" to actually replace\n - Add new \"git replace\" command\n - environment: add global variable to disable replacement\n - mktag: call \"check_sha1_signature\" with the replacement sha1\n - replace_object: add a test case\n - object: call \"check_sha1_signature\" with the replacement sha1\n - sha1_file: add a \"read_sha1_file_repl\" function\n - replace_object: add mechanism to replace objects found in\n   \"refs/replace/\"\n - refs: add a \"for_each_replace_ref\" function\n\nI suspect an attempt to replace an object that is directly listed on the\ncommand line would not work very well with this series.\n\n----------------------------------------------------------------\n[On Hold]\n\n* jc/deny-delete-current-1.7.0 (Mon Feb 9 00:19:46 2009 -0800) 1 commit\n - receive-pack: default receive.denyDeleteCurrent to refuse\n\n* jc/refuse-push-to-current-1.7.0 (Wed Feb 11 02:28:03 2009 -0800) 1 commit\n - Refuse updating the current branch in a non-bare repository via\n   push\n\nThese are for 1.7.0, but the messages when they trigger together may need\nto be rethought.\n\n----------------------------------------------------------------\n[Discarded]\n\n* js/notes (Tue Apr 14 00:03:36 2009 +0200) 15 commits\n . Documentation: fix 'linkgit' macro in \"git-notes.txt\"\n . tests: fix \"export var=val\"\n . notes: refuse to edit notes outside refs/notes/\n . t3301: use test_must_fail instead of !\n . t3301: fix confusing quoting in test for valid notes ref\n . notes: use GIT_EDITOR and core.editor over VISUAL/EDITOR\n . notes: only clean up message file when editing\n . handle empty notes gracefully\n . git notes show: test empty notes\n . git-notes: fix printing of multi-line notes\n . notes: fix core.notesRef documentation\n . Add an expensive test for git-notes\n . Speed up git notes lookup\n . Add a script to edit/inspect notes\n . Introduce commit notes\n\nThis has been replaced by jh/notes series.\n"},{"id":"114125","messageId":"m3zldcjc76.fsf@localhost.localdomain","threadId":"19387","inReplyTo":"7vab5ci281.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (May 2009, #02; Sun, 17)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-05-17T09:45:24Z","receivedAt":"2009-05-17T09:45:24Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> * jn/gitweb-cleanup (Mon May 11 19:45:11 2009 +0200) 8 commits\n>  + gitweb: Remove unused $hash_base parameter from\n>    normalize_link_target\n>  + gitweb: Simplify snapshot format detection logic in\n>    evaluate_path_info\n>  + gitweb: Use capturing parentheses only when you intend to capture\n>  + gitweb: Replace wrongly added tabs with spaces\n>  + gitweb: Use block form of map/grep in a few cases more\n>  + gitweb: Always use three argument form of open\n>  + gitweb: Always use three argument form of open\n>  + gitweb: Do not use bareword filehandles\n\nWhy \"gitweb: Always use three argument form of open\" is twice here?\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"114130","messageId":"20090517114142.GA25956@gmail.com","threadId":"19387","inReplyTo":"7vab5ci281.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (May 2009, #02; Sun, 17)","fromName":"David Aguilar","fromEmail":"davvid@gmail.com","sentAt":"2009-05-17T11:41:43Z","receivedAt":"2009-05-17T11:41:43Z","isPatch":false,"sender":{"key":"davvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13196?v=4"},"body":"On Sun, May 17, 2009 at 01:05:18AM -0700, Junio C Hamano wrote:\n> ----------------------------------------------------------------\n> [Actively cooking]\n> \n> * da/mergetool-lib (Sat May 2 01:57:21 2009 -0700) 1 commit\n>  - mergetool--lib: specialize diff options for emerge and ecmerge\n> \n> Can somebody tell me what the current status of this is?  I thought there\n> was some objection, but I lost track...\n\nThis one was good to go.\n\nThe original reporter of the problem w/ emerge was happy with\nthe patch.  The specialization for ecmerge was also correct.\n\nThe objection was about having to translate the ecmerge command\nname for mac os x (which the patch doesn't do).  We\nsettled on not doing it (meaning leave the patch alone\nas-is) since it's not customary for os x users to have ecmerge\nin their $PATH and thus it's up to them to configure it if\nthey want it.  The motivation being that we don't want to\nstart special-casing any platforms.\n\nThe patch for araxis was also good (after explaining that the\n-title: options don't work correctly which is why the patch\ndidn't include it).  I can resend again later in case\nit got lost.  I also share Dscho's \"if it's not free then I\nwon't touch it\" attitude, tho I'm not opposed to helping out\nusers on under-privileged platforms from time to time.\nIt seemed like Myagi(?) wasted a lot of time getting araxis\nworking with msysgit/mergetool so porting the patch to\nmergetool--lib felt like the nice thing to do.\n\n-- \n\n\tDavid\n"},{"id":"114141","messageId":"7v1vqnipc0.fsf@alter.siamese.dyndns.org","threadId":"19387","inReplyTo":"m3zldcjc76.fsf@localhost.localdomain","subject":"Re: What's cooking in git.git (May 2009, #02; Sun, 17)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-05-17T17:58:23Z","receivedAt":"2009-05-17T17:58:23Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski <jnareb@gmail.com> writes:\n\n> Junio C Hamano <gitster@pobox.com> writes:\n>\n>> * jn/gitweb-cleanup (Mon May 11 19:45:11 2009 +0200) 8 commits\n>>  + gitweb: Remove unused $hash_base parameter from\n>>    normalize_link_target\n>>  + gitweb: Simplify snapshot format detection logic in\n>>    evaluate_path_info\n>>  + gitweb: Use capturing parentheses only when you intend to capture\n>>  + gitweb: Replace wrongly added tabs with spaces\n>>  + gitweb: Use block form of map/grep in a few cases more\n>>  + gitweb: Always use three argument form of open\n>>  + gitweb: Always use three argument form of open\n>>  + gitweb: Do not use bareword filehandles\n>\n> Why \"gitweb: Always use three argument form of open\" is twice here?\n\nPerhaps you sent in a malformed message and I did not notice nor hand\nmunge it?  Let's see...\n\n      Message-ID: <200905110329.40666.jnareb@gmail.com>\n\nYeah, that's it.\n"},{"id":"114142","messageId":"200905172027.22374.jnareb@gmail.com","threadId":"19387","inReplyTo":"7v1vqnipc0.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (May 2009, #02; Sun, 17)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-05-17T18:27:20Z","receivedAt":"2009-05-17T18:27:20Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Sun, 17 May 2009, Junio C Hamano wrote:\n> Jakub Narebski <jnareb@gmail.com> writes:\n>> Junio C Hamano <gitster@pobox.com> writes:\n>>\n>>> * jn/gitweb-cleanup (Mon May 11 19:45:11 2009 +0200) 8 commits\n>>>  + gitweb: Remove unused $hash_base parameter from\n>>>    normalize_link_target\n>>>  + gitweb: Simplify snapshot format detection logic in\n>>>    evaluate_path_info\n>>>  + gitweb: Use capturing parentheses only when you intend to capture\n>>>  + gitweb: Replace wrongly added tabs with spaces\n>>>  + gitweb: Use block form of map/grep in a few cases more\n>>>  + gitweb: Always use three argument form of open\n>>>  + gitweb: Always use three argument form of open\n>>>  + gitweb: Do not use bareword filehandles\n>>\n>> Why \"gitweb: Always use three argument form of open\" is twice here?\n> \n> Perhaps you sent in a malformed message and I did not notice nor hand\n> munge it?  Let's see...\n> \n>       Message-ID: <200905110329.40666.jnareb@gmail.com>\n> \n> Yeah, that's it.\n\nOoops. I have put v2 of 'gitweb: Localize magic variable $/' as a reply\nto a wrong post, and forgot to massage the email... still, shouldn't\ngit-am pick up \"Subject:\" from a body of email?\n\nWell, it is in 'next' already, so resend wouldn't help...\n\nI'm sorry about that...\n-- \nJakub Narebski\nPoland\n"},{"id":"114178","messageId":"200905181536.39508.johan@herland.net","threadId":"19387","inReplyTo":"7vab5ci281.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (May 2009, #02; Sun, 17)","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2009-05-18T13:36:39Z","receivedAt":"2009-05-18T13:36:39Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Sunday 17 May 2009, Junio C Hamano wrote:\n> [Will merge to \"master\" soon]\n>\n> * ph/submodule-rebase (Fri Apr 24 09:06:38 2009 +1000) 1 commit \n>  + git-submodule: add support for --rebase.\n\nJust a quick question before this ends up in 'master'. I'm sorry if this \nhas already been answered:\n\nWhy only --rebase, and not also --merge?\n\nI certainly don't have anything against \"git submodule update --rebase\", \nand I support its inclusion, but why not also \"--merge\"? While --rebase \ncalls \"git rebase\" instead of \"git checkout\", --merge would call \"git \nmerge\" instead. I believe there are useful workflows where --merge \nwould be a better fit than --rebase.\n\nNow, my question should not stop this feature from going into 'master', \nexcept for the fact that if we also want to support merge, we should \nrename the associated config variable:\n\nInstead of\n\n  submodule.<name>.rebase = true/false (false if unset)\n\nwe should have something like\n\n  submodule.<name>.resolve = checkout/rebase/merge (checkout if unset)\n\n\nHmm?\n\n...Johan\n\n-- \nJohan Herland, <johan@herland.net>\nwww.herland.net\n"},{"id":"114198","messageId":"200905182140.29953.markus.heidelberg@web.de","threadId":"19387","inReplyTo":"200905181536.39508.johan@herland.net","subject":"Re: What's cooking in git.git (May 2009, #02; Sun, 17)","fromName":"Markus Heidelberg","fromEmail":"markus.heidelberg@web.de","sentAt":"2009-05-18T19:40:29Z","receivedAt":"2009-05-18T19:40:29Z","isPatch":false,"sender":{"key":"markus.heidelberg@web.de","avatar":"https://avatars.githubusercontent.com/u/6334512?v=4"},"body":"Johan Herland, 18.05.2009:\n> On Sunday 17 May 2009, Junio C Hamano wrote:\n> > [Will merge to \"master\" soon]\n> >\n> > * ph/submodule-rebase (Fri Apr 24 09:06:38 2009 +1000) 1 commit \n> >  + git-submodule: add support for --rebase.\n> \n> [..]\n> \n> Now, my question should not stop this feature from going into 'master', \n> except for the fact that if we also want to support merge, we should \n> rename the associated config variable:\n> \n> Instead of\n> \n>   submodule.<name>.rebase = true/false (false if unset)\n> \n> we should have something like\n> \n>   submodule.<name>.resolve = checkout/rebase/merge (checkout if unset)\n\nAt least this would be inconsistent with options like\nbranch.<name>.merge and branch.<name>.rebase\n\nMarkus\n"},{"id":"114203","messageId":"200905182355.21645.johan@herland.net","threadId":"19387","inReplyTo":"200905182140.29953.markus.heidelberg@web.de","subject":"Re: What's cooking in git.git (May 2009, #02; Sun, 17)","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2009-05-18T21:55:21Z","receivedAt":"2009-05-18T21:55:21Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Monday 18 May 2009, Markus Heidelberg wrote:\n> Johan Herland, 18.05.2009:\n> > On Sunday 17 May 2009, Junio C Hamano wrote:\n> > > [Will merge to \"master\" soon]\n> > >\n> > > * ph/submodule-rebase (Fri Apr 24 09:06:38 2009 +1000) 1 commit\n> > >  + git-submodule: add support for --rebase.\n> >\n> > [..]\n> >\n> > Now, my question should not stop this feature from going into 'master',\n> > except for the fact that if we also want to support merge, we should\n> > rename the associated config variable:\n> >\n> > Instead of\n> >\n> >   submodule.<name>.rebase = true/false (false if unset)\n> >\n> > we should have something like\n> >\n> >   submodule.<name>.resolve = checkout/rebase/merge (checkout if unset)\n>\n> At least this would be inconsistent with options like\n> branch.<name>.merge and branch.<name>.rebase\n\nNo. We cannot \"reuse\" the branch.<name>.merge/rebase semantics in this case: \nbranch.<name>.merge takes a remote branch name to merge with, while \nsubmodule.<name>.merge needs no such name (the merge is well-specified \nwithout that extra name: the new submodule commit is merged into the \nsubmodule's current branch). Thus, submodule.<name>.merge is reduced to a \nsimple bool indicating whether or not we should merge. At this point, \nhowever, it is not only inconsistent with branch.<name>.merge, it also \ndirectly conflicts with submodule.<name>.rebase (they cannot both be \"true\" \nsimultaneously). They should therefore be collapsed into one tri-state \nconfig variable set to either 'rebase', 'merge' or 'false'/unset (which \ntriggers the default 'checkout' behaviour). This is pretty much what I \npropose above.\n\nAfter some thinking, I don't like my original name submodule.<name>.resolve, \nsince \".resolve\" sounds more like a merge strategy or conflict resolution \nmethod, than a \"how to deal with submodule update\" choice. I propose \nsubmodule.<name>.update instead.\n\n\n...Johan\n\n-- \nJohan Herland, <johan@herland.net>\nwww.herland.net\n"},{"id":"114218","messageId":"200905190235.34720.johan@herland.net","threadId":"19387","inReplyTo":"200905182355.21645.johan@herland.net","subject":"[PATCH] git-submodule: add support for --merge.","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2009-05-19T00:35:34Z","receivedAt":"2009-05-19T00:35:34Z","isPatch":true,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"'git submodule update --merge' merges the commit referenced by the\nsuperproject into your local branch, instead of checking it out on\na detached HEAD.\n\nAs evidenced by the addition of \"git submodule update --rebase\", it\nis useful to provide alternatives to the default 'checkout' behaviour\nof \"git submodule update\". Another such alternative is, when updating\na submodule to a new commit, to merge that commit into the current\nbranch. This is useful in workflows where you cannot use --rebase,\nbecause you have downstream people working on top of your submodule\nbranch, and you don't want to disrupt their work with a rebase, but\nyou still want to update your submodule from its upstream.\n\nConfig variables: The --rebase patch added submodule.<name>.rebase\nfor turning on --rebase by default for a given submodule. However,\na similar submodule.<name>.merge variable cannot be added since it\nwould conflict with submodule.<name>.rebase (they cannot both be\ntrue). This patch therefore replaces submodule.<name>.rebase with\nsubmodule.<name>.update, which can be set to the following values:\n\n- 'checkout': This specifies the default behaviour in which \"git\n  submodule update\" checks out the new commit to a detached HEAD.\n  Leaving submodule.<name>.update unset also causes this behaviour.\n\n- 'rebase': This specifies the --rebase behaviour (and thus replaces\n  submodule.<name>.rebase == true), where the local branch in the\n  submodule is rebased onto the new commit.\n\n- 'merge': This specifies the new --merge behaviour in which the new\n  commit is merged into the submodule's local branch.\n\nSigned-off-by: Johan Herland <johan@herland.net>\n---\n\nHere's a patch implementing my suggestion. I have chosen to avoid\nbackwards-compatibility for the submodule.<name>.rebase config\nvariable, since it is not yet present in a released version.\n\n\nHave fun! :)\n\n...Johan\n\n Documentation/git-submodule.txt |   19 ++++++++--\n Documentation/gitmodules.txt    |   12 +++++-\n git-submodule.sh                |   43 ++++++++++++++--------\n t/t7406-submodule-update.sh     |   76 ++++++++++++++++++++++++++++++++++-----\n 4 files changed, 119 insertions(+), 31 deletions(-)\n\ndiff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt\nindex acd16ac..1cbb181 100644\n--- a/Documentation/git-submodule.txt\n+++ b/Documentation/git-submodule.txt\n@@ -13,7 +13,7 @@ SYNOPSIS\n \t      [--reference <repository>] [--] <repository> <path>\n 'git submodule' [--quiet] status [--cached] [--] [<path>...]\n 'git submodule' [--quiet] init [--] [<path>...]\n-'git submodule' [--quiet] update [--init] [-N|--no-fetch] [--rebase]\n+'git submodule' [--quiet] update [--init] [-N|--no-fetch] [--rebase|--merge]\n \t      [--reference <repository>] [--] [<path>...]\n 'git submodule' [--quiet] summary [--summary-limit <n>] [commit] [--] [<path>...]\n 'git submodule' [--quiet] foreach <command>\n@@ -115,8 +115,9 @@ init::\n update::\n \tUpdate the registered submodules, i.e. clone missing submodules and\n \tcheckout the commit specified in the index of the containing repository.\n-\tThis will make the submodules HEAD be detached unless '--rebase' is\n-\tspecified or the key `submodule.$name.rebase` is set to `true`.\n+\tThis will make the submodules HEAD be detached unless '--rebase' or\n+\t'--merge' is specified or the key `submodule.$name.update` is set to\n+\t`rebase` or `merge`.\n +\n If the submodule is not yet initialized, and you just want to use the\n setting as stored in .gitmodules, you can automatically initialize the\n@@ -186,7 +187,17 @@ OPTIONS\n \tsuperproject. If this option is given, the submodule's HEAD will not\n \tbe detached. If a a merge failure prevents this process, you will have\n \tto resolve these failures with linkgit:git-rebase[1].\n-\tIf the key `submodule.$name.rebase` is set to `true`, this option is\n+\tIf the key `submodule.$name.update` is set to `rebase`, this option is\n+\timplicit.\n+\n+--merge::\n+\tThis option is only valid for the update command.\n+\tMerge the commit recorded in the superproject into the current branch\n+\tof the submodule. If this option is given, the submodule's HEAD will\n+\tnot be detached. If a merge failure prevents this process, you will\n+\thave to resolve the resulting conflicts within the submodule with the\n+\tusual conflict resolution tools.\n+\tIf the key `submodule.$name.update` is set to `merge`, this option is\n \timplicit.\n \n --reference <repository>::\ndiff --git a/Documentation/gitmodules.txt b/Documentation/gitmodules.txt\nindex 7c22c40..5daf750 100644\n--- a/Documentation/gitmodules.txt\n+++ b/Documentation/gitmodules.txt\n@@ -30,8 +30,16 @@ submodule.<name>.path::\n submodule.<name>.url::\n \tDefines an url from where the submodule repository can be cloned.\n \n-submodule.<name>.rebase::\n-\tDefines that the submodule should be rebased by default.\n+submodule.<name>.update::\n+\tDefines what to do when the submodule is updated by the superproject.\n+\tIf 'checkout' (the default), the new commit specified in the\n+\tsuperproject will be checked out in the submodule on a detached HEAD.\n+\tIf 'rebase', the current branch of the submodule will be rebased onto\n+\tthe commit specified in the superproject. If 'merge', the commit\n+\tspecified in the superproject will be merged into the current branch\n+\tin the submodule.\n+\tThis config option is overridden if 'git submodule update' is given\n+\tthe '--merge' or '--rebase' options.\n \n \n EXAMPLES\ndiff --git a/git-submodule.sh b/git-submodule.sh\nindex bbca183..2a1e73c 100755\n--- a/git-submodule.sh\n+++ b/git-submodule.sh\n@@ -5,7 +5,7 @@\n # Copyright (c) 2007 Lars Hjemli\n \n USAGE=\"[--quiet] [--cached] \\\n-[add [-b branch] <repo> <path>]|[status|init|update [-i|--init] [-N|--no-fetch]|summary [-n|--summary-limit <n>] [<commit>]] \\\n+[add [-b branch] <repo> <path>]|[status|init|update [-i|--init] [-N|--no-fetch] [--rebase|--merge]|summary [-n|--summary-limit <n>] [<commit>]] \\\n [--] [<path>...]|[foreach <command>]|[sync [--] [<path>...]]\"\n OPTIONS_SPEC=\n . git-sh-setup\n@@ -18,7 +18,7 @@ quiet=\n reference=\n cached=\n nofetch=\n-rebase=\n+update=\n \n #\n # print stuff on stdout unless -q was specified\n@@ -311,10 +311,10 @@ cmd_init()\n \t\tgit config submodule.\"$name\".url \"$url\" ||\n \t\tdie \"Failed to register url for submodule path '$path'\"\n \n-\t\ttest true != \"$(git config -f .gitmodules --bool \\\n-\t\t\tsubmodule.\"$name\".rebase)\" ||\n-\t\tgit config submodule.\"$name\".rebase true ||\n-\t\tdie \"Failed to register submodule path '$path' as rebasing\"\n+\t\tupd=\"$(git config -f .gitmodules submodule.\"$name\".update)\"\n+\t\ttest -z \"$upd\" ||\n+\t\tgit config submodule.\"$name\".update \"$upd\" ||\n+\t\tdie \"Failed to register update mode for submodule path '$path'\"\n \n \t\tsay \"Submodule '$name' ($url) registered for path '$path'\"\n \tdone\n@@ -345,7 +345,11 @@ cmd_update()\n \t\t\t;;\n \t\t-r|--rebase)\n \t\t\tshift\n-\t\t\trebase=true\n+\t\t\tupdate=\"rebase\"\n+\t\t\t;;\n+\t\t-m|--merge)\n+\t\t\tshift\n+\t\t\tupdate=\"merge\"\n \t\t\t;;\n \t\t--reference)\n \t\t\tcase \"$2\" in '') usage ;; esac\n@@ -379,7 +383,7 @@ cmd_update()\n \tdo\n \t\tname=$(module_name \"$path\") || exit\n \t\turl=$(git config submodule.\"$name\".url)\n-\t\trebase_module=$(git config --bool submodule.\"$name\".rebase)\n+\t\tupdate_module=$(git config submodule.\"$name\".update)\n \t\tif test -z \"$url\"\n \t\tthen\n \t\t\t# Only mention uninitialized submodules when its\n@@ -400,9 +404,9 @@ cmd_update()\n \t\t\tdie \"Unable to find current revision in submodule path '$path'\"\n \t\tfi\n \n-\t\tif test true = \"$rebase\"\n+\t\tif ! test -z \"$update\"\n \t\tthen\n-\t\t\trebase_module=true\n+\t\t\tupdate_module=$update\n \t\tfi\n \n \t\tif test \"$subsha1\" != \"$sha1\"\n@@ -420,16 +424,23 @@ cmd_update()\n \t\t\t\tdie \"Unable to fetch in submodule path '$path'\"\n \t\t\tfi\n \n-\t\t\tif test true = \"$rebase_module\"\n-\t\t\tthen\n-\t\t\t\tcommand=\"git-rebase\"\n+\t\t\tcase \"$update_module\" in\n+\t\t\trebase)\n+\t\t\t\tcommand=\"git rebase\"\n \t\t\t\taction=\"rebase\"\n \t\t\t\tmsg=\"rebased onto\"\n-\t\t\telse\n-\t\t\t\tcommand=\"git-checkout $force -q\"\n+\t\t\t\t;;\n+\t\t\tmerge)\n+\t\t\t\tcommand=\"git merge\"\n+\t\t\t\taction=\"merge\"\n+\t\t\t\tmsg=\"merged in\"\n+\t\t\t\t;;\n+\t\t\t*)\n+\t\t\t\tcommand=\"git checkout $force -q\"\n \t\t\t\taction=\"checkout\"\n \t\t\t\tmsg=\"checked out\"\n-\t\t\tfi\n+\t\t\t\t;;\n+\t\t\tesac\n \n \t\t\t(unset GIT_DIR; cd \"$path\" && $command \"$sha1\") ||\n \t\t\tdie \"Unable to $action '$sha1' in submodule path '$path'\"\ndiff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh\nindex 3442c05..2d33d9e 100755\n--- a/t/t7406-submodule-update.sh\n+++ b/t/t7406-submodule-update.sh\n@@ -6,7 +6,7 @@\n test_description='Test updating submodules\n \n This test verifies that \"git submodule update\" detaches the HEAD of the\n-submodule and \"git submodule update --rebase\" does not detach the HEAD.\n+submodule and \"git submodule update --rebase/--merge\" does not detach the HEAD.\n '\n \n . ./test-lib.sh\n@@ -76,9 +76,23 @@ test_expect_success 'submodule update --rebase staying on master' '\n \t)\n '\n \n-test_expect_success 'submodule update - rebase true in .git/config' '\n+test_expect_success 'submodule update --merge staying on master' '\n+\t(cd super/submodule &&\n+\t  git reset --hard HEAD~1\n+\t) &&\n+\t(cd super &&\n+\t (cd submodule &&\n+\t  compare_head\n+\t ) &&\n+\t git submodule update --merge submodule &&\n+\t cd submodule &&\n+\t compare_head\n+\t)\n+'\n+\n+test_expect_success 'submodule update - rebase in .git/config' '\n \t(cd super &&\n-\t git config submodule.submodule.rebase true\n+\t git config submodule.submodule.update rebase\n \t) &&\n \t(cd super/submodule &&\n \t  git reset --hard HEAD~1\n@@ -93,9 +107,9 @@ test_expect_success 'submodule update - rebase true in .git/config' '\n \t)\n '\n \n-test_expect_success 'submodule update - rebase false in .git/config but --rebase given' '\n+test_expect_success 'submodule update - checkout in .git/config but --rebase given' '\n \t(cd super &&\n-\t git config submodule.submodule.rebase false\n+\t git config submodule.submodule.update checkout\n \t) &&\n \t(cd super/submodule &&\n \t  git reset --hard HEAD~1\n@@ -110,9 +124,43 @@ test_expect_success 'submodule update - rebase false in .git/config but --rebase\n \t)\n '\n \n-test_expect_success 'submodule update - rebase false in .git/config' '\n+test_expect_success 'submodule update - merge in .git/config' '\n \t(cd super &&\n-\t git config submodule.submodule.rebase false\n+\t git config submodule.submodule.update merge\n+\t) &&\n+\t(cd super/submodule &&\n+\t  git reset --hard HEAD~1\n+\t) &&\n+\t(cd super &&\n+\t (cd submodule &&\n+\t  compare_head\n+\t ) &&\n+\t git submodule update submodule &&\n+\t cd submodule &&\n+\t compare_head\n+\t)\n+'\n+\n+test_expect_success 'submodule update - checkout in .git/config but --merge given' '\n+\t(cd super &&\n+\t git config submodule.submodule.update checkout\n+\t) &&\n+\t(cd super/submodule &&\n+\t  git reset --hard HEAD~1\n+\t) &&\n+\t(cd super &&\n+\t (cd submodule &&\n+\t  compare_head\n+\t ) &&\n+\t git submodule update --merge submodule &&\n+\t cd submodule &&\n+\t compare_head\n+\t)\n+'\n+\n+test_expect_success 'submodule update - checkout in .git/config' '\n+\t(cd super &&\n+\t git config submodule.submodule.update checkout\n \t) &&\n \t(cd super/submodule &&\n \t  git reset --hard HEAD^\n@@ -131,9 +179,19 @@ test_expect_success 'submodule init picks up rebase' '\n \t(cd super &&\n \t git config submodule.rebasing.url git://non-existing/git &&\n \t git config submodule.rebasing.path does-not-matter &&\n-\t git config submodule.rebasing.rebase true &&\n+\t git config submodule.rebasing.update rebase &&\n \t git submodule init rebasing &&\n-\t test true = $(git config --bool submodule.rebasing.rebase)\n+\t test \"rebase\" = $(git config submodule.rebasing.update)\n+\t)\n+'\n+\n+test_expect_success 'submodule init picks up merge' '\n+\t(cd super &&\n+\t git config submodule.merging.url git://non-existing/git &&\n+\t git config submodule.merging.path does-not-matter &&\n+\t git config submodule.merging.update merge &&\n+\t git submodule init merging &&\n+\t test \"merge\" = $(git config submodule.merging.update)\n \t)\n '\n \n-- \n1.6.3.rc0.1.gf800\n"},{"id":"114220","messageId":"7vpre5anaz.fsf@alter.siamese.dyndns.org","threadId":"19387","inReplyTo":"200905182355.21645.johan@herland.net","subject":"Re: What's cooking in git.git (May 2009, #02; Sun, 17)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-05-19T01:33:56Z","receivedAt":"2009-05-19T01:33:56Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johan Herland <johan@herland.net> writes:\n\n> After some thinking, I don't like my original name submodule.<name>.resolve, \n> since \".resolve\" sounds more like a merge strategy or conflict resolution \n> method, than a \"how to deal with submodule update\" choice. I propose \n> submodule.<name>.update instead.\n\nSounds like a plan, even though I do not necessarily agree with the idea\nof automatically rebinding what is at the submodule path every time you\nupdate the toplevel project tree.  And from my point of view, \"rebind\" (or\n\"autorebind\") would be more appropriate name than \"update\" (and I would\nprobably set it to \"never\").\n"},{"id":"114235","messageId":"200905190923.33874.johan@herland.net","threadId":"19387","inReplyTo":"7vpre5anaz.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (May 2009, #02; Sun, 17)","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2009-05-19T07:23:33Z","receivedAt":"2009-05-19T07:23:33Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Tuesday 19 May 2009, Junio C Hamano wrote:\n> Johan Herland <johan@herland.net> writes:\n> > After some thinking, I don't like my original name\n> > submodule.<name>.resolve, since \".resolve\" sounds more like a merge\n> > strategy or conflict resolution method, than a \"how to deal with\n> > submodule update\" choice. I propose submodule.<name>.update instead.\n>\n> Sounds like a plan, even though I do not necessarily agree with the idea\n> of automatically rebinding what is at the submodule path every time you\n> update the toplevel project tree.\n\nI agree that in many workflows this does not make sense, but I believe that \n(as with 'git submodule update --rebase') there are some cases where it does \nmake sense, and I see no reason to support one, but not the other.\n\n> And from my point of view, \"rebind\" (or \"autorebind\") would be more\n> appropriate name than \"update\"\n\nFeel free to fix up my patch with whatever the community finds most \nappropriate. Personally, I still like \"update\" better because it determines \nwhat \"happens\" on a git submodule update, but I'm not religious about this.\n\n> (and I would probably set it to \"never\").\n\nThat's perfectly ok. So will I, in most of my repos. But there are cases \n(e.g. in the workflows at $dayjob) where this feature will be very valuable.\n\n\n...Johan\n\n-- \nJohan Herland, <johan@herland.net>\nwww.herland.net\n"},{"id":"114240","messageId":"alpine.DEB.1.00.0905191015560.26154@pacific.mpi-cbg.de","threadId":"19387","inReplyTo":"200905190923.33874.johan@herland.net","subject":"Re: What's cooking in git.git (May 2009, #02; Sun, 17)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-05-19T08:17:29Z","receivedAt":"2009-05-19T08:17:29Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 19 May 2009, Johan Herland wrote:\n\n> On Tuesday 19 May 2009, Junio C Hamano wrote:\n> > Johan Herland <johan@herland.net> writes:\n> > > After some thinking, I don't like my original name \n> > > submodule.<name>.resolve, since \".resolve\" sounds more like a merge \n> > > strategy or conflict resolution method, than a \"how to deal with \n> > > submodule update\" choice. I propose submodule.<name>.update instead.\n> >\n> > Sounds like a plan, even though I do not necessarily agree with the \n> > idea of automatically rebinding what is at the submodule path every \n> > time you update the toplevel project tree.\n> \n> I agree that in many workflows this does not make sense, but I believe \n> that (as with 'git submodule update --rebase') there are some cases \n> where it does make sense, and I see no reason to support one, but not \n> the other.\n\nWe have a _lot_ of obscure things that are not supported by core Git, but \nare _very_ easy to add as _tiny_ add-on scripts by the user, without the \nneed for \"official\" feature support.\n\nJust like this one,\nDscho\n"},{"id":"114243","messageId":"200905191045.39108.johan@herland.net","threadId":"19387","inReplyTo":"alpine.DEB.1.00.0905191015560.26154@pacific.mpi-cbg.de","subject":"Re: What's cooking in git.git (May 2009, #02; Sun, 17)","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2009-05-19T08:45:38Z","receivedAt":"2009-05-19T08:45:38Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Tuesday 19 May 2009, Johannes Schindelin wrote:\n> On Tue, 19 May 2009, Johan Herland wrote:\n> > On Tuesday 19 May 2009, Junio C Hamano wrote:\n> > > Johan Herland <johan@herland.net> writes:\n> > > > After some thinking, I don't like my original name\n> > > > submodule.<name>.resolve, since \".resolve\" sounds more like a\n> > > > merge strategy or conflict resolution method, than a \"how to\n> > > > deal with submodule update\" choice. I propose\n> > > > submodule.<name>.update instead.\n> > >\n> > > Sounds like a plan, even though I do not necessarily agree with\n> > > the idea of automatically rebinding what is at the submodule path\n> > > every time you update the toplevel project tree.\n> >\n> > I agree that in many workflows this does not make sense, but I\n> > believe that (as with 'git submodule update --rebase') there are\n> > some cases where it does make sense, and I see no reason to support\n> > one, but not the other.\n>\n> We have a _lot_ of obscure things that are not supported by core Git,\n> but are _very_ easy to add as _tiny_ add-on scripts by the user,\n> without the need for \"official\" feature support.\n>\n> Just like this one\n\nDoes that mean you're also opposed to 'git submodule update --rebase' \n(which is already in 'next', and is even Signed-off-by yourself)?\n\nI still don't see any reason why one should be added (--rebase), and not \nthe other (--merge).\n\nDropping both would at least be consistent from core Git's POV, but \nfollowing that thread, we should probably also drop \"git pull\" (which \nis just a simple wrapper around \"git fetch\" and \"git merge\"), and maybe \nalso \"git clone\" (which can easily be scripted, using \"git init\", \"git \nremote\", \"git fetch\" and \"git branch\")...\n\n\n...Johan\n\n-- \nJohan Herland, <johan@herland.net>\nwww.herland.net\n"},{"id":"114257","messageId":"alpine.DEB.1.00.0905191348460.4266@intel-tinevez-2-302","threadId":"19387","inReplyTo":"200905191045.39108.johan@herland.net","subject":"Re: What's cooking in git.git (May 2009, #02; Sun, 17)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-05-19T11:53:29Z","receivedAt":"2009-05-19T11:53:29Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 19 May 2009, Johan Herland wrote:\n\n> On Tuesday 19 May 2009, Johannes Schindelin wrote:\n> > On Tue, 19 May 2009, Johan Herland wrote:\n> > > On Tuesday 19 May 2009, Junio C Hamano wrote:\n> > > > Johan Herland <johan@herland.net> writes:\n> > > > > After some thinking, I don't like my original name \n> > > > > submodule.<name>.resolve, since \".resolve\" sounds more like a \n> > > > > merge strategy or conflict resolution method, than a \"how to \n> > > > > deal with submodule update\" choice. I propose \n> > > > > submodule.<name>.update instead.\n> > > >\n> > > > Sounds like a plan, even though I do not necessarily agree with \n> > > > the idea of automatically rebinding what is at the submodule path \n> > > > every time you update the toplevel project tree.\n> > >\n> > > I agree that in many workflows this does not make sense, but I \n> > > believe that (as with 'git submodule update --rebase') there are \n> > > some cases where it does make sense, and I see no reason to support \n> > > one, but not the other.\n> >\n> > We have a _lot_ of obscure things that are not supported by core Git, \n> > but are _very_ easy to add as _tiny_ add-on scripts by the user, \n> > without the need for \"official\" feature support.\n> >\n> > Just like this one\n> \n> Does that mean you're also opposed to 'git submodule update --rebase' \n> (which is already in 'next', and is even Signed-off-by yourself)?\n\nNo, because -- as I said myself already a couple of times -- I can see \nthis supporting a common workflow.\n\n> I still don't see any reason why one should be added (--rebase), and not \n> the other (--merge).\n\nWhen you rebase, you see your personal stuff (i.e. stuff that you do not \nwant to submit, or not in its current form, or that you submitted and it \nwaits for inclusion) on top of things right away.\n\nIn contrast, if you merge, you will have a different state from the \nupstream _forever_.  Even if your stuff gets included.\n\nNeedless to say, I do not see much use for the latter case, but tons for \nthe former.\n\n> Dropping both would at least be consistent from core Git's POV, but \n> following that thread, we should probably also drop \"git pull\" (which is \n> just a simple wrapper around \"git fetch\" and \"git merge\"), and maybe \n> also \"git clone\" (which can easily be scripted, using \"git init\", \"git \n> remote\", \"git fetch\" and \"git branch\")...\n\nI will not bother to comment on this.\n\nCiao,\nDscho\n"},{"id":"114260","messageId":"200905191526.40471.johan@herland.net","threadId":"19387","inReplyTo":"alpine.DEB.1.00.0905191348460.4266@intel-tinevez-2-302","subject":"Re: git submodule update --merge (Was: What's cooking in git.git (May 2009, #02; Sun, 17))","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2009-05-19T13:26:40Z","receivedAt":"2009-05-19T13:26:40Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Tuesday 19 May 2009, Johannes Schindelin wrote:\n> On Tue, 19 May 2009, Johan Herland wrote:\n> > On Tuesday 19 May 2009, Johannes Schindelin wrote:\n> > > On Tue, 19 May 2009, Johan Herland wrote:\n> > > > [git submodule update --merge]\n> > >\n> > > We have a _lot_ of obscure things that are not supported by core\n> > > Git, but are _very_ easy to add as _tiny_ add-on scripts by the\n> > > user, without the need for \"official\" feature support.\n> > >\n> > > Just like this one\n> >\n> > Does that mean you're also opposed to 'git submodule update\n> > --rebase' (which is already in 'next', and is even Signed-off-by\n> > yourself)?\n>\n> No, because -- as I said myself already a couple of times -- I can\n> see this supporting a common workflow.\n>\n> > I still don't see any reason why one should be added (--rebase),\n> > and not the other (--merge).\n>\n> When you rebase, you see your personal stuff (i.e. stuff that you do\n> not want to submit, or not in its current form, or that you submitted\n> and it waits for inclusion) on top of things right away.\n\nBut if there are developers downstream whose work is based on your \nsubmodule branch, the rebase will disrupt _their_ work, in the same way \nthat rebasing any other public branch would disrupt people's work.\n\n> In contrast, if you merge, you will have a different state from the\n> upstream _forever_.  Even if your stuff gets included.\n\nCorrect, but there are cases where reconciliation with the upstream repo \nis less important than not disrupting downstream developers (see \nbelow).\n\n> Needless to say, I do not see much use for the latter case, but tons\n> for the former.\n\nI fully agree that for a regular downstream (or \"leaf\") developer, there \nis not much use for git submodule rebase --merge.\n\nBut not all developers fit nicely into your scenario above. Please \nconsider the following scenario (loosely based on the setup at my \n$dayjob):\n\n1. There is a collection of \"core\" repositories that provide common \nplatform-independent functionality that is useful to several projects.\n\n2. There is a group of \"core\" developers that work directly on \nthe \"core\" repos in #1. These developers are not much concerned with \nsubmodule functionality at all.\n\n3. There are multiple projects that each have their own project \nsuper-repo, which contains a set of submodules. Most of these \nsubmodules are clones of the \"core\" repos in #1.\n\n4. Each project has a group of developers that work on that project. \nThese developers clone the project super-repo in #3, and do their work, \nboth directly in the super-repo, and within the submodules. Their \nchanges (both in the super-repo and its submodules), are pushed back \ninto the shared project repos (i.e. the project super-repo, and the \nproject's clones of the \"core\" repos). The project developers will \ntypically use \"git submodule update --rebase\" to keep their own \nunfinished changes on top of submodule updates.\n\n5. Finally, there is the last group of developers, in between the two \nother groups - call them \"branch managers\" or \"integration developers\". \nThese developers are responsible for synchronizing the work done by the \ndownstream project developers (#4) and the work done by the \nupstream \"core\" developers (#2):\n\na) Some of the changes done by the project developers are useful to \n_all_ projects using that \"core\" module, and are sent as patches to \nthe \"core\" developers for inclusion upstream.\n\nb) Some changes are NOT useful to the upstream project, and are kept on \nthe project-specific branch of the submodule.\n\nNow, consider what happens when a new version of a \"core\" module (#1) is \nreleased/published: The new version contains general improvements to \nthat module, and all projects that use the module should upgrade to the \nnew version. The integration developers (#5) for a given project is \nresponsible for this upgrade. How are they going to do the upgrade \nwithout disrupting the work of the project developers (#4)?\n\n- They obviously cannot use the default \"git submodule update\", since \nthat would lose all project-specific changes (see b), and it would also \ndisrupt the downstream project developers.\n\n- Using \"git submodule update --rebase\" is certainly better (they don't \nlose the project-specific changes), but they still rebase the project \nbranch (which disrupts the downstream project developers).\n\nTherefore, the straightforward solution is to merge the new upstream \nversion into the existing project branch. This preserves the \nproject-specific changes, AND it does not disrupt the downstream \ndevelopers.\n\nHence, support for \"git submodule update --merge\" is a very welcome \nfeature for these integration developers.\n\n\nI understand that the above scenario is not common in the free software \nworld, but I believe it is much more common in an enterprise/company \nsetting. Therefore, the support of such workflows is important to \ncompanies that are currently considering (or have already chosen) Git. \nI believe there is value in supporting such workflows, especially when \ndoing so is as straightforward as my patch shows.\n\n\nThanks for your attention,\n\n...Johan\n\n-- \nJohan Herland, <johan@herland.net>\nwww.herland.net\n"},{"id":"114663","messageId":"200905251359.37619.johan@herland.net","threadId":"19387","inReplyTo":"200905191526.40471.johan@herland.net","subject":"Re: git submodule update --merge (Was: What's cooking in git.git (May 2009, #02; Sun, 17))","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2009-05-25T11:59:37Z","receivedAt":"2009-05-25T11:59:37Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Tuesday 19 May 2009, Johan Herland wrote:\n> On Tuesday 19 May 2009, Johannes Schindelin wrote:\n> > On Tue, 19 May 2009, Johan Herland wrote:\n> > > I still don't see any reason why one should be added (--rebase),\n> > > and not the other (--merge).\n> >\n> > When you rebase, you see your personal stuff (i.e. stuff that you\n> > do not want to submit, or not in its current form, or that you\n> > submitted and it waits for inclusion) on top of things right away.\n>\n> But if there are developers downstream whose work is based on your\n> submodule branch, the rebase will disrupt _their_ work, in the same\n> way that rebasing any other public branch would disrupt people's\n> work.\n>\n> > In contrast, if you merge, you will have a different state from the\n> > upstream _forever_.  Even if your stuff gets included.\n>\n> Correct, but there are cases where reconciliation with the upstream\n> repo is less important than not disrupting downstream developers (see\n> below).\n>\n> > Needless to say, I do not see much use for the latter case, but\n> > tons for the former.\n>\n> I fully agree that for a regular downstream (or \"leaf\") developer,\n> there is not much use for git submodule rebase --merge.\n>\n> But not all developers fit nicely into your scenario above.\n> \n> [Workflow description in which \"git submodule update --merge\" would\n>  be a helpful addition]\n>\n> I understand that the above scenario is not common in the free\n> software world, but I believe it is much more common in an\n> enterprise/company setting. Therefore, the support of such workflows\n> is important to companies that are currently considering (or have\n> already chosen) Git. I believe there is value in supporting such\n> workflows, especially when doing so is as straightforward as my patch\n> shows.\n\nI haven't received any replies to my attempt to describe the context in \nwhich \"git submodule update --merge\" is useful. A hint as to whether my \nargument is valid, or just crap, would be nice.\n\nIn any case, even if we don't include \"git submodule update --merge\", \ncould we _please_ consider changing the associated config variable from\n\n  submodule.<name>.rebase = true/false (false if unset)\n\nto something like\n\n  submodule.<name>.update = checkout/rebase (checkout if unset)\n\nor (Junio's suggestion)\n\n  submodule.<name>.rebind = never/rebase (never if unset)\n\nso that we at least have the _option_ of adding other alternatives in \nthe future?\n\n\nHave fun! :)\n\n...Johan\n\n-- \nJohan Herland, <johan@herland.net>\nwww.herland.net\n"},{"id":"114683","messageId":"7vmy91vxqc.fsf@alter.siamese.dyndns.org","threadId":"19387","inReplyTo":"200905251359.37619.johan@herland.net","subject":"Re: git submodule update --merge","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-05-25T18:33:31Z","receivedAt":"2009-05-25T18:33:31Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johan Herland <johan@herland.net> writes:\n\n> I haven't received any replies to my attempt to describe the context in \n> which \"git submodule update --merge\" is useful. A hint as to whether my \n> argument is valid, or just crap, would be nice.\n\nFWIW, I didn't find \"rebase makes sense but merge doesn't\" argument very\nconvincing to begin with.  Because the configuration variable is about\n\"update\" action, I agree it makes sense to do\n\n>   submodule.<name>.update = checkout/rebase (checkout if unset)\n\nfrom the UI standpoint.\n\nI do not know what the sensible repertoire of options nor what the default\nshould be, though.  That's up to the submodule using people to sort out.\n"},{"id":"114685","messageId":"alpine.DEB.1.00.0905252053070.4288@intel-tinevez-2-302","threadId":"19387","inReplyTo":"7vmy91vxqc.fsf@alter.siamese.dyndns.org","subject":"Re: git submodule update --merge","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-05-25T18:57:28Z","receivedAt":"2009-05-25T18:57:28Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 25 May 2009, Junio C Hamano wrote:\n\n> Johan Herland <johan@herland.net> writes:\n> \n> > I haven't received any replies to my attempt to describe the context \n> > in which \"git submodule update --merge\" is useful. A hint as to \n> > whether my argument is valid, or just crap, would be nice.\n> \n> FWIW, I didn't find \"rebase makes sense but merge doesn't\" argument very\n> convincing to begin with.\n\nWell, that is probably because you are not forced by me to use submodules.\n\nBecause in the project I use submodules most heavily, there is one \nrecurring theme: you cannot push to the submodules.  And by \"you\" I mean \n\"a regular user\".\n\nSo virtually all you do in these submodules cannot be pushed at all.  It \nhas to be submitted to the respective submodule maintainer.\n\nAnd guess what happens in such a case when you set that tentative \"update\" \nvariable to \"merge\"?\n\nExactly.\n\nFWIW I consider any scenario where the average users have push access to \nthe submodule a toy scenario.\n\nThe rebase workflow is very useful in my project, so if it does not go \ninto git.git, I'll just force my users to install a Git compiled from my \ngit tree.\n\nCiao,\nDscho\n"},{"id":"114687","messageId":"32541b130905251204q20b5600fr4486390cc9157f66@mail.gmail.com","threadId":"19387","inReplyTo":"alpine.DEB.1.00.0905252053070.4288@intel-tinevez-2-302","subject":"Re: git submodule update --merge","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2009-05-25T19:04:19Z","receivedAt":"2009-05-25T19:04:19Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Mon, May 25, 2009 at 2:57 PM, Johannes Schindelin\n<Johannes.Schindelin@gmx.de> wrote:\n> Because in the project I use submodules most heavily, there is one\n> recurring theme: you cannot push to the submodules.  And by \"you\" I mean\n> \"a regular user\".\n>\n> So virtually all you do in these submodules cannot be pushed at all.  It\n> has to be submitted to the respective submodule maintainer.\n>\n> And guess what happens in such a case when you set that tentative \"update\"\n> variable to \"merge\"?\n>\n> Exactly.\n>\n> FWIW I consider any scenario where the average users have push access to\n> the submodule a toy scenario.\n\nI have the same problem.  Out of curiosity, how do you handle the case\nwhere you really need to make a change to the submodule and let your\nteam members see that change, even though the submodule's upstream is\nslow and/or doesn't accept the patch?\n\nIn that situation, we've had to make local shared mirrors of all the\nsubmodules and point .gitmodules at that.  But that would be your\n\"toy\" scenario - our local users have push access to the submodule.\n\nThanks,\n\nAvery\n"},{"id":"114695","messageId":"alpine.DEB.1.00.0905252149370.4288@intel-tinevez-2-302","threadId":"19387","inReplyTo":"32541b130905251204q20b5600fr4486390cc9157f66@mail.gmail.com","subject":"Re: git submodule update --merge","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-05-25T19:54:09Z","receivedAt":"2009-05-25T19:54:09Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 25 May 2009, Avery Pennarun wrote:\n\n> On Mon, May 25, 2009 at 2:57 PM, Johannes Schindelin\n> <Johannes.Schindelin@gmx.de> wrote:\n> > Because in the project I use submodules most heavily, there is one\n> > recurring theme: you cannot push to the submodules.  And by \"you\" I mean\n> > \"a regular user\".\n> >\n> > So virtually all you do in these submodules cannot be pushed at all.  It\n> > has to be submitted to the respective submodule maintainer.\n> >\n> > And guess what happens in such a case when you set that tentative \"update\"\n> > variable to \"merge\"?\n> >\n> > Exactly.\n> >\n> > FWIW I consider any scenario where the average users have push access to\n> > the submodule a toy scenario.\n> \n> I have the same problem.  Out of curiosity, how do you handle the case\n> where you really need to make a change to the submodule and let your\n> team members see that change, even though the submodule's upstream is\n> slow and/or doesn't accept the patch?\n> \n> In that situation, we've had to make local shared mirrors of all the\n> submodules and point .gitmodules at that.  But that would be your\n> \"toy\" scenario - our local users have push access to the submodule.\n\nHappily enough, our changes were accepted so far.\n\nFor a few branches, though, the patches are not ready to be sent upstream \n(or, from a certain viewpoint, sometimes downstream) yet, so we do have \nlocal forks for those working on that.\n\nNote, however, that even in this case, it is better to use 'rebase' rather \nthan 'merge', for exactly the same (I almost wrote \"unconvincing\") reason \nas before.\n\nCiao,\nDscho\n\nP.S.: in some cases, the submodules' \"upstreams\" are maintained by team \nmembers, but that is very much on purpose.  They are trusted maintainers, \nand there is no reason to let some young and maybe overly energetic \nfriends push to such a trusted repository."},{"id":"114706","messageId":"200905260010.37454.johan@herland.net","threadId":"19387","inReplyTo":"7vmy91vxqc.fsf@alter.siamese.dyndns.org","subject":"Re: git submodule update --merge","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2009-05-25T22:10:37Z","receivedAt":"2009-05-25T22:10:37Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Monday 25 May 2009, Junio C Hamano wrote:\n> Johan Herland <johan@herland.net> writes:\n> > I haven't received any replies to my attempt to describe the context in\n> > which \"git submodule update --merge\" is useful. A hint as to whether my\n> > argument is valid, or just crap, would be nice.\n>\n> FWIW, I didn't find \"rebase makes sense but merge doesn't\" argument very\n> convincing to begin with.  Because the configuration variable is about\n> \"update\" action, I agree it makes sense to do\n>\n> >   submodule.<name>.update = checkout/rebase (checkout if unset)\n>\n> from the UI standpoint.\n>\n> I do not know what the sensible repertoire of options nor what the\n> default should be, though.  That's up to the submodule using people to\n> sort out.\n\nI suggest the default should be whatever \"git submodule update\" does today, \nwhich is what I've called 'checkout' above (i.e. it simply checks out the \nsubmodule commit, which naturally detaches the head).\n\nIf you prefer, I can split my previous patch in two; one that fixes the \nconfig variable, and one that adds \"submodule update --merge\", so that they \ncan be evaluated separately. Hmm?\n\n\nHave fun! :)\n\n...Johan\n\n-- \nJohan Herland, <johan@herland.net>\nwww.herland.net\n"},{"id":"114715","messageId":"200905260048.54625.johan@herland.net","threadId":"19387","inReplyTo":"alpine.DEB.1.00.0905252149370.4288@intel-tinevez-2-302","subject":"Re: git submodule update --merge","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2009-05-25T22:48:54Z","receivedAt":"2009-05-25T22:48:54Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Monday 25 May 2009, Johannes Schindelin wrote:\n> On Mon, 25 May 2009, Avery Pennarun wrote:\n> > On Mon, May 25, 2009 at 2:57 PM, Johannes Schindelin wrote:\n> > > Because in the project I use submodules most heavily, there is one\n> > > recurring theme: you cannot push to the submodules.  And by \"you\" I\n> > > mean \"a regular user\".\n> > >\n> > > So virtually all you do in these submodules cannot be pushed at all.\n> > >  It has to be submitted to the respective submodule maintainer.\n> > >\n> > > And guess what happens in such a case when you set that tentative\n> > > \"update\" variable to \"merge\"?\n> > >\n> > > Exactly.\n> > >\n> > > FWIW I consider any scenario where the average users have push access\n> > > to the submodule a toy scenario.\n\nWell, in the scenario I described earlier, the project developers (your \n\"average users\") _do_ have push access to the submodules. And that scenario \nis certainly not a toy scenario.\n\n> > I have the same problem.  Out of curiosity, how do you handle the case\n> > where you really need to make a change to the submodule and let your\n> > team members see that change, even though the submodule's upstream is\n> > slow and/or doesn't accept the patch?\n> >\n> > In that situation, we've had to make local shared mirrors of all the\n> > submodules and point .gitmodules at that.  But that would be your\n> > \"toy\" scenario - our local users have push access to the submodule.\n\nFor the purposes of this discussion, this is pretty close to the use case I \ndescribed earlier in my scenario as well. Thanks, Avery, for presenting the \nargument in a more readable manner.\n\n> Happily enough, our changes were accepted so far.\n>\n> For a few branches, though, the patches are not ready to be sent upstream\n> (or, from a certain viewpoint, sometimes downstream) yet, so we do have\n> local forks for those working on that.\n>\n> Note, however, that even in this case, it is better to use 'rebase'\n> rather than 'merge', for exactly the same (I almost wrote \"unconvincing\")\n> reason as before.\n\nYes, and I have never argued that your \"average users\" should use 'merge'. \nIndeed I have not argued that 'merge' is suitable for your workflow _at_ \n_all_.\n\nOne of the guiding principles I have learned from earlier submodule \ndiscussions on this list, is that the git submodule commands should NOT \nimpose restrictions on the workflows available to its users. But in this \ncase you are using your own workflow to argue what should, and should not be \npart of the git submodule repertoire. I am arguing that there are \n_different_ workflows, with _different_ requirements where 'merge' would be \na useful addition. Just because you won't ever use it, does not mean that it \nwill not be useful to anybody else.\n\n> P.S.: in some cases, the submodules' \"upstreams\" are maintained by team\n> members, but that is very much on purpose.  They are trusted maintainers,\n> and there is no reason to let some young and maybe overly energetic\n> friends push to such a trusted repository.\n\nDo you argue that protecting these \"young and maybe overly energetic\" \ndevelopers from themselves should be hardcoded into the git submodule \nbehaviour, in such a way that it obscures the availability of other \nalternative submodule workflows?\n\n\nHave fun! :)\n\n...Johan\n\n-- \nJohan Herland, <johan@herland.net>\nwww.herland.net\n"},{"id":"114720","messageId":"20090525231544.GA3999@dingo.bne.redhat.com","threadId":"19387","inReplyTo":"200905251359.37619.johan@herland.net","subject":"Re: git submodule update --merge (Was: What's cooking in git.git (May 2009, #02; Sun, 17))","fromName":"Peter Hutterer","fromEmail":"peter.hutterer@who-t.net","sentAt":"2009-05-25T23:15:46Z","receivedAt":"2009-05-25T23:15:46Z","isPatch":false,"sender":{"key":"peter.hutterer@who-t.net","avatar":"https://avatars.githubusercontent.com/u/1487352?v=4"},"body":"On Mon, May 25, 2009 at 01:59:37PM +0200, Johan Herland wrote:\n> On Tuesday 19 May 2009, Johan Herland wrote:\n> > On Tuesday 19 May 2009, Johannes Schindelin wrote:\n> > > On Tue, 19 May 2009, Johan Herland wrote:\n> > > > I still don't see any reason why one should be added (--rebase),\n> > > > and not the other (--merge).\n> > >\n> > > When you rebase, you see your personal stuff (i.e. stuff that you\n> > > do not want to submit, or not in its current form, or that you\n> > > submitted and it waits for inclusion) on top of things right away.\n> >\n> > But if there are developers downstream whose work is based on your\n> > submodule branch, the rebase will disrupt _their_ work, in the same\n> > way that rebasing any other public branch would disrupt people's\n> > work.\n> >\n> > > In contrast, if you merge, you will have a different state from the\n> > > upstream _forever_.  Even if your stuff gets included.\n> >\n> > Correct, but there are cases where reconciliation with the upstream\n> > repo is less important than not disrupting downstream developers (see\n> > below).\n> >\n> > > Needless to say, I do not see much use for the latter case, but\n> > > tons for the former.\n> >\n> > I fully agree that for a regular downstream (or \"leaf\") developer,\n> > there is not much use for git submodule rebase --merge.\n> >\n> > But not all developers fit nicely into your scenario above.\n> > \n> > [Workflow description in which \"git submodule update --merge\" would\n> >  be a helpful addition]\n> >\n> > I understand that the above scenario is not common in the free\n> > software world, but I believe it is much more common in an\n> > enterprise/company setting. Therefore, the support of such workflows\n> > is important to companies that are currently considering (or have\n> > already chosen) Git. I believe there is value in supporting such\n> > workflows, especially when doing so is as straightforward as my patch\n> > shows.\n> \n> I haven't received any replies to my attempt to describe the context in \n> which \"git submodule update --merge\" is useful. A hint as to whether my \n> argument is valid, or just crap, would be nice.\n> \n> In any case, even if we don't include \"git submodule update --merge\", \n> could we _please_ consider changing the associated config variable from\n> \n>   submodule.<name>.rebase = true/false (false if unset)\n> \n> to something like\n> \n>   submodule.<name>.update = checkout/rebase (checkout if unset)\n> \n> or (Junio's suggestion)\n> \n>   submodule.<name>.rebind = never/rebase (never if unset)\n> \n> so that we at least have the _option_ of adding other alternatives in \n> the future?\n\nI can't really chime in on the merge debate since it's not part of my\nworkflow, but I definitely support the above. Even if we never add any\noptions other than checkout/rebase, it's still better than the prospect of\nhaving possibly conflicting boolean settings in the future.\n\nCheers,\n  Peter\n"}]}