{"thread":{"id":"41122","subject":"[PATCH v2] Remote subtree split --annotate","startedAt":"2016-01-05T03:05:00Z","lastAt":"2016-06-28T11:10:40Z","messageCount":8,"participants":["David Greene","Junio C Hamano","David A. Greene"],"isPatch":true,"patchVersion":2,"patchTotal":null},"messages":[{"id":"275340","messageId":"1451963101-4901-1-git-send-email-greened@obbligato.org","threadId":"41122","inReplyTo":null,"subject":"[PATCH v2] Remote subtree split --annotate","fromName":"David Greene","fromEmail":"greened@obbligato.org","sentAt":"2016-01-05T03:05:00Z","receivedAt":"2016-01-05T03:05:00Z","isPatch":true,"sender":{"key":"greened@obbligato.org","avatar":"https://avatars.githubusercontent.com/u/5291869?v=4"},"body":"Here's a re-roll with the commit message change suggested by\nSebastian.  Please apply.  Thanks!\n"},{"id":"275341","messageId":"1451963101-4901-2-git-send-email-greened@obbligato.org","threadId":"41122","inReplyTo":"1451963101-4901-1-git-send-email-greened@obbligato.org","subject":"[PATCH] contrib/subtree: Remove --annotate","fromName":"David Greene","fromEmail":"greened@obbligato.org","sentAt":"2016-01-05T03:05:01Z","receivedAt":"2016-01-05T03:05:01Z","isPatch":true,"sender":{"key":"greened@obbligato.org","avatar":"https://avatars.githubusercontent.com/u/5291869?v=4"},"body":"From: \"David A. Greene\" <greened@obbligato.org>\n\nRemove --annotate.  This obviates the need for an --unannotate\ncommand, which is both an obvious addition and difficult to define\ndue to the numerous ways one might want to specify how to edit\ncommit messages.  git has other tools more suited to rewriting\ncommit messages and it's easy enough to use them after a subtree\nsplit.  Such tools include filter-branch, rebase -i and\ncommit --amend.\n\nSigned-off-by: David A. Greene <greened@obbligato.org>\n---\n contrib/subtree/git-subtree.sh     |  6 +----\n contrib/subtree/t/t7900-subtree.sh | 50 +++++++++++++++++++-------------------\n 2 files changed, 26 insertions(+), 30 deletions(-)\n\ndiff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh\nindex edf36f8..699c954 100755\n--- a/contrib/subtree/git-subtree.sh\n+++ b/contrib/subtree/git-subtree.sh\n@@ -21,7 +21,6 @@ d             show debug messages\n P,prefix=     the name of the subdir to split out\n m,message=    use the given message as the commit message for the merge commit\n  options for 'split'\n-annotate=     add a prefix to commit message of new commits\n b,branch=     create a new branch from the split subtree\n ignore-joins  ignore prior --rejoin commits\n onto=         try connecting new tree to an existing one\n@@ -43,7 +42,6 @@ command=\n onto=\n rejoin=\n ignore_joins=\n-annotate=\n squash=\n message=\n prefix=\n@@ -87,8 +85,6 @@ while [ $# -gt 0 ]; do\n \tcase \"$opt\" in\n \t\t-q) quiet=1 ;;\n \t\t-d) debug=1 ;;\n-\t\t--annotate) annotate=\"$1\"; shift ;;\n-\t\t--no-annotate) annotate= ;;\n \t\t-b) branch=\"$1\"; shift ;;\n \t\t-P) prefix=\"${1%/}\"; shift ;;\n \t\t-m) message=\"$1\"; shift ;;\n@@ -319,7 +315,7 @@ copy_commit()\n \t\t\tGIT_COMMITTER_NAME \\\n \t\t\tGIT_COMMITTER_EMAIL \\\n \t\t\tGIT_COMMITTER_DATE\n-\t\t(printf \"%s\" \"$annotate\"; cat ) |\n+\t\t(echo -n \"\"; cat ) |\n \t\tgit commit-tree \"$2\" $3  # reads the rest of stdin\n \t) || die \"Can't copy commit $1\"\n }\ndiff --git a/contrib/subtree/t/t7900-subtree.sh b/contrib/subtree/t/t7900-subtree.sh\nindex 751aee3..521c401 100755\n--- a/contrib/subtree/t/t7900-subtree.sh\n+++ b/contrib/subtree/t/t7900-subtree.sh\n@@ -340,8 +340,8 @@ test_expect_success 'split sub dir/ with --rejoin' '\n \t\tcd \"$subtree_test_count\" &&\n \t\tgit fetch ./\"sub proj\" master &&\n \t\tgit subtree merge --prefix=\"sub dir\" FETCH_HEAD &&\n-\t\tsplit_hash=$(git subtree split --prefix=\"sub dir\" --annotate=\"*\") &&\n-\t\tgit subtree split --prefix=\"sub dir\" --annotate=\"*\" --rejoin &&\n+\t\tsplit_hash=$(git subtree split --prefix=\"sub dir\") &&\n+\t\tgit subtree split --prefix=\"sub dir\" --rejoin &&\n \t\tcheck_equal \"$(last_commit_message)\" \"Split '\\''sub dir/'\\'' into commit '\\''$split_hash'\\''\"\n \t)\n  '\n@@ -365,7 +365,7 @@ test_expect_success 'split sub dir/ with --rejoin and --message' '\n \t\tcd \"$subtree_test_count\" &&\n \t\tgit fetch ./\"sub proj\" master &&\n \t\tgit subtree merge --prefix=\"sub dir\" FETCH_HEAD &&\n-\t\tgit subtree split --prefix=\"sub dir\" --message=\"Split & rejoin\" --annotate=\"*\" --rejoin &&\n+\t\tgit subtree split --prefix=\"sub dir\" --message=\"Split & rejoin\" --rejoin &&\n \t\tcheck_equal \"$(last_commit_message)\" \"Split & rejoin\"\n \t)\n '\n@@ -389,8 +389,8 @@ test_expect_success 'split \"sub dir\"/ with --branch' '\n \t\tcd \"$subtree_test_count\" &&\n \t\tgit fetch ./\"sub proj\" master &&\n \t\tgit subtree merge --prefix=\"sub dir\" FETCH_HEAD &&\n-\t\tsplit_hash=$(git subtree split --prefix=\"sub dir\" --annotate=\"*\") &&\n-\t\tgit subtree split --prefix=\"sub dir\" --annotate=\"*\" --branch subproj-br &&\n+\t\tsplit_hash=$(git subtree split --prefix=\"sub dir\") &&\n+\t\tgit subtree split --prefix=\"sub dir\" --branch subproj-br &&\n \t\tcheck_equal \"$(git rev-parse subproj-br)\" \"$split_hash\"\n \t)\n '\n@@ -414,8 +414,8 @@ test_expect_success 'check hash of split' '\n \t\tcd \"$subtree_test_count\" &&\n \t\tgit fetch ./\"sub proj\" master &&\n \t\tgit subtree merge --prefix=\"sub dir\" FETCH_HEAD &&\n-\t\tsplit_hash=$(git subtree split --prefix=\"sub dir\" --annotate=\"*\") &&\n-\t\tgit subtree split --prefix=\"sub dir\" --annotate=\"*\" --branch subproj-br &&\n+\t\tsplit_hash=$(git subtree split --prefix=\"sub dir\") &&\n+\t\tgit subtree split --prefix=\"sub dir\" --branch subproj-br &&\n \t\tcheck_equal \"$(git rev-parse subproj-br)\" \"$split_hash\" &&\n \t\t# Check hash of split\n \t\tnew_hash=$(git rev-parse subproj-br^2) &&\n@@ -500,7 +500,7 @@ test_expect_success 'make sure exactly the right set of files ends up in the sub\n \t\tcd \"$subtree_test_count\" &&\n \t\tgit fetch ./\"sub proj\" master &&\n \t\tgit subtree merge --prefix=\"sub dir\" FETCH_HEAD &&\n-\t\tgit subtree split --prefix=\"sub dir\" --annotate=\"*\" --branch subproj-br --rejoin\n+\t\tgit subtree split --prefix=\"sub dir\" --branch subproj-br --rejoin\n \t) &&\n \ttest_create_commit \"$subtree_test_count/sub proj\" sub3 &&\n \ttest_create_commit \"$subtree_test_count\" \"sub dir\"/main-sub3 &&\n@@ -512,12 +512,12 @@ test_expect_success 'make sure exactly the right set of files ends up in the sub\n \ttest_create_commit \"$subtree_test_count/sub proj\" sub4 &&\n \t(\n \t\tcd \"$subtree_test_count\" &&\n-\t\tgit subtree split --prefix=\"sub dir\" --annotate=\"*\" --branch subproj-br --rejoin\n+\t\tgit subtree split --prefix=\"sub dir\" --branch subproj-br --rejoin\n \t) &&\n \ttest_create_commit \"$subtree_test_count\" \"sub dir\"/main-sub4 &&\n \t(\n \t\tcd \"$subtree_test_count\" &&\n-\t\tgit subtree split --prefix=\"sub dir\" --annotate=\"*\" --branch subproj-br --rejoin\n+\t\tgit subtree split --prefix=\"sub dir\" --branch subproj-br --rejoin\n \t) &&\n \t(\n \t\tcd \"$subtree_test_count/sub proj\" &&\n@@ -566,7 +566,7 @@ test_expect_success 'make sure the subproj *only* contains commits that affect t\n \t\tcd \"$subtree_test_count\" &&\n \t\tgit fetch ./\"sub proj\" master &&\n \t\tgit subtree merge --prefix=\"sub dir\" FETCH_HEAD &&\n-\t\tgit subtree split --prefix=\"sub dir\" --annotate=\"*\" --branch subproj-br --rejoin\n+\t\tgit subtree split --prefix=\"sub dir\" --branch subproj-br --rejoin\n \t) &&\n \ttest_create_commit \"$subtree_test_count/sub proj\" sub3 &&\n \ttest_create_commit \"$subtree_test_count\" \"sub dir\"/main-sub3 &&\n@@ -578,12 +578,12 @@ test_expect_success 'make sure the subproj *only* contains commits that affect t\n \ttest_create_commit \"$subtree_test_count/sub proj\" sub4 &&\n \t(\n \t\tcd \"$subtree_test_count\" &&\n-\t\tgit subtree split --prefix=\"sub dir\" --annotate=\"*\" --branch subproj-br --rejoin\n+\t\tgit subtree split --prefix=\"sub dir\" --branch subproj-br --rejoin\n \t) &&\n \ttest_create_commit \"$subtree_test_count\" \"sub dir\"/main-sub4 &&\n \t(\n \t\tcd \"$subtree_test_count\" &&\n-\t\tgit subtree split --prefix=\"sub dir\" --annotate=\"*\" --branch subproj-br --rejoin\n+\t\tgit subtree split --prefix=\"sub dir\" --branch subproj-br --rejoin\n \t) &&\n \t(\n \t\tcd \"$subtree_test_count/sub proj\" &&\n@@ -631,7 +631,7 @@ test_expect_success 'make sure exactly the right set of files ends up in the mai\n \t\tcd \"$subtree_test_count\" &&\n \t\tgit fetch ./\"sub proj\" master &&\n \t\tgit subtree merge --prefix=\"sub dir\" FETCH_HEAD &&\n-\t\tgit subtree split --prefix=\"sub dir\" --annotate=\"*\" --branch subproj-br --rejoin\n+\t\tgit subtree split --prefix=\"sub dir\" --branch subproj-br --rejoin\n \t) &&\n \ttest_create_commit \"$subtree_test_count/sub proj\" sub3 &&\n \ttest_create_commit \"$subtree_test_count\" \"sub dir\"/main-sub3 &&\n@@ -643,12 +643,12 @@ test_expect_success 'make sure exactly the right set of files ends up in the mai\n \ttest_create_commit \"$subtree_test_count/sub proj\" sub4 &&\n \t(\n \t\tcd \"$subtree_test_count\" &&\n-\t\tgit subtree split --prefix=\"sub dir\" --annotate=\"*\" --branch subproj-br --rejoin\n+\t\tgit subtree split --prefix=\"sub dir\" --branch subproj-br --rejoin\n \t) &&\n \ttest_create_commit \"$subtree_test_count\" \"sub dir\"/main-sub4 &&\n \t(\n \t\tcd \"$subtree_test_count\" &&\n-\t\tgit subtree split --prefix=\"sub dir\" --annotate=\"*\" --branch subproj-br --rejoin\n+\t\tgit subtree split --prefix=\"sub dir\" --branch subproj-br --rejoin\n \t) &&\n \t(\n \t\tcd \"$subtree_test_count/sub proj\" &&\n@@ -704,7 +704,7 @@ test_expect_success 'make sure each filename changed exactly once in the entire\n \t\tcd \"$subtree_test_count\" &&\n \t\tgit fetch ./\"sub proj\" master &&\n \t\tgit subtree merge --prefix=\"sub dir\" FETCH_HEAD &&\n-\t\tgit subtree split --prefix=\"sub dir\" --annotate=\"*\" --branch subproj-br --rejoin\n+\t\tgit subtree split --prefix=\"sub dir\" --branch subproj-br --rejoin\n \t) &&\n \ttest_create_commit \"$subtree_test_count/sub proj\" sub3 &&\n \ttest_create_commit \"$subtree_test_count\" \"sub dir\"/main-sub3 &&\n@@ -716,12 +716,12 @@ test_expect_success 'make sure each filename changed exactly once in the entire\n \ttest_create_commit \"$subtree_test_count/sub proj\" sub4 &&\n \t(\n \t\tcd \"$subtree_test_count\" &&\n-\t\tgit subtree split --prefix=\"sub dir\" --annotate=\"*\" --branch subproj-br --rejoin\n+\t\tgit subtree split --prefix=\"sub dir\" --branch subproj-br --rejoin\n \t) &&\n \ttest_create_commit \"$subtree_test_count\" \"sub dir\"/main-sub4 &&\n \t(\n \t\tcd \"$subtree_test_count\" &&\n-\t\tgit subtree split --prefix=\"sub dir\" --annotate=\"*\" --branch subproj-br --rejoin\n+\t\tgit subtree split --prefix=\"sub dir\" --branch subproj-br --rejoin\n \t) &&\n \t(\n \t\tcd \"$subtree_test_count/sub proj\" &&\n@@ -785,7 +785,7 @@ test_expect_success 'make sure the --rejoin commits never make it into subproj'\n \t\tcd \"$subtree_test_count\" &&\n \t\tgit fetch ./\"sub proj\" master &&\n \t\tgit subtree merge --prefix=\"sub dir\" FETCH_HEAD &&\n-\t\tgit subtree split --prefix=\"sub dir\" --annotate=\"*\" --branch subproj-br --rejoin\n+\t\tgit subtree split --prefix=\"sub dir\" --branch subproj-br --rejoin\n \t) &&\n \ttest_create_commit \"$subtree_test_count/sub proj\" sub3 &&\n \ttest_create_commit \"$subtree_test_count\" \"sub dir\"/main-sub3 &&\n@@ -797,12 +797,12 @@ test_expect_success 'make sure the --rejoin commits never make it into subproj'\n \ttest_create_commit \"$subtree_test_count/sub proj\" sub4 &&\n \t(\n \t\tcd \"$subtree_test_count\" &&\n-\t\tgit subtree split --prefix=\"sub dir\" --annotate=\"*\" --branch subproj-br --rejoin\n+\t\tgit subtree split --prefix=\"sub dir\" --branch subproj-br --rejoin\n \t) &&\n \ttest_create_commit \"$subtree_test_count\" \"sub dir\"/main-sub4 &&\n \t(\n \t\tcd \"$subtree_test_count\" &&\n-\t\tgit subtree split --prefix=\"sub dir\" --annotate=\"*\" --branch subproj-br --rejoin\n+\t\tgit subtree split --prefix=\"sub dir\" --branch subproj-br --rejoin\n \t) &&\n \t(\n \t\tcd \"$subtree_test_count/sub proj\" &&\n@@ -835,7 +835,7 @@ test_expect_success 'make sure no \"git subtree\" tagged commits make it into subp\n \t\tcd \"$subtree_test_count\" &&\n \t\tgit fetch ./\"sub proj\" master &&\n \t\tgit subtree merge --prefix=\"sub dir\" FETCH_HEAD &&\n-\t\tgit subtree split --prefix=\"sub dir\" --annotate=\"*\" --branch subproj-br --rejoin\n+\t\tgit subtree split --prefix=\"sub dir\" --branch subproj-br --rejoin\n \t) &&\n \ttest_create_commit \"$subtree_test_count/sub proj\" sub3 &&\n \ttest_create_commit \"$subtree_test_count\" \"sub dir\"/main-sub3 &&\n@@ -847,12 +847,12 @@ test_expect_success 'make sure no \"git subtree\" tagged commits make it into subp\n \ttest_create_commit \"$subtree_test_count/sub proj\" sub4 &&\n \t(\n \t\tcd \"$subtree_test_count\" &&\n-\t\tgit subtree split --prefix=\"sub dir\" --annotate=\"*\" --branch subproj-br --rejoin\n+\t\tgit subtree split --prefix=\"sub dir\" --branch subproj-br --rejoin\n \t) &&\n \ttest_create_commit \"$subtree_test_count\" \"sub dir\"/main-sub4 &&\n \t(\n \t\tcd \"$subtree_test_count\" &&\n-\t\tgit subtree split --prefix=\"sub dir\" --annotate=\"*\" --branch subproj-br --rejoin\n+\t\tgit subtree split --prefix=\"sub dir\" --branch subproj-br --rejoin\n \t) &&\n \t(\n \t\tcd \"$subtree_test_count/sub proj\" &&\n-- \n2.6.1\n"},{"id":"275387","messageId":"xmqqsi2cj5hu.fsf@gitster.mtv.corp.google.com","threadId":"41122","inReplyTo":"1451963101-4901-2-git-send-email-greened@obbligato.org","subject":"Re: [PATCH] contrib/subtree: Remove --annotate","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-01-05T17:33:33Z","receivedAt":"2016-01-05T17:33:33Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"David Greene <greened@obbligato.org> writes:\n\n> From: \"David A. Greene\" <greened@obbligato.org>\n>\n> Remove --annotate.  This obviates the need for an --unannotate\n> command, which is both an obvious addition and difficult to define\n> due to the numerous ways one might want to specify how to edit\n> commit messages.  git has other tools more suited to rewriting\n> commit messages and it's easy enough to use them after a subtree\n> split.  Such tools include filter-branch, rebase -i and\n> commit --amend.\n\nI do not think that \"there are other ways to do this\" is a good\njustification for removing a feature, unless it can be shown that\nnobody is using it, of course.\n\n> @@ -319,7 +315,7 @@ copy_commit()\n>  \t\t\tGIT_COMMITTER_NAME \\\n>  \t\t\tGIT_COMMITTER_EMAIL \\\n>  \t\t\tGIT_COMMITTER_DATE\n> -\t\t(printf \"%s\" \"$annotate\"; cat ) |\n> +\t\t(echo -n \"\"; cat ) |\n\nI can see that by changing \"printf something\" with 'echo -n \"\"', you\nare making it clear that we are stopping to add that something to\nthe pipeline, but (1) I think the intended effect of running 'echo\n-n' on an empty string is to do nothing, and (2) 'echo -n' is not\nportable [*1*], so this leaves a puzzling code that makes future\nreaders scratch their heads.\n\nI wonder why this cannot be simply the removal of the entire line,\nmaking the resulting implementation more like this:\n\n                git log -1 --pretty=format:... \"$1\" |\n                (\n                        read ... various variables ...\n                        export ... various variables ...\n        -\t\t(printf \"%s\" \"$annotate\"; cat ) |\n                        git commit-tree \"$2\" $3 # reads the rest of stdin\n                ) || die \"cannot copy\"\n\nThat is, just feed the remainder of what is coming directly to the\ncommand?\n\n[Footnote]\n\n*1* http://pubs.opengroup.org/onlinepubs/9699919799/utilities/echo.html\n\nsays \"\"\"Implementations shall not support any options.\"\"\"; '-n'\ncomes from BSD and SysV way of supressing the final newline is to\nend the string with \"\\c\".\n"},{"id":"275404","messageId":"87oaczwvz8.fsf@waller.obbligato.org","threadId":"41122","inReplyTo":"xmqqsi2cj5hu.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH] contrib/subtree: Remove --annotate","fromName":"David A. Greene","fromEmail":"greened@obbligato.org","sentAt":"2016-01-05T21:35:23Z","receivedAt":"2016-01-05T21:35:23Z","isPatch":true,"sender":{"key":"greened@obbligato.org","avatar":"https://avatars.githubusercontent.com/u/5291869?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> David Greene <greened@obbligato.org> writes:\n>\n>> From: \"David A. Greene\" <greened@obbligato.org>\n>>\n>> Remove --annotate.  This obviates the need for an --unannotate\n>> command, which is both an obvious addition and difficult to define\n>> due to the numerous ways one might want to specify how to edit\n>> commit messages.  git has other tools more suited to rewriting\n>> commit messages and it's easy enough to use them after a subtree\n>> split.  Such tools include filter-branch, rebase -i and\n>> commit --amend.\n>\n> I do not think that \"there are other ways to do this\" is a good\n> justification for removing a feature, unless it can be shown that\n> nobody is using it, of course.\n\nI thought you might say that.  :)\n\nI honestly don't know how much it's used.  Obviously someone uses it\nbecause we got a request a couple of years ago for an --unannotate\noption and the ensuing discussion made it clear that that's not a\ntrivial thing.\n\nThe original author is not active anymore so I don't even know why it\nwas added in the first place.  I don't know how to get data about usage.\n\nI'm in the process of getting git-subtree into shape so it can move out\nof contrib into the main area.  Is there a policy for interface changes\nto things in contrib?\n\nThere are a few other things I'm working on that will involve slight\nsemantic changes.  I was planning to do those similarly to how push\nchanged with git 2.0.  Make the current behavior default, emit a warning\nand switch the default after a few releases.  This is all being done to\nmake git-subtree faster, take advanted of new git features since it was\nopriginally written and generally make it more solid and predictable.  I\ncould do the deprecate/remote thing with --annotate if that sounds\nbetter to you.\n\nMy thinking on this change runs as follows:\n\n- --annotate isn't as powerful/flexible as other git commit message\n  rewrite tools.\n\n- Its obvious pair feature --unannotate isn't trivial to do -- people\n  didn't even agree on what it *should* do.  It won't be added any\n  time soon, if at all, so don't advertise something that naturally\n  leads people to request it.\n\n- We really shouldn't lie about the state of this.  --annotate feels\n  tacked-on and incomplete.  It would be best to not have it at all if\n  we can't do it right.\n\n- Better to make the change now before moving out of contrib.\n\nIf you really don't want to get rid of this, I guess that's ok but my\npreference as maintainer is to reduce the feature set to those things\npeople seem to actually regularly use (according to my very unscientific\nGoogle searches) and add features as requested/evaluated.  --annotate\nisn't a huge maintenance burdern but some of those other changes I\nmentioned do in fact significantly reduce the maintenance burden of\ngit-subtree.  I hope I will have some leeway with those, even if they\nchange semantics slightly.\n\n>> @@ -319,7 +315,7 @@ copy_commit()\n>>  \t\t\tGIT_COMMITTER_NAME \\\n>>  \t\t\tGIT_COMMITTER_EMAIL \\\n>>  \t\t\tGIT_COMMITTER_DATE\n>> -\t\t(printf \"%s\" \"$annotate\"; cat ) |\n>> +\t\t(echo -n \"\"; cat ) |\n>\n> I can see that by changing \"printf something\" with 'echo -n \"\"', you\n> are making it clear that we are stopping to add that something to\n> the pipeline, but (1) I think the intended effect of running 'echo\n> -n' on an empty string is to do nothing, and (2) 'echo -n' is not\n> portable [*1*], so this leaves a puzzling code that makes future\n> readers scratch their heads.\n>\n> I wonder why this cannot be simply the removal of the entire line,\n> making the resulting implementation more like this:\n>\n>                 git log -1 --pretty=format:... \"$1\" |\n>                 (\n>                         read ... various variables ...\n>                         export ... various variables ...\n>         -\t\t(printf \"%s\" \"$annotate\"; cat ) |\n>                         git commit-tree \"$2\" $3 # reads the rest of stdin\n>                 ) || die \"cannot copy\"\n>\n> That is, just feed the remainder of what is coming directly to the\n> command?\n\nThat makes sense.  Thanks.\n\n                   -David\n"},{"id":"276186","messageId":"xmqqbn8mish5.fsf@gitster.mtv.corp.google.com","threadId":"41122","inReplyTo":"87oaczwvz8.fsf@waller.obbligato.org","subject":"Re: [PATCH] contrib/subtree: Remove --annotate","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-01-15T18:54:14Z","receivedAt":"2016-01-15T18:54:14Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"greened@obbligato.org (David A. Greene) writes:\n\n> If you really don't want to get rid of this, I guess that's ok but my\n> preference as maintainer is to reduce the feature set to those things\n> people seem to actually regularly use (according to my very unscientific\n> Google searches) and add features as requested/evaluated.  --annotate\n> isn't a huge maintenance burdern but some of those other changes I\n> mentioned do in fact significantly reduce the maintenance burden of\n> git-subtree.  I hope I will have some leeway with those, even if they\n> change semantics slightly.\n\nOK.  It is easy enough to add back when people complains, so...\n\n;-)\n\nThanks.\n"},{"id":"276259","messageId":"87oacjaint.fsf@waller.obbligato.org","threadId":"41122","inReplyTo":"xmqqbn8mish5.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH] contrib/subtree: Remove --annotate","fromName":"David A. Greene","fromEmail":"greened@obbligato.org","sentAt":"2016-01-17T23:30:14Z","receivedAt":"2016-01-17T23:30:14Z","isPatch":true,"sender":{"key":"greened@obbligato.org","avatar":"https://avatars.githubusercontent.com/u/5291869?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> greened@obbligato.org (David A. Greene) writes:\n>\n>> If you really don't want to get rid of this, I guess that's ok but my\n>> preference as maintainer is to reduce the feature set to those things\n>> people seem to actually regularly use (according to my very unscientific\n>> Google searches) and add features as requested/evaluated.  --annotate\n>> isn't a huge maintenance burdern but some of those other changes I\n>> mentioned do in fact significantly reduce the maintenance burden of\n>> git-subtree.  I hope I will have some leeway with those, even if they\n>> change semantics slightly.\n>\n> OK.  It is easy enough to add back when people complains, so...\n>\n> ;-)\n\nThanks.\n\nJust to clarify, what is the expectation of things in contrib?\nBasically the same as other code?\n\n                    -David\n"},{"id":"276265","messageId":"xmqq60yrektk.fsf@gitster.mtv.corp.google.com","threadId":"41122","inReplyTo":"87oacjaint.fsf@waller.obbligato.org","subject":"Re: [PATCH] contrib/subtree: Remove --annotate","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-01-18T01:29:59Z","receivedAt":"2016-01-18T01:29:59Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"greened@obbligato.org (David A. Greene) writes:\n\n> Just to clarify, what is the expectation of things in contrib?\n> Basically the same as other code?\n\nThat heavily depends on your exit strategy.\n\nThe contrib/ area was created back when Git was still young and we\nfelt that it would be beneficial for building the community if\ncontributions to non-core part were also included, encouraging\ndevelopers whose strength are not necessarily in the core part to\nparticipate in various design-level discussions to grow the\ncommunity faster.  Back then, we felt that an obscure standalone\nproject outside Git that would help the Git-life of users have a\nmuch better chance of surviving (and eventually be polished) if we\nhad them bundled, even if the code quality and stability were\nsub-par.\n\nThose young days are long gone.  A standalone tool that aims to help\nusers' Git-life would not just survive but flourish with much more\ncertainty, as long as the tool is good.  We have enough Git users to\nrely on words-of-mouth these days to ensure their success.\n\nThat is why I am very hesitant to add new things to contrib/ these\ndays.  It is very welcome thought that you are working on improving\nsubtree, and eventually moving it out of contrib/.  From the point\nof view of the project, either moving up (to be part of the git core\nproper) or moving out (to become an independent project) is far more\npreferreable than the status quo so far that was staying in contrib/\n(without seeing much changes and slowly but steadily bitrotting).\n\nIf the aspiration is to move up to exit, then the quality and\nstability expectation is basically the same as stuff in core, and we\nneed to strive to keep it stable and high quality.\n\nOn the other hand, if it is exiting by moving out, then Git-core\ndevelopers wouldn't have much say in how you would run your project.\n\nThere are obvious pros-and-cons from various points of view when\nchoosing between moving up and moving out:\n\n * If the integration between \"git subtree\" and the rest of the\n   system is loose (in other words, if your improved version of \"git\n   subtree\" taken from Git 2.8 is dropped into an even newer version\n   of Git 2.13, or an older version like Git 2.4 for that matter, is\n   it expected to work, given the promise of interface stability git\n   core gives you?), there is not much technical reason why it must\n   stay in core.  Of course, your improvements may need to take\n   advantage of improvements on the core side and your new \"git\n   subtree\" may start to require at least Git 2.8, or you may even\n   send patches to the core side to extend and enhance the services\n   you use from the core side, but as long as that happens only\n   occasionally and the dependency does not require lock-step\n   upgrade, we can still call such an integration \"loose\" and moving\n   out will still be a viable possibility.\n\n * If there are many existing users who expect their Git to come\n   with \"git subtree\", unbundling may inconvenience them unless we\n   work closely with Distros, from which most of these users get\n   their Git.\n\n * If you expect the pace of improvement would be far faster than\n   the release schedule of git core (usually a cycle lasts for 8 to\n   12 weeks), moving out would give users a shorter turnaround for\n   getting new and improved \"git subtree\".\n\n * It may even turn out that the users are a lot more tolerant for\n   instability (e.g. removal of rarely used features) in \"git\n   subtree\" than they require the git core proper to be stable, in\n   which case moving up (rather than moving out) to apply the same\n   stability requirement to \"git subtree\" as the rest of the system\n   would be undesirable.\n\n * Moving up and staying in has a big social implication. It gives\n   the version that comes with git core an appearance of being\n   authoritative, even when other people fork the project.\n\n   - This discourages incompatible forks (e.g. when one such fork\n     finds the need to improve the \"metadata\" left by merge\n     operation and used by split, the resulting repository managed\n     by it may no longer usable by other variants of \"git subtree\",\n     and if there is one in-tree \"authoritative\" one that is\n     maintained, such a fork will not get wide adoption without\n     taking compatibility issues into account).\n\n   - On the other hand, if the \"authoritative\" one moves too slowly,\n     that may hinder progress.  An exit by \"moving out\" to become\n     one of the projects that help people's Git-life would result in\n     two or more honestly competing forks of \"git subtree\", which\n     might give users a better end-result after a few years, even\n     though the users who happened to have picked the losing side\n     during these few years may end up having to rewrite the\n     history.\n"},{"id":"290362","messageId":"87vb0td0wq.fsf@waller.obbligato.org","threadId":"41122","inReplyTo":"xmqq60yrektk.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH] contrib/subtree: Remove --annotate","fromName":"David A. Greene","fromEmail":"greened@obbligato.org","sentAt":"2016-06-28T11:10:29Z","receivedAt":"2016-06-28T11:10:40Z","isPatch":true,"sender":{"key":"greened@obbligato.org","avatar":"https://avatars.githubusercontent.com/u/5291869?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> greened@obbligato.org (David A. Greene) writes:\n>\n>> Just to clarify, what is the expectation of things in contrib?\n>> Basically the same as other code?\n>\n> That heavily depends on your exit strategy.\n>\n> If the aspiration is to move up to exit, then the quality and\n> stability expectation is basically the same as stuff in core, and we\n> need to strive to keep it stable and high quality.\n\nThis is the strategy I was planning to pursue.  After extensive\nexperience with git-subtree and some local enhancements I have in\nreal-world work, I am convinced it is a great complementary tool to\ngit-submodule.  It seems odd to me to have one in core and one not.\n\n>  * If the integration between \"git subtree\" and the rest of the\n>    system is loose (in other words, if your improved version of \"git\n>    subtree\" taken from Git 2.8 is dropped into an even newer version\n>    of Git 2.13, or an older version like Git 2.4 for that matter, is\n>    it expected to work, given the promise of interface stability git\n>    core gives you?), there is not much technical reason why it must\n>    stay in core.  Of course, your improvements may need to take\n>    advantage of improvements on the core side and your new \"git\n>    subtree\" may start to require at least Git 2.8, or you may even\n>    send patches to the core side to extend and enhance the services\n>    you use from the core side, but as long as that happens only\n>    occasionally and the dependency does not require lock-step\n>    upgrade, we can still call such an integration \"loose\" and moving\n>    out will still be a viable possibility.\n\nThe enhancements to git-subtree that I have and/or am planning to\nimplement will probably require some changes to core, mostly bugfixes.\nSome of the rebase tests I've sent are heading in that direction.  They\nare problems I discovered while trying to enhance subtree.\n\n>  * If you expect the pace of improvement would be far faster than\n>    the release schedule of git core (usually a cycle lasts for 8 to\n>    12 weeks), moving out would give users a shorter turnaround for\n>    getting new and improved \"git subtree\".\n\nI don't think this is a concern.\n\n>  * It may even turn out that the users are a lot more tolerant for\n>    instability (e.g. removal of rarely used features) in \"git\n>    subtree\" than they require the git core proper to be stable, in\n>    which case moving up (rather than moving out) to apply the same\n>    stability requirement to \"git subtree\" as the rest of the system\n>    would be undesirable.\n\nThat's a fair point.  Besides than removing this --annotate option, I\nanticipate two other potentially breaking changes:\n\n1. Reorganizing metadata to be more useful - The metadata tags are\n   somewhat misleading at the moment and there is additional metadata\n   I've thought about adding.\n\n2. Changing the split algorithm to reuse more of git core -\n   Specifically, I would like to leverage filter-branch to eliminate a\n   bunch of custom code in the split algorithm.  In fact doing so would\n   fix a couple of bugs that have come in.  My intent for this change is\n   to not alter the resulting history from what split does now (except\n   fixing the known bugs) but I can't absolutely guarantee that will be\n   the case until I implement it and try it out.\n\n>  * Moving up and staying in has a big social implication. It gives\n>    the version that comes with git core an appearance of being\n>    authoritative, even when other people fork the project.\n>\n>    - This discourages incompatible forks (e.g. when one such fork\n>      finds the need to improve the \"metadata\" left by merge\n>      operation and used by split, the resulting repository managed\n>      by it may no longer usable by other variants of \"git subtree\",\n>      and if there is one in-tree \"authoritative\" one that is\n>      maintained, such a fork will not get wide adoption without\n>      taking compatibility issues into account).\n\nOther than the metadata rework mentioned above, I personally don't\nanticipate a lot of change to it.  Some ideas have come in from\nelsewhere but I'm not yet convinced they're necessary.  My guess is that\nany future metadata changes will be more for convenience than any core\nfnctionality.  Thus, they could be added in a backward-compatible way.\n\n>    - On the other hand, if the \"authoritative\" one moves too slowly,\n>      that may hinder progress.  An exit by \"moving out\" to become\n>      one of the projects that help people's Git-life would result in\n>      two or more honestly competing forks of \"git subtree\", which\n>      might give users a better end-result after a few years, even\n>      though the users who happened to have picked the losing side\n>      during these few years may end up having to rewrite the\n>      history.\n\nThat's an important point, especially given the time constraints I have.\nDespite all my efforts, work is still taking the majority of my coding\ntime.  That may improve given some other life schedule changes but we\nwill see.  I think I can also justify taking some work time to implement\nthings, since the enhancements are all driven by work needs.\n\nOverall, I think moving subtree to core is the best plan, given\nsubmodule's status and the fact that both tools address similar tasks\nbut do them in fundamentally different ways, leading to useful\ntrade-offs for users.  One of the things I plan to do is add a section\nto subtree's documentation that discusses submodule, subtree and\nreasonable scenarios when one may be a better fit than the other.\n\n                            -David\n"}]}