{"thread":{"id":"11102","subject":"v1.5.4 plans","startedAt":"2007-12-02T22:04:26Z","lastAt":"2007-12-18T20:24:27Z","messageCount":64,"participants":["Junio C Hamano","Jakub Narebski","David Symonds","Pierre Habouzit","Johannes Schindelin","Jeff King","Nicolas Pitre","Russell","Joel Becker","J. Bruce Fields","Mark Fasheh","Martin Langhoff"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"61687","messageId":"7vk5nwu51x.fsf@gitster.siamese.dyndns.org","threadId":"11102","inReplyTo":null,"subject":"v1.5.4 plans","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-12-02T22:04:26Z","receivedAt":"2007-12-02T22:04:26Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Please do not take this as the final decision made by the Emperor, whose\nsubjects now must follow. This is a sanity-check to see if everybody is\non the same page.\n\nI am not the Emperor anyway ;-)\n\nDeprecation and Removal\n-----------------------\n\n * We have already removed svnimport without giving a deprecation notice\n in the release notes of the previous feature release, which was bad.\n Maybe the users will forgive us. Maybe not.\n\n * As discussed on the list, v1.5.4 will ship with the dashed form of\n commands (e.g. \"git-commit\") on users' PATH by default. However we\n will move them outside the normal PATH (exact location needs to be\n decided by checking FHS first, something like /usr/libexec/git-core)\n in v1.5.5 so the release notes to v1.5.4 will declare deprecation\n (see the top of Documentation/RelNotes-1.5.4.txt). We might want to\n keep copies of dashed form Porcelains in /usr/bin but that discussion\n is towards v1.5.5 (post v1.5.4, not now).\n\n * We also will give deprecation warning for the following features and\n commands in the release notes to v1.5.4, and remove them in v1.5.5:\n\n - lost-found (use fsck --lost-found);\n - post-update hook (use post-receive hook);\n - peek-remote (use ls-remote)\n\n\nTopics not in 'master' yet but should be in v1.5.4\n--------------------------------------------------\n\nI think the following should go in, along with what we already have in\n'master':\n\n * git-commit in C (Kristian and others)\n * git-add --patch (Wincent)\n * git-prune --expire (Dscho)\n * git-add --interactive coloring (Dan Zwell)\n * whitespace error classes in diff and patch, using gitattributes (Bruce and me)\n * cvsserver runs post-receive (Michael Witten)\n * git-rebase -i gives chance to rerere (Dscho)\n * git-rebase gives more appropriate help text (Wincent)\n * make refspec matching logic in git-push and git-fetch saner (Steffen Prohaska)\n * work-tree related minor fixes (Nguyen and Dscho)\n * allow update hook to munge commit (Steven Grimm)\n\nI'd like to explicitly exclude topics about the following, although I\nthink there might be worthwhile ones among them to think about in the\nlonger term:\n\n * removing dashed form from the filesystem\n * teaching diff family about fileglob pathspecs\n * making it possible to omit leading paths from diff family output when\n run from a subdirectory\n"},{"id":"61690","messageId":"m33aukwwtx.fsf@roke.D-201","threadId":"11102","inReplyTo":"7vk5nwu51x.fsf@gitster.siamese.dyndns.org","subject":"Re: v1.5.4 plans","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-12-02T22:33:51Z","receivedAt":"2007-12-02T22:33:51Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"\nDoes this mean we should be entering feature freeze?\nOr at least feature freeze for 'master'?\n\n-- \nJakub Narebski\n"},{"id":"61692","messageId":"7v7ijwu3ct.fsf@gitster.siamese.dyndns.org","threadId":"11102","inReplyTo":"m33aukwwtx.fsf@roke.D-201","subject":"Re: v1.5.4 plans","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-12-02T22:41:06Z","receivedAt":"2007-12-02T22:41:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n> Does this mean we should be entering feature freeze?\n> Or at least feature freeze for 'master'?\n\nI said \"these are not in master but should be before v1.5.4\", so master\nis not frozen yet in that sense, but on the other hand, I want to stop\ntaking anything other than I explicitly listed to 'master' from now on.\n\nSo please take it as a \"rfc feature freeze notice\".\n"},{"id":"61699","messageId":"ee77f5c20712021539r3075fc57ld6a4cec737e6043d@mail.gmail.com","threadId":"11102","inReplyTo":"7vk5nwu51x.fsf@gitster.siamese.dyndns.org","subject":"Re: v1.5.4 plans","fromName":"David Symonds","fromEmail":"dsymonds@gmail.com","sentAt":"2007-12-02T23:39:59Z","receivedAt":"2007-12-02T23:39:59Z","isPatch":false,"sender":{"key":"dsymonds@gmail.com","avatar":"https://gravatar.com/avatar/b22f5051cbfc11836e36cf7a690e6cde4e225d835e13295ff98d15c7a9ee3c0f?d=mp&s=160"},"body":"On Dec 3, 2007 9:04 AM, Junio C Hamano wrote:\n> Please do not take this as the final decision made by the Emperor, whose\n> subjects now must follow. This is a sanity-check to see if everybody is\n> on the same page.\n>\n> I am not the Emperor anyway ;-)\n>\n\n> Topics not in 'master' yet but should be in v1.5.4\n> --------------------------------------------------\n>\n> I think the following should go in, along with what we already have in\n> 'master':\n\nCan we add the git-status/git-checkout relative path stuff that's\ncurrently been sitting in 'next'? It would be a good step forward for\nusability.\n\n\nDave.\n"},{"id":"61710","messageId":"7vabosse23.fsf@gitster.siamese.dyndns.org","threadId":"11102","inReplyTo":"ee77f5c20712021539r3075fc57ld6a4cec737e6043d@mail.gmail.com","subject":"Re: v1.5.4 plans","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-12-03T02:32:52Z","receivedAt":"2007-12-03T02:32:52Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"David Symonds\" writes:\n\n> On Dec 3, 2007 9:04 AM, Junio C Hamano wrote:\n>> Please do not take this as the final decision made by the Emperor, whose\n>> subjects now must follow. This is a sanity-check to see if everybody is\n>> on the same page.\n>>\n>> I am not the Emperor anyway ;-)\n>>\n>\n>> Topics not in 'master' yet but should be in v1.5.4\n>> --------------------------------------------------\n>>\n>> I think the following should go in, along with what we already have in\n>> 'master':\n>\n> Can we add the git-status/git-checkout relative path stuff that's\n> currently been sitting in 'next'? It would be a good step forward for\n> usability.\n\nI think checkout from subdirectory with relative was merged on November\n18th to master, with d577bc58. Relative path output for git-status is\npart of the \"git-commit in C\" series, which is planned to go in.\n\nBut now you mention it, I realize that I ran \"git-topic.perl\" (found in\nmy 'todo' branch) without \"--all\" option when I made that list, and I\nmissed stuff fully merged to 'next'. Sorry.\n\nHere is a corrected list.\n\nTopics not in 'master' yet but should be in v1.5.4\n--------------------------------------------------\n\nI think the following should go in, along with what we already have in\n'master':\n\n * git-commit in C (Kristian and others)\n * git-add --patch (Wincent)\n * git-prune --expire (Dscho)\n * git-add --interactive coloring (Dan Zwell)\n * whitespace error classes in diff and patch, using gitattributes (Bruce and me)\n * cvsserver runs post-receive (Michael Witten)\n * git-rebase -i gives chance to rerere (Dscho)\n * git-rebase gives more appropriate help text (Wincent)\n * make refspec matching logic in git-push and git-fetch saner (Steffen Prohaska)\n * work-tree related minor fixes (Nguyen and Dscho)\n * allow update hook to munge commit (Steven Grimm)\n * git-fast-export (Dscho)\n * Add commitdiff to gitweb grep page (Denis Cheng)\n * \"git pull --rebase\" (Dscho)\n * \"git config --get-color\" (me)\n * \"color.diff = true\" means \"auto\" (me)\n * Rewrite \"export VAR=VAL\" to \"VAR=VAL; export VAR\" (Dscho)\n * run correct perl in Documentation (me, waiting for Merlyn)\n"},{"id":"61753","messageId":"20071203090652.GA25154@artemis.madism.org","threadId":"11102","inReplyTo":"ee77f5c20712021539r3075fc57ld6a4cec737e6043d@mail.gmail.com","subject":"[PATCH] Fix quote_path when called with negative length.","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-12-03T09:06:52Z","receivedAt":"2007-12-03T09:06:52Z","isPatch":true,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"When the len passed was -1, relative paths shortening was broken, resulting\nin too long paths.\n\nSigned-off-by: Pierre Habouzit \n---\n\n On Sun, Dec 02, 2007 at 11:39:59PM +0000, David Symonds wrote:\n > On Dec 3, 2007 9:04 AM, Junio C Hamano wrote:\n > > Please do not take this as the final decision made by the Emperor, whose\n > > subjects now must follow. This is a sanity-check to see if everybody is\n > > on the same page.\n > >\n > > I am not the Emperor anyway ;-)\n > >\n > \n > > Topics not in 'master' yet but should be in v1.5.4\n > > --------------------------------------------------\n > >\n > > I think the following should go in, along with what we already have in\n > > 'master':\n > \n > Can we add the git-status/git-checkout relative path stuff that's\n > currently been sitting in 'next'? It would be a good step forward for\n > usability.\n\n Speaking of which, there is this irritating bug in git status that\n let it show too long paths in the first chunk (the \"tracked files\"\n one).\n\n The previous version of the function was avoiding very hard to\n compute \"in\" length, and had quite convoluted code because of that.\n I now compute it at the beginning. The real issue was the:\n\n \t\twhile (prefix[off] && off < len && prefix[off] == in[off])\n\n line, when len is negative, the shortening never happens. I could\n have fixed it using ((len < 0 && in[off]) || off < len), but I\n disliked the resulting code, so I went for this.\n\n -- \n ·O· Pierre Habouzit\n ··O madcoder@debian.org\n OOO http://www.madism.org\n\n wt-status.c | 31 +++++++++++++------------------\n 1 files changed, 13 insertions(+), 18 deletions(-)\n\ndiff --git a/wt-status.c b/wt-status.c\nindex 0e0439f..eb2cbea 100644\n--- a/wt-status.c\n+++ b/wt-status.c\n@@ -84,30 +84,25 @@ static void wt_status_print_trailer(struct wt_status *s)\n static char *quote_path(const char *in, int len,\n \t\tstruct strbuf *out, const char *prefix)\n {\n-\tif (len > 0)\n-\t\tstrbuf_grow(out, len);\n+\tint pos = 0;\n+\n+\tif (len < 0)\n+\t\tlen = strlen(in);\n+\tstrbuf_grow(out, len);\n \tstrbuf_setlen(out, 0);\n \n \tif (prefix) {\n \t\tint off = 0;\n \t\twhile (prefix[off] && off < len && prefix[off] == in[off])\n-\t\t\tif (prefix[off] == '/') {\n-\t\t\t\tprefix += off + 1;\n-\t\t\t\tin += off + 1;\n-\t\t\t\tlen -= off + 1;\n-\t\t\t\toff = 0;\n-\t\t\t} else\n-\t\t\t\toff++;\n-\n-\t\tfor (; *prefix; prefix++)\n-\t\t\tif (*prefix == '/')\n+\t\t\tif (prefix[off++] == '/')\n+\t\t\t\tpos = off;\n+\t\twhile (prefix[off])\n+\t\t\tif (prefix[off++] == '/')\n \t\t\t\tstrbuf_addstr(out, \"../\");\n \t}\n \n-\tfor (; (len < 0 && *in) || len > 0; in++, len--) {\n-\t\tint ch = *in;\n-\n-\t\tswitch (ch) {\n+\tfor (; pos < len; pos++) {\n+\t\tswitch (in[pos]) {\n \t\tcase '\\n':\n \t\t\tstrbuf_addstr(out, \"\\\\n\");\n \t\t\tbreak;\n@@ -115,8 +110,8 @@ static char *quote_path(const char *in, int len,\n \t\t\tstrbuf_addstr(out, \"\\\\r\");\n \t\t\tbreak;\n \t\tdefault:\n-\t\t\tstrbuf_addch(out, ch);\n-\t\t\tcontinue;\n+\t\t\tstrbuf_addch(out, in[pos]);\n+\t\t\tbreak;\n \t\t}\n \t}\n \n-- \n1.5.3.7.2065.g3d18-dirty\n\n"},{"id":"61758","messageId":"7vbq98jdy5.fsf_-_@gitster.siamese.dyndns.org","threadId":"11102","inReplyTo":"7vabosse23.fsf@gitster.siamese.dyndns.org","subject":"Many things pushed out to 'master'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-12-03T10:00:02Z","receivedAt":"2007-12-03T10:00:02Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"I've merged a handful topics that have been cooking in 'next' to\n'master'. Except for a few big topics still in 'next', this brings the\ntip of 'master' much closer to what will become 1.5.4.\n\nAs always has been promised, the tip of 'master' is designed to be more\nstable than any released version without introducing regression, and we\nneed to test how true that is from time to time ;-).\n\nPlease keep the fixes flowing. The next batch will be \"commit in C\" and\n\"add --patch\" series.\n"},{"id":"61771","messageId":"Pine.LNX.4.64.0712031109380.27959@racer.site","threadId":"11102","inReplyTo":"7vbq98jdy5.fsf_-_@gitster.siamese.dyndns.org","subject":"Re: Many things pushed out to 'master'","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-12-03T11:12:34Z","receivedAt":"2007-12-03T11:12:34Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 3 Dec 2007, Junio C Hamano wrote:\n\n> I've merged a handful topics that have been cooking in 'next' to \n> 'master'. Except for a few big topics still in 'next', this brings the \n> tip of 'master' much closer to what will become 1.5.4.\n\nI usually run off next + patches, so I do not know if fast-export already \nmade it to \"master\".\n\nBut I remembered that you requested a mode for signed tags where they \nwould just be copied. I just realised while implementing \"verbatim\" that \n\"ignore\" does just that. Maybe we should rename this mode to \"verbatim\"?\n\nAnd maybe you want to make it the default (even if I think that this will \nresult in more surprise moments than the current mode which aborts).\n\nCiao,\nDscho\n"},{"id":"61790","messageId":"20071203171839.GA19144@coredump.intra.peff.net","threadId":"11102","inReplyTo":"20071203090652.GA25154@artemis.madism.org","subject":"Re: [PATCH] Fix quote_path when called with negative length.","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-12-03T17:18:39Z","receivedAt":"2007-12-03T17:18:39Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Dec 03, 2007 at 10:06:52AM +0100, Pierre Habouzit wrote:\n\n> Speaking of which, there is this irritating bug in git status that\n> let it show too long paths in the first chunk (the \"tracked files\"\n> one).\n\nIt was annoying me, too. See the thread 'quote_path: fix collapsing of\nrelative paths'.\n\n-Peff\n"},{"id":"61796","messageId":"alpine.LFD.0.99999.0712031258460.9605@xanadu.home","threadId":"11102","inReplyTo":"7vk5nwu51x.fsf@gitster.siamese.dyndns.org","subject":"Re: v1.5.4 plans","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-12-03T18:06:49Z","receivedAt":"2007-12-03T18:06:49Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Sun, 2 Dec 2007, Junio C Hamano wrote:\n\n> Please do not take this as the final decision made by the Emperor, whose\n> subjects now must follow. This is a sanity-check to see if everybody is\n> on the same page.\n> \n> I am not the Emperor anyway ;-)\n\nEmperor of the Rising Sun. ;-)\n\n> Deprecation and Removal\n> -----------------------\n> \n> * We also will give deprecation warning for the following features and\n> commands in the release notes to v1.5.4, and remove them in v1.5.5:\n> \n> - lost-found (use fsck --lost-found);\n> - post-update hook (use post-receive hook);\n> - peek-remote (use ls-remote)\n\nTwo things I would like to see in the next version (1.5.5) as well, for \nwhich we could provide early warnings now:\n\n - repack.usedeltabaseoffset defaulting to true\n\n - pack.indexversion defaulting to 2\n\n\nNicolas\n"},{"id":"61803","messageId":"7v1wa3iquj.fsf@gitster.siamese.dyndns.org","threadId":"11102","inReplyTo":"Pine.LNX.4.64.0712031109380.27959@racer.site","subject":"Re: Many things pushed out to 'master'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-12-03T18:19:00Z","receivedAt":"2007-12-03T18:19:00Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> But I remembered that you requested a mode for signed tags where they \n> would just be copied. I just realised while implementing \"verbatim\" that \n> \"ignore\" does just that. Maybe we should rename this mode to \"verbatim\"?\n>\n> And maybe you want to make it the default (even if I think that this will \n> result in more surprise moments than the current mode which aborts).\n\nI did not hear others agreeing with me, so let's respect the original\nauthor's thinking.\n"},{"id":"61807","messageId":"Pine.LNX.4.64.0712031838450.27959@racer.site","threadId":"11102","inReplyTo":"7v1wa3iquj.fsf@gitster.siamese.dyndns.org","subject":"Re: Many things pushed out to 'master'","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-12-03T18:39:14Z","receivedAt":"2007-12-03T18:39:14Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 3 Dec 2007, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > But I remembered that you requested a mode for signed tags where they \n> > would just be copied. I just realised while implementing \"verbatim\" \n> > that \"ignore\" does just that. Maybe we should rename this mode to \n> > \"verbatim\"?\n> >\n> > And maybe you want to make it the default (even if I think that this \n> > will result in more surprise moments than the current mode which \n> > aborts).\n> \n> I did not hear others agreeing with me, so let's respect the original \n> author's thinking.\n\nBut the original author already admitted that the original naming was \nstupid...\n\nCiao,\nDscho\n"},{"id":"61817","messageId":"7vwsrvh4vx.fsf@gitster.siamese.dyndns.org","threadId":"11102","inReplyTo":"Pine.LNX.4.64.0712031838450.27959@racer.site","subject":"Re: Many things pushed out to 'master'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-12-03T20:58:42Z","receivedAt":"2007-12-03T20:58:42Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> Hi,\n>\n> On Mon, 3 Dec 2007, Junio C Hamano wrote:\n>\n>> Johannes Schindelin writes:\n>> \n>> > But I remembered that you requested a mode for signed tags where they \n>> > would just be copied. I just realised while implementing \"verbatim\" \n>> > that \"ignore\" does just that. Maybe we should rename this mode to \n>> > \"verbatim\"?\n>> >\n>> > And maybe you want to make it the default (even if I think that this \n>> > will result in more surprise moments than the current mode which \n>> > aborts).\n>> \n>> I did not hear others agreeing with me, so let's respect the original \n>> author's thinking.\n>\n> But the original author already admitted that the original naming was \n> stupid...\n\nOk, send in updates, please.\n"},{"id":"61820","messageId":"7vsl2jh3rb.fsf@gitster.siamese.dyndns.org","threadId":"11102","inReplyTo":"alpine.LFD.0.99999.0712031258460.9605@xanadu.home","subject":"Re: v1.5.4 plans","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-12-03T21:23:04Z","receivedAt":"2007-12-03T21:23:04Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre writes:\n\n> Two things I would like to see in the next version (1.5.5) as well, for \n> which we could provide early warnings now:\n>\n> - repack.usedeltabaseoffset defaulting to true\n>\n> - pack.indexversion defaulting to 2\n\nI think the former would be sensible, the latter I fear might be a bit\ntoo new but I do not recall the exact version dependency.\n\nCould you draft a patch to ReleaseNotes to explain the consequences of\nthese changes using ordinary user's vocabulary, like:\n\n\tStarting v1.5.5, repack.usedeltabaseoffset will default to true,\n\twhich will give denser packfile (i.e. more efficient storage).\n\tThe downside is that git older than version X will not be able\n\tto use a repository packed using this setting.\n"},{"id":"61829","messageId":"Pine.LNX.4.64.0712032243450.27959@racer.site","threadId":"11102","inReplyTo":"7vwsrvh4vx.fsf@gitster.siamese.dyndns.org","subject":"[PATCH] fast-export: rename the signed tag mode 'ignore' to 'verbatim'","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-12-03T22:44:39Z","receivedAt":"2007-12-03T22:44:39Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"\nThe name 'verbatim' describes much better what this mode does with\nsigned tags. While at it, fix the documentation what it actually\ndoes.\n\nSigned-off-by: Johannes Schindelin \n---\n\n\tOn Mon, 3 Dec 2007, Junio C Hamano wrote:\n\n\t> Johannes Schindelin writes:\n\t> \n\t> > But the original author already admitted that the original \n\t> > naming was stupid...\n\t> \n\t> Ok, send in updates, please.\n\n\tAlright...\n\n Documentation/git-fast-export.txt | 4 ++--\n builtin-fast-export.c | 8 ++++----\n 2 files changed, 6 insertions(+), 6 deletions(-)\n\ndiff --git a/Documentation/git-fast-export.txt b/Documentation/git-fast-export.txt\nindex 073ff7f..fd3d571 100644\n--- a/Documentation/git-fast-export.txt\n+++ b/Documentation/git-fast-export.txt\n@@ -26,14 +26,14 @@ OPTIONS\n \tInsert 'progress' statements every objects, to be shown by\n \tgitlink:git-fast-import[1] during import.\n \n---signed-tags=(ignore|warn|strip|abort)::\n+--signed-tags=(verbatim|warn|strip|abort)::\n \tSpecify how to handle signed tags. Since any transformation\n \tafter the export can change the tag names (which can also happen\n \twhen excluding revisions) the signatures will not match.\n +\n When asking to 'abort' (which is the default), this program will die\n when encountering a signed tag. With 'strip', the tags will be made\n-unsigned, with 'ignore', they will be silently ignored (i.e. not exported)\n+unsigned, with 'verbatim', they will be silently exported\n and with 'warn', they will be exported, but you will see a warning.\n \n \ndiff --git a/builtin-fast-export.c b/builtin-fast-export.c\nindex 72be45d..2136aad 100755\n--- a/builtin-fast-export.c\n+++ b/builtin-fast-export.c\n@@ -23,15 +23,15 @@ static const char *fast_export_usage[] = {\n };\n \n static int progress;\n-static enum { IGNORE, WARN, STRIP, ABORT } signed_tag_mode = ABORT;\n+static enum { VERBATIM, WARN, STRIP, ABORT } signed_tag_mode = ABORT;\n \n static int parse_opt_signed_tag_mode(const struct option *opt,\n \t\t\t\t const char *arg, int unset)\n {\n \tif (unset || !strcmp(arg, \"abort\"))\n \t\tsigned_tag_mode = ABORT;\n-\telse if (!strcmp(arg, \"ignore\"))\n-\t\tsigned_tag_mode = IGNORE;\n+\telse if (!strcmp(arg, \"verbatim\") || !strcmp(arg, \"ignore\"))\n+\t\tsigned_tag_mode = VERBATIM;\n \telse if (!strcmp(arg, \"warn\"))\n \t\tsigned_tag_mode = WARN;\n \telse if (!strcmp(arg, \"strip\"))\n@@ -270,7 +270,7 @@ static void handle_tag(const char *name, struct tag *tag)\n \t\t\t\twarning (\"Exporting signed tag %s\",\n \t\t\t\t\t sha1_to_hex(tag->object.sha1));\n \t\t\t\t/* fallthru */\n-\t\t\tcase IGNORE:\n+\t\t\tcase VERBATIM:\n \t\t\t\tbreak;\n \t\t\tcase STRIP:\n \t\t\t\tmessage_size = signature + 1 - message;\n-- \n1.5.3.7.2120.g1a32\n"},{"id":"61834","messageId":"Pine.LNX.4.64.0712032254150.27959@racer.site","threadId":"11102","inReplyTo":"Pine.LNX.4.64.0712032243450.27959@racer.site","subject":"Re: [PATCH] fast-export: rename the signed tag mode 'ignore' to 'verbatim'","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-12-03T22:56:06Z","receivedAt":"2007-12-03T22:56:06Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 3 Dec 2007, Johannes Schindelin wrote:\n\n> The name 'verbatim' describes much better what this mode does with\n> signed tags. While at it, fix the documentation what it actually\n> does.\n> \n> Signed-off-by: Johannes Schindelin \n> ---\n\nMaybe you want to squash this, too (sorry, I sent the patch too soon, \nalthough the mode \"ignore\" is still accepted, and thus, the test \nsucceeded):\n\n-- snipsnap --\n[PATCH] fast-export: test \"verbatim\", not \"ignore\"\n\nThe signed-tag-mode \"ignore\" was renamed to \"verbatim\", and although we \nstill accept \"ignore\" as a synonym, it is better to test \"verbatim\".\n\nSigned-off-by: Johannes Schindelin \n\n---\n\n t/t9301-fast-export.sh | 4 ++--\n 1 files changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/t/t9301-fast-export.sh b/t/t9301-fast-export.sh\nindex e9c9fe6..f09bfb1 100755\n--- a/t/t9301-fast-export.sh\n+++ b/t/t9301-fast-export.sh\n@@ -106,9 +106,9 @@ test_expect_success 'signed-tags=abort' '\n \n '\n \n-test_expect_success 'signed-tags=ignore' '\n+test_expect_success 'signed-tags=verbatim' '\n \n-\tgit fast-export --signed-tags=ignore sign-your-name > output &&\n+\tgit fast-export --signed-tags=verbatim sign-your-name > output &&\n \tgrep PGP output\n \n '\n"},{"id":"61844","messageId":"c1b8b6670712031648q4c6ed92cx4295042d2a80bf18@mail.gmail.com","threadId":"11102","inReplyTo":"7vk5nwu51x.fsf@gitster.siamese.dyndns.org","subject":"Re: v1.5.4 plans","fromName":"Russell","fromEmail":"russellsteicke@gmail.com","sentAt":"2007-12-04T00:48:04Z","receivedAt":"2007-12-04T00:48:04Z","isPatch":false,"sender":{"key":"russellsteicke@gmail.com","avatar":null},"body":"On Dec 3, 2007 7:04 AM, Junio C Hamano wrote:\n> * We have already removed svnimport without giving a deprecation notice\n> in the release notes of the previous feature release, which was bad.\n> Maybe the users will forgive us. Maybe not.\n\nAh, that explains that. I was in the middle of importing the open2x\nproject into a git repo. It's a large tree which looks like it\nincludes several copies of linux 2.4, and importing is taking several\ndays. Occasionally the svn connection times out or something, and I\njust restart it and it continues. In the middle of that I built and\ninstalled git 1.5.3.7 and was surprised when git-svnimport wasn't\nthere the next time I tried to restart it. Back to 1.5.3.6 for now.\n\nI see there's a thread about using a git-svnimport tree with git-svn,\nso I'll do that.\n\nOh, and you're forgiven. :)\n\n\n\n-- \nVirus found in this message.\n"},{"id":"63077","messageId":"alpine.LFD.0.999999.0712132227090.8467@xanadu.home","threadId":"11102","inReplyTo":"7vsl2jh3rb.fsf@gitster.siamese.dyndns.org","subject":"[PATCH] provide advance warning of some future pack default changes","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-12-14T03:32:36Z","receivedAt":"2007-12-14T03:32:36Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"\nSigned-off-by: Nicolas Pitre \n\n---\n\nOn Mon, 3 Dec 2007, Junio C Hamano wrote:\n\n> Nicolas Pitre writes:\n> \n> > Two things I would like to see in the next version (1.5.5) as well, for \n> > which we could provide early warnings now:\n> >\n> > - repack.usedeltabaseoffset defaulting to true\n> >\n> > - pack.indexversion defaulting to 2\n> \n> I think the former would be sensible, the latter I fear might be a bit\n> too new but I do not recall the exact version dependency.\n> \n> Could you draft a patch to ReleaseNotes to explain the consequences of\n> these changes using ordinary user's vocabulary, like:\n> \n> \tStarting v1.5.5, repack.usedeltabaseoffset will default to true,\n> \twhich will give denser packfile (i.e. more efficient storage).\n> \tThe downside is that git older than version X will not be able\n> \tto use a repository packed using this setting.\n\nHere it is.\n\ndiff --git a/Documentation/RelNotes-1.5.4.txt b/Documentation/RelNotes-1.5.4.txt\nindex 6645565..d6fd3dd 100644\n--- a/Documentation/RelNotes-1.5.4.txt\n+++ b/Documentation/RelNotes-1.5.4.txt\n@@ -43,6 +43,17 @@ Deprecation notices\n * \"git peek-remote\" is deprecated, as \"git ls-remote\" was written in C\n and works for all transports, and will be removed in the future.\n \n+ * From v1.5.5, the repack.usedeltabaseoffset config option will default\n+ to true, which will give denser packfile (i.e. more efficient storage).\n+ The downside is that git older than version 1.4.4 will not be able\n+ to directly use a repository packed using this setting.\n+\n+ * From v1.5.5, the pack.indexversion config option will default to 2,\n+ which is slightly more efficient, and makes repacking more immune to\n+ data corruptions. Git older than version 1.5.2 may revert to version 1\n+ of the pack index with a manual \"git index-pack\" to be able to directly\n+ access corresponding pack files.\n+\n \n Updates since v1.5.3\n --------------------\n"},{"id":"63086","messageId":"7vir31x38p.fsf@gitster.siamese.dyndns.org","threadId":"11102","inReplyTo":"alpine.LFD.0.999999.0712132227090.8467@xanadu.home","subject":"Re: [PATCH] provide advance warning of some future pack default changes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-12-14T05:19:18Z","receivedAt":"2007-12-14T05:19:18Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thanks.\n\nDeprecating versions before 1.5.2 (May 20 2007) feels a bit too quick,\nbut seven month is almost an eternity in git timescale, and by now\nanything older than 1.5.2 can safely be called prehistoric. Will apply.\n"},{"id":"63161","messageId":"m3fxy5qwbq.fsf@roke.D-201","threadId":"11102","inReplyTo":"alpine.LFD.0.999999.0712132227090.8467@xanadu.home","subject":"Re: [PATCH] provide advance warning of some future pack default changes","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-12-14T12:45:23Z","receivedAt":"2007-12-14T12:45:23Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Nicolas Pitre writes:\n\n> + * From v1.5.5, the repack.usedeltabaseoffset config option will default\n> + to true, which will give denser packfile (i.e. more efficient storage).\n> + The downside is that git older than version 1.4.4 will not be able\n> + to directly use a repository packed using this setting.\n> +\n> + * From v1.5.5, the pack.indexversion config option will default to 2,\n> + which is slightly more efficient, and makes repacking more immune to\n> + data corruptions. Git older than version 1.5.2 may revert to version 1\n> + of the pack index with a manual \"git index-pack\" to be able to directly\n> + access corresponding pack files.\n\nWhich means what? Local clone with shortcut (hardlinking and remotes)?\nDumb protocols (http, ftp, rsync)?\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"63162","messageId":"alpine.LFD.0.999999.0712140807280.8467@xanadu.home","threadId":"11102","inReplyTo":"7vir31x38p.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] provide advance warning of some future pack default changes","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-12-14T13:14:42Z","receivedAt":"2007-12-14T13:14:42Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 13 Dec 2007, Junio C Hamano wrote:\n\n> Thanks.\n> \n> Deprecating versions before 1.5.2 (May 20 2007) feels a bit too quick,\n> but seven month is almost an eternity in git timescale, and by now\n> anything older than 1.5.2 can safely be called prehistoric. Will apply.\n\nWell, index version 1 is not gone. It's only the version used by \ndefault that will change, which can be overriden with a config variable.\n\nAnd even if that wasn't done, then any old Git version can just blow \naway the new index and recreate it. So it is not like if you actually \nneeded a recent version of Git to convert the repo back to the old \nformat.\n\nAnd all this will be effective in 1.5.5 which is still a few months \nahead.\n\n\nNicolas\n"},{"id":"63164","messageId":"alpine.LFD.0.999999.0712140836140.8467@xanadu.home","threadId":"11102","inReplyTo":"m3fxy5qwbq.fsf@roke.D-201","subject":"Re: [PATCH] provide advance warning of some future pack default changes","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-12-14T13:38:51Z","receivedAt":"2007-12-14T13:38:51Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Fri, 14 Dec 2007, Jakub Narebski wrote:\n\n> Nicolas Pitre writes:\n> \n> > + * From v1.5.5, the repack.usedeltabaseoffset config option will default\n> > + to true, which will give denser packfile (i.e. more efficient storage).\n> > + The downside is that git older than version 1.4.4 will not be able\n> > + to directly use a repository packed using this setting.\n> > +\n> > + * From v1.5.5, the pack.indexversion config option will default to 2,\n> > + which is slightly more efficient, and makes repacking more immune to\n> > + data corruptions. Git older than version 1.5.2 may revert to version 1\n> > + of the pack index with a manual \"git index-pack\" to be able to directly\n> > + access corresponding pack files.\n> \n> Which means what? Local clone with shortcut (hardlinking and remotes)?\n> Dumb protocols (http, ftp, rsync)?\n\nRight, or simply shared repo over NFS or the like.\n\nThe 1.5.5 release notes will contain a note reminding people to set the \ncorresponding config variables if they wish to retain the legacy \nbehaviors.\n\n\nNicolas\n"},{"id":"63212","messageId":"20071214215206.GB7300@mail.oracle.com","threadId":"11102","inReplyTo":"alpine.LFD.0.999999.0712140836140.8467@xanadu.home","subject":"Re: [PATCH] provide advance warning of some future pack default changes","fromName":"Joel Becker","fromEmail":"joel.becker@oracle.com","sentAt":"2007-12-14T21:52:06Z","receivedAt":"2007-12-14T21:52:06Z","isPatch":true,"sender":{"key":"joel.becker@oracle.com","avatar":null},"body":"On Fri, Dec 14, 2007 at 08:38:51AM -0500, Nicolas Pitre wrote:\n> On Fri, 14 Dec 2007, Jakub Narebski wrote:\n> > Which means what? Local clone with shortcut (hardlinking and remotes)?\n> > Dumb protocols (http, ftp, rsync)?\n> \n> Right, or simply shared repo over NFS or the like.\n> \n> The 1.5.5 release notes will contain a note reminding people to set the \n> corresponding config variables if they wish to retain the legacy \n> behaviors.\n\n\tWe've seen that release notes are a poor way to communicate\nthis. What will happen to a 1.4.4 user when they try to access the\nrepository? Corruption, cryptic error message, or clean \"this repo is\nnot compatible\" message?\n\nJoel\n\n-- \n\n\"Depend on the rabbit's foot if you will, but remember, it didn't\n help the rabbit.\"\n\t- R. E. Shay\n\nJoel Becker\nPrincipal Software Developer\nOracle\nE-mail: joel.becker@oracle.com\nPhone: (650) 506-8127\n"},{"id":"63218","messageId":"alpine.LFD.0.999999.0712141724260.8467@xanadu.home","threadId":"11102","inReplyTo":"20071214215206.GB7300@mail.oracle.com","subject":"Re: [PATCH] provide advance warning of some future pack default changes","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-12-14T22:34:49Z","receivedAt":"2007-12-14T22:34:49Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Fri, 14 Dec 2007, Joel Becker wrote:\n\n> On Fri, Dec 14, 2007 at 08:38:51AM -0500, Nicolas Pitre wrote:\n> > On Fri, 14 Dec 2007, Jakub Narebski wrote:\n> > > Which means what? Local clone with shortcut (hardlinking and remotes)?\n> > > Dumb protocols (http, ftp, rsync)?\n> > \n> > Right, or simply shared repo over NFS or the like.\n> > \n> > The 1.5.5 release notes will contain a note reminding people to set the \n> > corresponding config variables if they wish to retain the legacy \n> > behaviors.\n> \n> \tWe've seen that release notes are a poor way to communicate\n> this. What will happen to a 1.4.4 user when they try to access the\n> repository? Corruption, cryptic error message, or clean \"this repo is\n> not compatible\" message?\n\nThere won't be any corruption.\n\nIn the best case there will be a message along \"x is not supported by \nthis version of Git -- please consider upgrading\". In the worst case \nit'll say \"x is bad\".\n\nBut you know what? repositories with the change affecting 1.4.4 users \nare _already_ out there and no one complained recently. Anyone pushing \nchanges over the native Git protocol is already using deltabaseoffset as \nthe native protocol negociate that capability in its handshake, and \nthese days we keep packs as is on the receiving side when they're large \nenough.\n\n\nNicolas\n"},{"id":"63219","messageId":"20071214223957.GC7300@mail.oracle.com","threadId":"11102","inReplyTo":"alpine.LFD.0.999999.0712141724260.8467@xanadu.home","subject":"Re: [PATCH] provide advance warning of some future pack default changes","fromName":"Joel Becker","fromEmail":"joel.becker@oracle.com","sentAt":"2007-12-14T22:39:57Z","receivedAt":"2007-12-14T22:39:57Z","isPatch":true,"sender":{"key":"joel.becker@oracle.com","avatar":null},"body":"On Fri, Dec 14, 2007 at 05:34:49PM -0500, Nicolas Pitre wrote:\n> On Fri, 14 Dec 2007, Joel Becker wrote:\n> > \tWe've seen that release notes are a poor way to communicate\n> > this. What will happen to a 1.4.4 user when they try to access the\n> > repository? Corruption, cryptic error message, or clean \"this repo is\n> > not compatible\" message?\n> \n> There won't be any corruption.\n> \n> In the best case there will be a message along \"x is not supported by \n> this version of Git -- please consider upgrading\". In the worst case \n> it'll say \"x is bad\".\n\n\tThat would be excellent, especially the former message.\n \n> But you know what? repositories with the change affecting 1.4.4 users \n> are _already_ out there and no one complained recently. Anyone pushing \n\n\tI did, as did people I work with. It's on git-list, even. I'm\npretty sure it corrupted too.\n\nJoel\n\n-- \n\n\"Practice random acts of kindness and senseless acts of beauty.\"\n\n Oh, and don't forget where your towel is.\n\nJoel Becker\nPrincipal Software Developer\nOracle\nE-mail: joel.becker@oracle.com\nPhone: (650) 506-8127\n"},{"id":"63220","messageId":"alpine.LFD.0.999999.0712141744460.8467@xanadu.home","threadId":"11102","inReplyTo":"20071214223957.GC7300@mail.oracle.com","subject":"Re: [PATCH] provide advance warning of some future pack default changes","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-12-14T22:46:14Z","receivedAt":"2007-12-14T22:46:14Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Fri, 14 Dec 2007, Joel Becker wrote:\n\n> On Fri, Dec 14, 2007 at 05:34:49PM -0500, Nicolas Pitre wrote:\n> > But you know what? repositories with the change affecting 1.4.4 users \n> > are _already_ out there and no one complained recently. Anyone pushing \n> \n> \tI did, as did people I work with. It's on git-list, even. I'm\n> pretty sure it corrupted too.\n\nCould you please give me a reference to such message, so to verify that \nwe're actually talking about the same thing?\n\n\nNicolas\n"},{"id":"63227","messageId":"20071215004230.GF7300@mail.oracle.com","threadId":"11102","inReplyTo":"alpine.LFD.0.999999.0712141744460.8467@xanadu.home","subject":"Re: [PATCH] provide advance warning of some future pack default changes","fromName":"Joel Becker","fromEmail":"joel.becker@oracle.com","sentAt":"2007-12-15T00:42:30Z","receivedAt":"2007-12-15T00:42:30Z","isPatch":true,"sender":{"key":"joel.becker@oracle.com","avatar":null},"body":"On Fri, Dec 14, 2007 at 05:46:14PM -0500, Nicolas Pitre wrote:\n> On Fri, 14 Dec 2007, Joel Becker wrote:\n> \n> > On Fri, Dec 14, 2007 at 05:34:49PM -0500, Nicolas Pitre wrote:\n> > > But you know what? repositories with the change affecting 1.4.4 users \n> > > are _already_ out there and no one complained recently. Anyone pushing \n> > \n> > \tI did, as did people I work with. It's on git-list, even. I'm\n> > pretty sure it corrupted too.\n> \n> Could you please give me a reference to such message, so to verify that \n> we're actually talking about the same thing?\n\n\tThe relevant message is:\n\nMessage-ID: <7vveaindgp.fsf@gitster.siamese.dyndns.org>\n\nSee the paragraphs at the bottom. The thread, started by me, begins\nwith:\n\nMessage-ID: <20070910205429.GE27837@tasint.org>\n\nJoel\n\n-- \n\n\"You must remember this:\n A kiss is just a kiss,\n A sigh is just a sigh.\n The fundamental rules apply\n As time goes by.\"\n\nJoel Becker\nPrincipal Software Developer\nOracle\nE-mail: joel.becker@oracle.com\nPhone: (650) 506-8127\n"},{"id":"63228","messageId":"alpine.LFD.0.999999.0712142004480.8467@xanadu.home","threadId":"11102","inReplyTo":"20071215004230.GF7300@mail.oracle.com","subject":"Re: [PATCH] provide advance warning of some future pack default changes","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-12-15T01:08:05Z","receivedAt":"2007-12-15T01:08:05Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Fri, 14 Dec 2007, Joel Becker wrote:\n\n> On Fri, Dec 14, 2007 at 05:46:14PM -0500, Nicolas Pitre wrote:\n> > On Fri, 14 Dec 2007, Joel Becker wrote:\n> > \n> > > On Fri, Dec 14, 2007 at 05:34:49PM -0500, Nicolas Pitre wrote:\n> > > > But you know what? repositories with the change affecting 1.4.4 users \n> > > > are _already_ out there and no one complained recently. Anyone pushing \n> > > \n> > > \tI did, as did people I work with. It's on git-list, even. I'm\n> > > pretty sure it corrupted too.\n> > \n> > Could you please give me a reference to such message, so to verify that \n> > we're actually talking about the same thing?\n> \n> \tThe relevant message is:\n> \n> Message-ID: <7vveaindgp.fsf@gitster.siamese.dyndns.org>\n> \n> See the paragraphs at the bottom. The thread, started by me, begins\n> with:\n> \n> Message-ID: <20070910205429.GE27837@tasint.org>\n\nI don't have such emails in my mail folders anymore.\n\n\nNicolas\n"},{"id":"63230","messageId":"Pine.LNX.4.64.0712150121180.27959@racer.site","threadId":"11102","inReplyTo":"alpine.LFD.0.999999.0712142004480.8467@xanadu.home","subject":"Re: [PATCH] provide advance warning of some future pack default changes","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-12-15T01:21:42Z","receivedAt":"2007-12-15T01:21:42Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 14 Dec 2007, Nicolas Pitre wrote:\n\n> On Fri, 14 Dec 2007, Joel Becker wrote:\n> \n> > On Fri, Dec 14, 2007 at 05:46:14PM -0500, Nicolas Pitre wrote:\n> > > On Fri, 14 Dec 2007, Joel Becker wrote:\n> > > \n> > > > On Fri, Dec 14, 2007 at 05:34:49PM -0500, Nicolas Pitre wrote:\n> > > > > But you know what? repositories with the change affecting 1.4.4 users \n> > > > > are _already_ out there and no one complained recently. Anyone pushing \n> > > > \n> > > > \tI did, as did people I work with. It's on git-list, even. I'm\n> > > > pretty sure it corrupted too.\n> > > \n> > > Could you please give me a reference to such message, so to verify that \n> > > we're actually talking about the same thing?\n> > \n> > \tThe relevant message is:\n> > \n> > Message-ID: <7vveaindgp.fsf@gitster.siamese.dyndns.org>\n> > \n> > See the paragraphs at the bottom. The thread, started by me, begins\n> > with:\n> > \n> > Message-ID: <20070910205429.GE27837@tasint.org>\n> \n> I don't have such emails in my mail folders anymore.\n\nGMane does not seem to have it, either:\n\n\thttp://mid.gmane.org/20070910205429.GE27837@tasint.org\n\nreturns \"No such article\".\n\nCiao,\nDscho\n"},{"id":"63231","messageId":"7vr6hoohqm.fsf@gitster.siamese.dyndns.org","threadId":"11102","inReplyTo":"alpine.LFD.0.999999.0712142004480.8467@xanadu.home","subject":"Re: [PATCH] provide advance warning of some future pack default changes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-12-15T01:43:13Z","receivedAt":"2007-12-15T01:43:13Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre writes:\n\n> On Fri, 14 Dec 2007, Joel Becker wrote:\n>\n>> > Could you please give me a reference to such message, so to verify that \n>> > we're actually talking about the same thing?\n>> \n>> \tThe relevant message is:\n>> \n>> Message-ID: <7vveaindgp.fsf@gitster.siamese.dyndns.org>\n>> \n>> See the paragraphs at the bottom. The thread, started by me, begins\n>> with:\n>> \n>> Message-ID: <20070910205429.GE27837@tasint.org>\n>\n> I don't have such emails in my mail folders anymore.\n\n-- >8 --\n\nDate:\tMon, 10 Sep 2007 13:54:29 -0700\nFrom:\tJoel Becker \nTo:\tgit@vger.kernel.org\nSubject: Remote branches and better documentation\nMessage-ID: <20070910205429.GE27837@tasint.org>\nSender:\tgit-owner@vger.kernel.org\n\nJunio et al,\n\tGit is a fast moving target, so some of this obviously needs a\ngrain of salt. However, I'd like to make a couple of humble suggestions\nand ask one simple question.\n\tFirst, the question: Is there a syntax to git clone that\ncreates the old-style branches? That is, you get all the branches\nlocally, for people that either haven't learned \"git branch -r\" or have\nexisting scripts that expect the branch to exist? I can't find anything\nin the git clone manpage.\n\tThe suggestions are pretty simple. First, when behavior is\nchanged invisibly (as the remote branch stuff was), can we note it in\nthe documentation? I don't mean the ChangeLog, I mean the manpage. I\npersonally already knew about \"branch -r\" because I read this list. A\ncoworker of mine, who just uses git, spent an hour trying to find his\nbranches after a clone with git 1.5. He thought his clone had failed.\nHe read the manpage, and there was no big \"Hey, those of you used to\nthe old behavior, it changed!\". The single sentence about \"remote\ntracking branches\" clearly isn't enough for folks that don't follow the\ndevelopment side. If we're going to take the liberty of changing\nexpected behavior silently, we should be giving it its own section in\nthe manpage.\n\tThe second suggestion is related. When an invisible change has\nmade the repository incompatible with older versions, we should make\nsure that things behave. We had some repositories cloned via 1.4.2. Do\nsome work with 1.5.0.6 (on a different machine), then go back to the\nmachine with 1.4.2, and 1.4.2 doesn't work. In fact, it can mess things\nup. He was doing simple things: pull from Linus, switch branches, etc.\nIf this is going to be incompatible, then the newer stuff should at\nleast warn about it, if not outright prevent 1.4 from running.\n\tThese sorts of things make fast-moving changes workable.\n\nJoel\n\n-- >8 --\n\nDate:\tMon, 10 Sep 2007 19:27:34 -0700\nMessage-ID: <7vveaindgp.fsf@gitster.siamese.dyndns.org>\nSender:\tgit-owner@vger.kernel.org\n\nJoel Becker writes:\n\n> On Tue, Sep 11, 2007 at 02:05:34AM +0200, Wincent Colaiuta wrote:\n>> But that's precisely the group release notes are for; existing users who \n>> need to be informed of any changes to the way things work.\n>\n> \tNo one reads the changelogs of 100 packages updated via \"yum\n> update\". Heck, they don't even see the list of packages. They just\n> switch to a different desktop while it runs.\n\nDistros are not something under my control, so I cannot help you\nmuch there.\n\n> \tThen there's the user that doesn't administer the system. They\n> don't even know the version changed. It Just Breaks, and they don't\n> know why.\n\nThat's a valid concern, but I am not sure how you would want to\naddress that issue. Design constraints are:\n\n - you cannot change the old software that is not updated on the\n user's box;\n\n - you cannot afford to write something to the repository to\n mark the latest version that mucked with the repository every\n time any operation happens;\n\nWe _could_ check presence of $HOME/.knows-git-version-X.Y.Z file\nevery time we run (that's just a single stat(2) call that cannot\nbe too expensive) and if there isn't one, ask the user if he has\nread the release notes and understood the backward compatibility\nissues if there is any, and refuse to run until getting a\nsatisfactory answer.\n\nBut I personally do not think that would be an improvement.\n\nAfter reviewing Release Notes for v1.5.0, I do not think we\ncould have done much better, unfortunately.\n\n As of git v1.5.0 there are some optional features that changes\n the repository to allow data to be stored and transferred more\n efficiently. These features are not enabled by default, as they\n will make the repository unusable with older versions of git.\n Specifically, the available options are:\n\n - There is a configuration variable core.legacyheaders that\n changes the format of loose objects so that they are more\n efficient to pack and to send out of the repository over git\n native protocol, since v1.4.2. However, loose objects\n written in the new format cannot be read by git older than\n that version; people fetching from your repository using\n older clients over dumb transports (e.g. http) using older\n versions of git will also be affected.\n\n To let git use the new loose object format, you have to\n set core.legacyheaders to false.\n\n - Since v1.4.3, configuration repack.usedeltabaseoffset allows\n packfile to be created in more space efficient format, which\n cannot be read by git older than that version.\n\n To let git use the new format for packfiles, you have to\n set repack.usedeltabaseoffset to true.\n\n The above two new features are not enabled by default and you\n have to explicitly ask for them, because they make repositories\n unreadable by older versions of git, and in v1.5.0 we still do\n not enable them by default for the same reason. We will change\n this default probably 1 year after 1.4.2's release, when it is\n reasonable to expect everybody to have new enough version of\n git.\n\n - 'git pack-refs' appeared in v1.4.4; this command allows tags\n to be accessed much more efficiently than the traditional\n 'one-file-per-tag' format. Older git-native clients can\n still fetch from a repository that packed and pruned refs\n (the server side needs to run the up-to-date version of git),\n but older dumb transports cannot. Packing of refs is done by\n an explicit user action, either by use of \"git pack-refs\n --prune\" command or by use of \"git gc\" command.\n\nSo everything was opt in and clearly marked as such. You may\nnot have read it, distros may not have shown it, but then that\nis something we cannot do much about, unfortunately.\n\nI think there was _one_ honest slippage though. Fetching from\n1.5.0 peer by 1.5.0 client could (after doing content\nnegotiation between both ends as a protection measure) create a\npackfile that cannot be read by older 1.4 clients. Obviously\nyou cannot expect that kind of \"protection\" to work across set\nof machines with mixed versions sharing a repository over NFS,\nand that probably is a mistake we can learn from.\n"},{"id":"63232","messageId":"alpine.LFD.0.999999.0712142114400.8467@xanadu.home","threadId":"11102","inReplyTo":"20071215004230.GF7300@mail.oracle.com","subject":"Re: [PATCH] provide advance warning of some future pack default changes","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-12-15T02:23:38Z","receivedAt":"2007-12-15T02:23:38Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Fri, 14 Dec 2007, Joel Becker wrote:\n\n> On Fri, Dec 14, 2007 at 05:46:14PM -0500, Nicolas Pitre wrote:\n> > On Fri, 14 Dec 2007, Joel Becker wrote:\n> > \n> > > On Fri, Dec 14, 2007 at 05:34:49PM -0500, Nicolas Pitre wrote:\n> > > > But you know what? repositories with the change affecting 1.4.4 users \n> > > > are _already_ out there and no one complained recently. Anyone pushing \n> > > \n> > > \tI did, as did people I work with. It's on git-list, even. I'm\n> > > pretty sure it corrupted too.\n> > \n> > Could you please give me a reference to such message, so to verify that \n> > we're actually talking about the same thing?\n> \n> \tThe relevant message is:\n> \n> Message-ID: <7vveaindgp.fsf@gitster.siamese.dyndns.org>\n> \n> See the paragraphs at the bottom. The thread, started by me, begins\n> with:\n> \n> Message-ID: <20070910205429.GE27837@tasint.org>\n\nOK. From those emails Junio forwarded to me, I don't see any case for \nactual _corruptions_. Git does indeed refuse to work with unknown pack \nindex or unknown objects in a pack. Really old versions were not overly \nclueful as to why they refused to work, but they should never corrupt a \npack which, for all purposes, is always read-only anyway.\n\n\nNicolas\n"},{"id":"63468","messageId":"20071217200920.GB19816@mail.oracle.com","threadId":"11102","inReplyTo":"alpine.LFD.0.999999.0712142114400.8467@xanadu.home","subject":"Re: [PATCH] provide advance warning of some future pack default changes","fromName":"Joel Becker","fromEmail":"joel.becker@oracle.com","sentAt":"2007-12-17T20:09:21Z","receivedAt":"2007-12-17T20:09:21Z","isPatch":true,"sender":{"key":"joel.becker@oracle.com","avatar":null},"body":"On Fri, Dec 14, 2007 at 09:23:38PM -0500, Nicolas Pitre wrote:\n> On Fri, 14 Dec 2007, Joel Becker wrote:\n> > \tThe relevant message is:\n> > \n> > Message-ID: <7vveaindgp.fsf@gitster.siamese.dyndns.org>\n> > \n> > See the paragraphs at the bottom. The thread, started by me, begins\n> > with:\n> > \n> > Message-ID: <20070910205429.GE27837@tasint.org>\n> \n> OK. From those emails Junio forwarded to me, I don't see any case for \n> actual _corruptions_. Git does indeed refuse to work with unknown pack \n> index or unknown objects in a pack. Really old versions were not overly \n> clueful as to why they refused to work, but they should never corrupt a \n> pack which, for all purposes, is always read-only anyway.\n\n\tYou may not see a case for actual corruptions, but my coworker\nupdated his tree on a box with 1.5.x, then tried to work on a box with\n1.4.x (I think 1.4.2 back then), and ended up with a tree that was\nunusable. He had to re-clone, and I think he got lucky recovering\npending changes (probably using 1.5.x on the branches with the changes,\nas master was what got broken).\n\tMy point is not that change is always bad, but that we should\nreally look forward to what we're doing, and that \"it's in the release\nnotes\" is not sufficient if an older git gives an incomprehensible error\nor a silent problem. I was responding to the cavalier statement \"well,\nit's in the release notes, so don't worry about older versions\".\n\nJoel\n\n-- \n\n\"Vote early and vote often.\" \n - Al Capone\n\nJoel Becker\nPrincipal Software Developer\nOracle\nE-mail: joel.becker@oracle.com\nPhone: (650) 506-8127\n"},{"id":"63474","messageId":"alpine.LFD.0.999999.0712171517320.8467@xanadu.home","threadId":"11102","inReplyTo":"20071217200920.GB19816@mail.oracle.com","subject":"Re: [PATCH] provide advance warning of some future pack default changes","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-12-17T20:41:24Z","receivedAt":"2007-12-17T20:41:24Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Mon, 17 Dec 2007, Joel Becker wrote:\n\n> On Fri, Dec 14, 2007 at 09:23:38PM -0500, Nicolas Pitre wrote:\n> > On Fri, 14 Dec 2007, Joel Becker wrote:\n> > > \tThe relevant message is:\n> > > \n> > > Message-ID: <7vveaindgp.fsf@gitster.siamese.dyndns.org>\n> > > \n> > > See the paragraphs at the bottom. The thread, started by me, begins\n> > > with:\n> > > \n> > > Message-ID: <20070910205429.GE27837@tasint.org>\n> > \n> > OK. From those emails Junio forwarded to me, I don't see any case for \n> > actual _corruptions_. Git does indeed refuse to work with unknown pack \n> > index or unknown objects in a pack. Really old versions were not overly \n> > clueful as to why they refused to work, but they should never corrupt a \n> > pack which, for all purposes, is always read-only anyway.\n> \n> \tYou may not see a case for actual corruptions, but my coworker\n> updated his tree on a box with 1.5.x, then tried to work on a box with\n> 1.4.x (I think 1.4.2 back then), and ended up with a tree that was\n> unusable. He had to re-clone, and I think he got lucky recovering\n> pending changes (probably using 1.5.x on the branches with the changes,\n> as master was what got broken).\n\nI still claim that there wasn't any corruptions.\n\nJust for fun, just edit some document with Microsoft Office 95, then \nopen the same document with Office 2007 and save it with default \nsettings. Now try to open it back with Office 95. It won't work. \nDoes that mean that the document got corrupted?\n\n> \tMy point is not that change is always bad, but that we should\n> really look forward to what we're doing, and that \"it's in the release\n> notes\" is not sufficient if an older git gives an incomprehensible error\n> or a silent problem. I was responding to the cavalier statement \"well,\n> it's in the release notes, so don't worry about older versions\".\n\nYour allegation of corruptions is cavalier just as well.\n\nI'm telling you that there won't be any such corruption. Just like in \nthe M$ Office case, it is expected that newer versions make data \nunusable by older versions at some point -- that's the inevitable side \neffect of progress.\n\nAnd we cannot always anticipate what kind of incompatibility will be \nworth making in the future, so it is hard to come with proper error \nmessages in all cases today.\n\nRecent enough Git versions do suggest upgrading when they refuse to \naccess repositories though, and later Git versions can be configured to \nremain compatible with old Git versions. And we also document it.\n\nAnd when you still cannot figure it out on your own, then there is that \nfree support available on a public mailing list, and even an IRC \nchannel.\n\nSo I don't see how we could do better in that regard. Carving the \nrepository format in stone to keep ancient versions working forever is \n_not_ a solution.\n\n\nNicolas\n"},{"id":"63486","messageId":"20071217211317.GC19816@mail.oracle.com","threadId":"11102","inReplyTo":"alpine.LFD.0.999999.0712171517320.8467@xanadu.home","subject":"Re: [PATCH] provide advance warning of some future pack default changes","fromName":"Joel Becker","fromEmail":"joel.becker@oracle.com","sentAt":"2007-12-17T21:13:18Z","receivedAt":"2007-12-17T21:13:18Z","isPatch":true,"sender":{"key":"joel.becker@oracle.com","avatar":null},"body":"On Mon, Dec 17, 2007 at 03:41:24PM -0500, Nicolas Pitre wrote:\n> On Mon, 17 Dec 2007, Joel Becker wrote:\n> > \tYou may not see a case for actual corruptions, but my coworker\n> > updated his tree on a box with 1.5.x, then tried to work on a box with\n> > 1.4.x (I think 1.4.2 back then), and ended up with a tree that was\n> > unusable. He had to re-clone, and I think he got lucky recovering\n> > pending changes (probably using 1.5.x on the branches with the changes,\n> > as master was what got broken).\n> \n> I still claim that there wasn't any corruptions.\n> \n> Just for fun, just edit some document with Microsoft Office 95, then \n> open the same document with Office 2007 and save it with default \n> settings. Now try to open it back with Office 95. It won't work. \n> Does that mean that the document got corrupted?\n\n\tNo, but when you try to re-open it with Office 2007, you expect\nit to work, don't you? His master was messed up even for 1.5.x. It was\nnow months ago, so I don't quite remember all the details, but I think\nyou'd agree that \"1.5.x no longer works\" is not correct.\n\n> I'm telling you that there won't be any such corruption. Just like in \n> the M$ Office case, it is expected that newer versions make data \n> unusable by older versions at some point -- that's the inevitable side \n> effect of progress.\n\n\tSure, we're not complaining about that. We complain some about\nthe fast pace (at the time he had his problem, 1.4 installs were not\nunusual, and Junio's response suggested that \"I use NFS\" wasn't strongly\nconsidered as a use case), but more we complain about the obscurity of\nthe reason. If it's obvious what happened (not the specifics, just\n\"please upgrade\" or \"repository format changed\" or something), the user\nmoves along.\n\n> And we cannot always anticipate what kind of incompatibility will be \n> worth making in the future, so it is hard to come with proper error \n> messages in all cases today.\n\n\tHow hard is it? We have core.repositoryformatversion. We\nundoubtably have headers on our files. As an example, an older version\nshould be able to ascertain 1) this is a pack file 2) I don't know how\nto read it. Thus, it should always be able to tell the user as such.\nThis is different from reporting \"invalid pack file\" or \"corrupt pack\nfile\", or \"garbage in tree\". Filesystems, as an example, set\ncompatibility bits or version levels. When an old kernel tries to mount\nit, it does not say \"corrupt filesystem\", it says \"this filesystem has a\nfeature I don't understand, I'm going to be nice and not do anything,\nplease upgrade\". This is clear, even though the older kernel doesn't\nhave any specifics about what the new feature is.\n\n> So I don't see how we could do better in that regard. Carving the \n> repository format in stone to keep ancient versions working forever is \n> _not_ a solution.\n\n\tOnce again, we're not asking for that. We're asking that you\nthink ahead to what can change, and plan for it, so you can tell the\nuser. If the user has a clear idea where to go next, the can solve the\nrest themselves.\n\tLook, not everyone reads this mailing list. No one outside of\nthis list reads the Release Notes. They get their upgrade via yum or\napt-get, along with 100 other packages. You can't assume that 3 months\nof feature discussion here is going to be known to your average user.\n\nJoel\n\n-- \n\n\"Vote early and vote often.\" \n - Al Capone\n\nJoel Becker\nPrincipal Software Developer\nOracle\nE-mail: joel.becker@oracle.com\nPhone: (650) 506-8127\n"},{"id":"63483","messageId":"7v3au16myj.fsf@gitster.siamese.dyndns.org","threadId":"11102","inReplyTo":"alpine.LFD.0.999999.0712171517320.8467@xanadu.home","subject":"Re: [PATCH] provide advance warning of some future pack default changes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-12-17T21:16:52Z","receivedAt":"2007-12-17T21:16:52Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre writes:\n\n> On Mon, 17 Dec 2007, Joel Becker wrote:\n>\n>> \tYou may not see a case for actual corruptions, but my coworker\n>> updated his tree on a box with 1.5.x, then tried to work on a box with\n>> 1.4.x (I think 1.4.2 back then), and ended up with a tree that was\n>> unusable. He had to re-clone, and I think he got lucky recovering\n>> pending changes (probably using 1.5.x on the branches with the changes,\n>> as master was what got broken).\n>\n> I still claim that there wasn't any corruptions.\n> ...\n> Your allegation of corruptions is cavalier just as well.\n>\n> I'm telling you that there won't be any such corruption. Just like in \n> the M$ Office case, it is expected that newer versions make data \n> unusable by older versions at some point -- that's the inevitable side \n> effect of progress.\n\nThis is mostly spilt milk under the bridge now, but I have to mildly\ndisagree.\n\nIf we had core.usedeltabaseoffset instead of repack.usedeltabaseoffset,\nand made the format negotiation in fetch-pack protocol pay attention to\nthat variable, Joel's coworker did not have to suffer if the repository\nexplicitly asked OFS_DELTA not to be used.\n\nInstead we unconditionally said \"if you are downloading with the new\nclient, we assume you would never be using older client to access that\nrepository locally, if you did so, you are screwed.\"\n\nIOW, I think e4fe4b8ef7cdde842a9e5e2594d0fba1367d9dd3 (let the GIT\nnative protocol use offsets to delta base when possible) could have been\na bit more careful in this respect.\n"},{"id":"63489","messageId":"20071217213049.GG13515@fieldses.org","threadId":"11102","inReplyTo":"20071217211317.GC19816@mail.oracle.com","subject":"Re: [PATCH] provide advance warning of some future pack default changes","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-12-17T21:30:49Z","receivedAt":"2007-12-17T21:30:49Z","isPatch":true,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Mon, Dec 17, 2007 at 01:13:18PM -0800, Joel Becker wrote:\n> \tSure, we're not complaining about that. We complain some about\n> the fast pace (at the time he had his problem, 1.4 installs were not\n> unusual, and Junio's response suggested that \"I use NFS\" wasn't strongly\n> considered as a use case), but more we complain about the obscurity of\n> the reason. If it's obvious what happened (not the specifics, just\n> \"please upgrade\" or \"repository format changed\" or something), the user\n> moves along.\n\nBy the way, just as a data point: I do keep some git repositories on\nNFS, and access them from multiple machines with different git versions\n(not on purpose--it's just that the machines don't all run the same\ndistro, so it'd be extra work to give them all the same version). I\ndon't use anything older than 1.5.0. If the repository became unusable\non one of those machines without warning it'd be annoying.\n\n---b.\n"},{"id":"63491","messageId":"alpine.LFD.0.999999.0712171641460.8467@xanadu.home","threadId":"11102","inReplyTo":"7v3au16myj.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] provide advance warning of some future pack default changes","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-12-17T21:45:26Z","receivedAt":"2007-12-17T21:45:26Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Mon, 17 Dec 2007, Junio C Hamano wrote:\n\n> This is mostly spilt milk under the bridge now, but I have to mildly\n> disagree.\n> \n> If we had core.usedeltabaseoffset instead of repack.usedeltabaseoffset,\n> and made the format negotiation in fetch-pack protocol pay attention to\n> that variable, Joel's coworker did not have to suffer if the repository\n> explicitly asked OFS_DELTA not to be used.\n> \n> Instead we unconditionally said \"if you are downloading with the new\n> client, we assume you would never be using older client to access that\n> repository locally, if you did so, you are screwed.\"\n> \n> IOW, I think e4fe4b8ef7cdde842a9e5e2594d0fba1367d9dd3 (let the GIT\n> native protocol use offsets to delta base when possible) could have been\n> a bit more careful in this respect.\n\nProbably. But this can hardly be called a \"corruption\" since nothing \nwas actually lost, rather an incompatibility problem.\n\nIf, on the other hand, the latest Git version wasn't able to read it \neither then this is a different matter entirely.\n\n\nNicolas\n"},{"id":"63493","messageId":"alpine.LFD.0.999999.0712171646230.8467@xanadu.home","threadId":"11102","inReplyTo":"20071217213049.GG13515@fieldses.org","subject":"Re: [PATCH] provide advance warning of some future pack default changes","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-12-17T21:52:16Z","receivedAt":"2007-12-17T21:52:16Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Mon, 17 Dec 2007, J. Bruce Fields wrote:\n\n> By the way, just as a data point: I do keep some git repositories on\n> NFS, and access them from multiple machines with different git versions\n> (not on purpose--it's just that the machines don't all run the same\n> distro, so it'd be extra work to give them all the same version). I\n> don't use anything older than 1.5.0. If the repository became unusable\n> on one of those machines without warning it'd be annoying.\n\nWhat the v1.5.5 release notes will say is that you'll have to set \npack.indexversion=1 to remain compatible with pre-1.5.2 Git versions. \n\nAnd even if you forget about it then there'll be a simple way to regain \ncompatibility after the facts.\n\n\nNicolas\n"},{"id":"63494","messageId":"20071217215709.GH13515@fieldses.org","threadId":"11102","inReplyTo":"alpine.LFD.0.999999.0712171646230.8467@xanadu.home","subject":"Re: [PATCH] provide advance warning of some future pack default changes","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-12-17T21:57:09Z","receivedAt":"2007-12-17T21:57:09Z","isPatch":true,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Mon, Dec 17, 2007 at 04:52:16PM -0500, Nicolas Pitre wrote:\n> On Mon, 17 Dec 2007, J. Bruce Fields wrote:\n> \n> > By the way, just as a data point: I do keep some git repositories on\n> > NFS, and access them from multiple machines with different git versions\n> > (not on purpose--it's just that the machines don't all run the same\n> > distro, so it'd be extra work to give them all the same version). I\n> > don't use anything older than 1.5.0. If the repository became unusable\n> > on one of those machines without warning it'd be annoying.\n> \n> What the v1.5.5 release notes will say is that you'll have to set \n> pack.indexversion=1 to remain compatible with pre-1.5.2 Git versions. \n\nIs there any reason not to make pack.indexversion=1 the default (for\npreexisting repositories at the very least) and suggest in the release\nnotes that people set something else if they want the features the new\nversion provides?\n\n--b.\n\n> And even if you forget about it then there'll be a simple way to regain \n> compatibility after the facts.\n"},{"id":"63496","messageId":"alpine.LFD.0.999999.0712171711100.8467@xanadu.home","threadId":"11102","inReplyTo":"20071217215709.GH13515@fieldses.org","subject":"Re: [PATCH] provide advance warning of some future pack default changes","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-12-17T22:15:18Z","receivedAt":"2007-12-17T22:15:18Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Mon, 17 Dec 2007, J. Bruce Fields wrote:\n\n> On Mon, Dec 17, 2007 at 04:52:16PM -0500, Nicolas Pitre wrote:\n> > On Mon, 17 Dec 2007, J. Bruce Fields wrote:\n> > \n> > > By the way, just as a data point: I do keep some git repositories on\n> > > NFS, and access them from multiple machines with different git versions\n> > > (not on purpose--it's just that the machines don't all run the same\n> > > distro, so it'd be extra work to give them all the same version). I\n> > > don't use anything older than 1.5.0. If the repository became unusable\n> > > on one of those machines without warning it'd be annoying.\n> > \n> > What the v1.5.5 release notes will say is that you'll have to set \n> > pack.indexversion=1 to remain compatible with pre-1.5.2 Git versions. \n> \n> Is there any reason not to make pack.indexversion=1 the default (for\n> preexisting repositories at the very least) and suggest in the release\n> notes that people set something else if they want the features the new\n> version provides?\n\nThat's already the case now.\n\nBut the thing is that index version 2 is better and actually plug a flaw \nin the repacking process where unnoticed corruption could be repacked \notherwise. So for better repo integrity sake, it has to become the \ndefault at some point.\n\n\nNicolas\n"},{"id":"63497","messageId":"7vtzmh55lu.fsf@gitster.siamese.dyndns.org","threadId":"11102","inReplyTo":"20071217215709.GH13515@fieldses.org","subject":"Re: [PATCH] provide advance warning of some future pack default changes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-12-17T22:17:01Z","receivedAt":"2007-12-17T22:17:01Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"J. Bruce Fields\" writes:\n\n> On Mon, Dec 17, 2007 at 04:52:16PM -0500, Nicolas Pitre wrote:\n>> On Mon, 17 Dec 2007, J. Bruce Fields wrote:\n>> \n>> > By the way, just as a data point: I do keep some git repositories on\n>> > NFS, and access them from multiple machines with different git versions\n>> > (not on purpose--it's just that the machines don't all run the same\n>> > distro, so it'd be extra work to give them all the same version). I\n>> > don't use anything older than 1.5.0. If the repository became unusable\n>> > on one of those machines without warning it'd be annoying.\n>> \n>> What the v1.5.5 release notes will say is that you'll have to set \n>> pack.indexversion=1 to remain compatible with pre-1.5.2 Git versions. \n>\n> Is there any reason not to make pack.indexversion=1 the default (for\n> preexisting repositories at the very least) and suggest in the release\n> notes that people set something else if they want the features the new\n> version provides?\n\nThat's a judgement call.\n\nPack-idx format v2 is by design much safer in the face of bitflip (do we\nhave a test case to make sure this is indeed true?). But from the end\nuser's point of view, all the usual \"I do not want to be forced to\nupdate that old box I do not want to touch\" applies.\n\nAnd the people who needs to suffer from the dilemma are only the ones\nwho access a single repository across NFS with git from different\nvintage. If that is a minority and/or tends to be more clueful people,\nthe inconvenience factor may be outweighed by the advantage v2 offers,\nand pushing adoption of v2 harder the way Nico is driving at would\ngenerally be a good thing.\n"},{"id":"63500","messageId":"20071217223055.GI13515@fieldses.org","threadId":"11102","inReplyTo":"7vtzmh55lu.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] provide advance warning of some future pack default changes","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-12-17T22:30:55Z","receivedAt":"2007-12-17T22:30:55Z","isPatch":true,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Mon, Dec 17, 2007 at 02:17:01PM -0800, Junio C Hamano wrote:\n> \"J. Bruce Fields\" writes:\n> \n> > On Mon, Dec 17, 2007 at 04:52:16PM -0500, Nicolas Pitre wrote:\n> >> On Mon, 17 Dec 2007, J. Bruce Fields wrote:\n> >> \n> >> > By the way, just as a data point: I do keep some git repositories on\n> >> > NFS, and access them from multiple machines with different git versions\n> >> > (not on purpose--it's just that the machines don't all run the same\n> >> > distro, so it'd be extra work to give them all the same version). I\n> >> > don't use anything older than 1.5.0. If the repository became unusable\n> >> > on one of those machines without warning it'd be annoying.\n> >> \n> >> What the v1.5.5 release notes will say is that you'll have to set \n> >> pack.indexversion=1 to remain compatible with pre-1.5.2 Git versions. \n> >\n> > Is there any reason not to make pack.indexversion=1 the default (for\n> > preexisting repositories at the very least) and suggest in the release\n> > notes that people set something else if they want the features the new\n> > version provides?\n> \n> That's a judgement call.\n\nSure. And I'm totally unfamiliar with the details here, so don't my let\nmy judgement weigh too heavily.\n\n> Pack-idx format v2 is by design much safer in the face of bitflip (do we\n> have a test case to make sure this is indeed true?). But from the end\n> user's point of view, all the usual \"I do not want to be forced to\n> update that old box I do not want to touch\" applies.\n> \n> And the people who needs to suffer from the dilemma are only the ones\n> who access a single repository across NFS with git from different\n> vintage.\n\nHm. We tell people to set up public repo's by doing something like:\n\n\tgit clone --bare ~/proj proj.git\n\ttouch proj.git/git-daemon-export-ok\n\tscp -r proj.git example.com:\n\nIs that going to hit the same problem if the public server has an older\ngit version? (Servers do tend to be on longer upgrade cycles; the\npublic server I use was on something 1.4ish till about a month ago.)\n\n--b.\n"},{"id":"63506","messageId":"7vprx553u4.fsf@gitster.siamese.dyndns.org","threadId":"11102","inReplyTo":"20071217223055.GI13515@fieldses.org","subject":"Re: [PATCH] provide advance warning of some future pack default changes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-12-17T22:55:15Z","receivedAt":"2007-12-17T22:55:15Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"J. Bruce Fields\" writes:\n\n> Hm. We tell people to set up public repo's by doing something like:\n>\n> \tgit clone --bare ~/proj proj.git\n> \ttouch proj.git/git-daemon-export-ok\n> \tscp -r proj.git example.com:\n>\n> Is that going to hit the same problem if the public server has an older\n> git version?\n\nIt will, but I think you should teach people --mirror pushing these\ndays, which was specifically invented for priming the public\nrepository.\n\nThat way, the administrator at example.com, as long as he initializes an\nempty repository with suitable daemon-export-ok and necessary hooks\n(which can be automated via templates), does not even have to allow you\na full ssh access.\n"},{"id":"63517","messageId":"alpine.LFD.0.999999.0712171810310.8467@xanadu.home","threadId":"11102","inReplyTo":"7vtzmh55lu.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] provide advance warning of some future pack default changes","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-12-17T23:13:29Z","receivedAt":"2007-12-17T23:13:29Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Mon, 17 Dec 2007, Junio C Hamano wrote:\n\n> Pack-idx format v2 is by design much safer in the face of bitflip (do we\n> have a test case to make sure this is indeed true?).\n\nt5302 provides a good demonstration of that.\n\n\nNicolas\n"},{"id":"63526","messageId":"20071218000443.GA8294@fieldses.org","threadId":"11102","inReplyTo":"7vprx553u4.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] provide advance warning of some future pack default changes","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-12-18T00:04:43Z","receivedAt":"2007-12-18T00:04:43Z","isPatch":true,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Mon, Dec 17, 2007 at 02:55:15PM -0800, Junio C Hamano wrote:\n> \"J. Bruce Fields\" writes:\n> \n> > Hm. We tell people to set up public repo's by doing something like:\n> >\n> > \tgit clone --bare ~/proj proj.git\n> > \ttouch proj.git/git-daemon-export-ok\n> > \tscp -r proj.git example.com:\n> >\n> > Is that going to hit the same problem if the public server has an older\n> > git version?\n> \n> It will, but I think you should teach people --mirror pushing these\n> days, which was specifically invented for priming the public\n> repository.\n>\n> That way, the administrator at example.com, as long as he initializes an\n> empty repository with suitable daemon-export-ok and necessary hooks\n> (which can be automated via templates), does not even have to allow you\n> a full ssh access.\n\nSo the basic instructions would be something like this?:\n\n\tssh example.com \"git init --bare myproj.git\"\n\t# (or ask your admin to do the previous step)\n\tgit add remote example example.com:myproj.git\n\tgit push --mirror example\n\nOK, that's neat, thanks.\n\nOn the backwards-compatibility issue, though: this won't help the large\nnumber of people who learned to just clone a bare repo and copy it\naround, since they aren't of their own initiative going to seek out new\nways of doing things that they think they already know how to do.\n\n--b.\n"},{"id":"63534","messageId":"7vbq8o4yxc.fsf@gitster.siamese.dyndns.org","threadId":"11102","inReplyTo":"alpine.LFD.0.999999.0712171641460.8467@xanadu.home","subject":"Re: [PATCH] provide advance warning of some future pack default changes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-12-18T00:41:19Z","receivedAt":"2007-12-18T00:41:19Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre writes:\n\n> On Mon, 17 Dec 2007, Junio C Hamano wrote:\n> ...\n>> Instead we unconditionally said \"if you are downloading with the new\n>> client, we assume you would never be using older client to access that\n>> repository locally, if you did so, you are screwed.\"\n>> \n>> IOW, I think e4fe4b8ef7cdde842a9e5e2594d0fba1367d9dd3 (let the GIT\n>> native protocol use offsets to delta base when possible) could have been\n>> a bit more careful in this respect.\n>\n> Probably. But this can hardly be called a \"corruption\" since nothing \n> was actually lost, rather an incompatibility problem.\n\nIt is not a corruption, but the distinction doesn't matter much to the\nend user who wants to get the job done with the data right now. The\ndata that was made inaccessible is inaccessible. The only difference is\nthat it is recoverable once the user upgrades, but that may be painful,\neven though it may be rewarding afterwards and worth doing so, and the\nuser may not be able to afford doing so right at that moment.\n"},{"id":"63550","messageId":"20071218021556.GC13821@ca-server1.us.oracle.com","threadId":"11102","inReplyTo":"alpine.LFD.0.999999.0712171517320.8467@xanadu.home","subject":"Re: [PATCH] provide advance warning of some future pack default changes","fromName":"Mark Fasheh","fromEmail":"mark.fasheh@oracle.com","sentAt":"2007-12-18T02:15:56Z","receivedAt":"2007-12-18T02:15:56Z","isPatch":true,"sender":{"key":"mark.fasheh@oracle.com","avatar":null},"body":"Hi,\n\n\tJust to \"out\" myself, I'm the \"co-worker\" whose name Joel has been\n(politely) keeping anonymous.\n\nOn Mon, Dec 17, 2007 at 03:41:24PM -0500, Nicolas Pitre wrote:\n> > \tYou may not see a case for actual corruptions, but my coworker\n> > updated his tree on a box with 1.5.x, then tried to work on a box with\n> > 1.4.x (I think 1.4.2 back then), and ended up with a tree that was\n> > unusable. He had to re-clone, and I think he got lucky recovering\n> > pending changes (probably using 1.5.x on the branches with the changes,\n> > as master was what got broken).\n> \n> I still claim that there wasn't any corruptions.\n\nThe following description is really vague because this was a while ago:\n\nSomething made my ocfs2.git tree unusable in that I could no longer do\ncommon tasks, such as git-log, etc without getting messages about corrupted\nrefs.\n\nI wish I had saved off some of the messages. Sorry.\n\nI had to re-create my git tree several times before I learned by deduction\nthat it was the older versions of git on some of the machines that were\nwriting some sort of incompatible format.\n\n\n> Just for fun, just edit some document with Microsoft Office 95, then \n> open the same document with Office 2007 and save it with default \n> settings. Now try to open it back with Office 95. It won't work. \n> Does that mean that the document got corrupted?\n\nBoy, I hope Microsoft Office isn't our bar for compatiblity here...\n\t--Mark\n\n--\nMark Fasheh\nSenior Software Developer, Oracle\nmark.fasheh@oracle.com\n"},{"id":"63551","messageId":"20071218022323.GD13821@ca-server1.us.oracle.com","threadId":"11102","inReplyTo":"7vbq8o4yxc.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] provide advance warning of some future pack default changes","fromName":"Mark Fasheh","fromEmail":"mark.fasheh@oracle.com","sentAt":"2007-12-18T02:23:23Z","receivedAt":"2007-12-18T02:23:23Z","isPatch":true,"sender":{"key":"mark.fasheh@oracle.com","avatar":null},"body":"On Mon, Dec 17, 2007 at 04:41:19PM -0800, Junio C Hamano wrote:\n> It is not a corruption, but the distinction doesn't matter much to the\n> end user who wants to get the job done with the data right now. The\n> data that was made inaccessible is inaccessible. The only difference is\n> that it is recoverable once the user upgrades, but that may be painful,\n> even though it may be rewarding afterwards and worth doing so, and the\n> user may not be able to afford doing so right at that moment.\n\nJunio, I agree 100% with your description here. This is all about user\nexperience and data which is silently made inaccessible makes them feel\npretty bad.\n\t--Mark\n\n--\nMark Fasheh\nSenior Software Developer, Oracle\nmark.fasheh@oracle.com\n"},{"id":"63552","messageId":"alpine.LFD.0.999999.0712172212110.8467@xanadu.home","threadId":"11102","inReplyTo":"7vbq8o4yxc.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] provide advance warning of some future pack default changes","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-12-18T03:23:31Z","receivedAt":"2007-12-18T03:23:31Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Mon, 17 Dec 2007, Junio C Hamano wrote:\n\n> Nicolas Pitre writes:\n> \n> > On Mon, 17 Dec 2007, Junio C Hamano wrote:\n> > ...\n> >> Instead we unconditionally said \"if you are downloading with the new\n> >> client, we assume you would never be using older client to access that\n> >> repository locally, if you did so, you are screwed.\"\n> >> \n> >> IOW, I think e4fe4b8ef7cdde842a9e5e2594d0fba1367d9dd3 (let the GIT\n> >> native protocol use offsets to delta base when possible) could have been\n> >> a bit more careful in this respect.\n> >\n> > Probably. But this can hardly be called a \"corruption\" since nothing \n> > was actually lost, rather an incompatibility problem.\n> \n> It is not a corruption, but the distinction doesn't matter much to the\n> end user who wants to get the job done with the data right now. The\n> data that was made inaccessible is inaccessible. The only difference is\n> that it is recoverable once the user upgrades, but that may be painful,\n> even though it may be rewarding afterwards and worth doing so, and the\n> user may not be able to afford doing so right at that moment.\n\nSure, but at some point that's something users mixing versions should be \nready to cope with. We try to make it as painless as possible of \ncourse.\n\nData corruption is usually something you just cannot recover from \n(unless you have backups). And if mixing different tool versions \nactually cause data corruption then this is a much much more serious \nissue and that must be avoided.\n\nSo at some point the distinction must be made, and if using an old \nversion of Git on a repo created by a new version actually produces data \ncorruption as Joel seemed to imply, then we must really take it \nseriously. OTOH, compatibility issues are usually much less of a pain \nto fix.\n\n\nNicolas\n"},{"id":"63553","messageId":"alpine.LFD.0.999999.0712172224560.8467@xanadu.home","threadId":"11102","inReplyTo":"20071218021556.GC13821@ca-server1.us.oracle.com","subject":"Re: [PATCH] provide advance warning of some future pack default changes","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-12-18T03:34:40Z","receivedAt":"2007-12-18T03:34:40Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Mon, 17 Dec 2007, Mark Fasheh wrote:\n\n> Hi,\n> \n> \tJust to \"out\" myself, I'm the \"co-worker\" whose name Joel has been\n> (politely) keeping anonymous.\n> \n> On Mon, Dec 17, 2007 at 03:41:24PM -0500, Nicolas Pitre wrote:\n> > > \tYou may not see a case for actual corruptions, but my coworker\n> > > updated his tree on a box with 1.5.x, then tried to work on a box with\n> > > 1.4.x (I think 1.4.2 back then), and ended up with a tree that was\n> > > unusable. He had to re-clone, and I think he got lucky recovering\n> > > pending changes (probably using 1.5.x on the branches with the changes,\n> > > as master was what got broken).\n> > \n> > I still claim that there wasn't any corruptions.\n> \n> The following description is really vague because this was a while ago:\n> \n> Something made my ocfs2.git tree unusable in that I could no longer do\n> common tasks, such as git-log, etc without getting messages about corrupted\n> refs.\n> \n> I wish I had saved off some of the messages. Sorry.\n> \n> I had to re-create my git tree several times before I learned by deduction\n> that it was the older versions of git on some of the machines that were\n> writing some sort of incompatible format.\n\nNext time please don't hesitate to post your issue on this list. The \nfix could have been so obvious to many people on the list, saving you \ntime and frustration. In your case I think the \"fix\" would have \nconsisted of simply running \"git repack -a -d\" on the machine with the \nmost recent Git version.\n\nAnd if it was a case of real corruption then we certainly would have \nliked to know about it ASAP.\n\n> > Just for fun, just edit some document with Microsoft Office 95, then \n> > open the same document with Office 2007 and save it with default \n> > settings. Now try to open it back with Office 95. It won't work. \n> > Does that mean that the document got corrupted?\n> \n> Boy, I hope Microsoft Office isn't our bar for compatiblity here...\n\nWe can do better of course, like allowing you to still produce the old \nformat with a new version of Git. But sometimes format changes are \nunavoidable for many good reasons.\n\n\nNicolas\n"},{"id":"63555","messageId":"46a038f90712171952i4f53876fv55b0e6993d5f4b0a@mail.gmail.com","threadId":"11102","inReplyTo":"alpine.LFD.0.999999.0712172212110.8467@xanadu.home","subject":"Re: [PATCH] provide advance warning of some future pack default changes","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2007-12-18T03:52:22Z","receivedAt":"2007-12-18T03:52:22Z","isPatch":true,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On Dec 18, 2007 4:23 PM, Nicolas Pitre wrote:\n> Sure, but at some point that's something users mixing versions should be\n> ready to cope with. We try to make it as painless as possible of\n> course.\n\nI have to say I agree with the \"apparently minor updates should not\nbreak cross-version compat\". And I think it's a communication issue\naround the version numbering. The fact that this will be introduced\nwith a v1.5.5 is, IMHO, a good part of the problem.\n\nIf cvs 1.11 doesn't talk with 1.12 I'll say there are nuts - minor\nrevisions should interoperate with end users not even thinking about\nit. But 1.5.5 has in its changelog lots of deprecations and interop\nchanges.\n\nIt's not good communication to label it 1.5.5.\n\nOther than that, it's an _amazing_ thing, and I'm in love with git.\nBut the version number is a bit of a lie -- and is bound to confuse\nand anger end users.\n\ncheers,\n\n\nmartin\n"},{"id":"63556","messageId":"alpine.LFD.0.999999.0712172308360.8467@xanadu.home","threadId":"11102","inReplyTo":"46a038f90712171952i4f53876fv55b0e6993d5f4b0a@mail.gmail.com","subject":"Re: [PATCH] provide advance warning of some future pack default changes","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-12-18T04:09:57Z","receivedAt":"2007-12-18T04:09:57Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 18 Dec 2007, Martin Langhoff wrote:\n\n> On Dec 18, 2007 4:23 PM, Nicolas Pitre wrote:\n> > Sure, but at some point that's something users mixing versions should be\n> > ready to cope with. We try to make it as painless as possible of\n> > course.\n> \n> I have to say I agree with the \"apparently minor updates should not\n> break cross-version compat\". And I think it's a communication issue\n> around the version numbering. The fact that this will be introduced\n> with a v1.5.5 is, IMHO, a good part of the problem.\n> \n> If cvs 1.11 doesn't talk with 1.12 I'll say there are nuts - minor\n> revisions should interoperate with end users not even thinking about\n> it. But 1.5.5 has in its changelog lots of deprecations and interop\n> changes.\n> \n> It's not good communication to label it 1.5.5.\n\nI agree. Might be time for 1.6.0?\n\n\nNicolas\n"},{"id":"63558","messageId":"7vlk7s38aq.fsf@gitster.siamese.dyndns.org","threadId":"11102","inReplyTo":"46a038f90712171952i4f53876fv55b0e6993d5f4b0a@mail.gmail.com","subject":"Re: [PATCH] provide advance warning of some future pack default changes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-12-18T05:01:49Z","receivedAt":"2007-12-18T05:01:49Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Martin Langhoff\" writes:\n\n> If cvs 1.11 doesn't talk with 1.12 I'll say there are nuts - minor\n> revisions should interoperate with end users not even thinking about\n> it. But 1.5.5 has in its changelog lots of deprecations and interop\n> changes.\n>\n> It's not good communication to label it 1.5.5.\n\nThere indeed are handful scheduled removals. I do not mind declaring\nthat 1.6.0 comes after 1.5.4, or just relabel the removal schedule for\n1.6.0 and keep the scheduled change on hold a bit longer.\n\nBy the way, I'd appreciate an Ack or comment on the recent pserver\nauthentication enhancements in c934dca22ee07cb3ca146a249bdb73ab0f30b2b1\n(Authentication support for pserver); I do not mind merging this in\n1.5.4 as the change is fairly isolated and should not affect people who\ndo not use the feature.\n"},{"id":"63576","messageId":"200712181024.52495.jnareb@gmail.com","threadId":"11102","inReplyTo":"7vlk7s38aq.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] provide advance warning of some future pack default changes","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-12-18T09:24:52Z","receivedAt":"2007-12-18T09:24:52Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n> \"Martin Langhoff\" writes:\n> \n>> If cvs 1.11 doesn't talk with 1.12 I'll say there are nuts - minor\n>> revisions should interoperate with end users not even thinking about\n>> it. But 1.5.5 has in its changelog lots of deprecations and interop\n>> changes.\n>>\n>> It's not good communication to label it 1.5.5.\n> \n> There indeed are handful scheduled removals. I do not mind declaring\n> that 1.6.0 comes after 1.5.4, or just relabel the removal schedule for\n> 1.6.0 and keep the scheduled change on hold a bit longer.\n\nBy the way, I wonder if there would be packv4 in time for 1.6.0;\nperhaps not enabled by default.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"63590","messageId":"20071218111136.GA6266@coredump.intra.peff.net","threadId":"11102","inReplyTo":"7vlk7s38aq.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] provide advance warning of some future pack default changes","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-12-18T11:11:36Z","receivedAt":"2007-12-18T11:11:36Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Dec 17, 2007 at 09:01:49PM -0800, Junio C Hamano wrote:\n\n> There indeed are handful scheduled removals. I do not mind declaring\n> that 1.6.0 comes after 1.5.4, or just relabel the removal schedule for\n> 1.6.0 and keep the scheduled change on hold a bit longer.\n\nI can think of two other user-visible changes which have been discussed\nthat might warrant such a version bump:\n - option parsing tweaks (hopefully these should be minor, but it is\n clear that we cannot be 100% consistent while retaining the\n identical previous behavior)\n - moving dashed forms out of paths\n\n-Peff\n"},{"id":"63593","messageId":"Pine.LNX.4.64.0712181202460.23902@racer.site","threadId":"11102","inReplyTo":"200712181024.52495.jnareb@gmail.com","subject":"Re: [PATCH] provide advance warning of some future pack default changes","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-12-18T12:03:34Z","receivedAt":"2007-12-18T12:03:34Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 18 Dec 2007, Jakub Narebski wrote:\n\n> By the way, I wonder if there would be packv4 in time for 1.6.0; perhaps \n> not enabled by default.\n\nSure! If someone undertakes the massive amount of work it takes to bring \npackv4 off!\n\nBut if that is done, I do not see why it should be off by default.\n\nCiao,\nDscho\n"},{"id":"63594","messageId":"Pine.LNX.4.64.0712181204500.23902@racer.site","threadId":"11102","inReplyTo":"20071218111136.GA6266@coredump.intra.peff.net","subject":"Re: [PATCH] provide advance warning of some future pack default changes","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-12-18T12:06:23Z","receivedAt":"2007-12-18T12:06:23Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 18 Dec 2007, Jeff King wrote:\n\n> On Mon, Dec 17, 2007 at 09:01:49PM -0800, Junio C Hamano wrote:\n> \n> > There indeed are handful scheduled removals. I do not mind declaring \n> > that 1.6.0 comes after 1.5.4, or just relabel the removal schedule for \n> > 1.6.0 and keep the scheduled change on hold a bit longer.\n> \n> I can think of two other user-visible changes which have been discussed \n> that might warrant such a version bump:\n>\n> - option parsing tweaks (hopefully these should be minor, but it is\n> clear that we cannot be 100% consistent while retaining the\n> identical previous behavior)\n\nIMHO this does not warrant a version bump. It should be mostly \nbehind-the-scenes, after all.\n\n> - moving dashed forms out of paths\n\nPlaying it safe, and waiting with this after announcing it more obviously, \nis something that I appreciate. Too many scripts can break, and I am sure \nquite a few of mine will; I simply do not have the time right now to audit \nthem.\n\nCiao,\nDscho\n"},{"id":"63602","messageId":"20071218124808.GA3728@sigill.intra.peff.net","threadId":"11102","inReplyTo":"Pine.LNX.4.64.0712181204500.23902@racer.site","subject":"Re: [PATCH] provide advance warning of some future pack default changes","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-12-18T12:48:08Z","receivedAt":"2007-12-18T12:48:08Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Dec 18, 2007 at 12:06:23PM +0000, Johannes Schindelin wrote:\n\n> > - option parsing tweaks (hopefully these should be minor, but it is\n> > clear that we cannot be 100% consistent while retaining the\n> > identical previous behavior)\n> \n> IMHO this does not warrant a version bump. It should be mostly \n> behind-the-scenes, after all.\n\nYes, it should be, but I think there will be a few user-visible fallouts\n(like \"--abbrev $foo\" in scripts should now be \"--abbrev-default $foo\"\nfor safety).\n\n-Peff\n"},{"id":"63603","messageId":"Pine.LNX.4.64.0712181329340.23902@racer.site","threadId":"11102","inReplyTo":"20071218124808.GA3728@sigill.intra.peff.net","subject":"Re: [PATCH] provide advance warning of some future pack default changes","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-12-18T13:30:49Z","receivedAt":"2007-12-18T13:30:49Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 18 Dec 2007, Jeff King wrote:\n\n> On Tue, Dec 18, 2007 at 12:06:23PM +0000, Johannes Schindelin wrote:\n> \n> > > - option parsing tweaks (hopefully these should be minor, but it is\n> > > clear that we cannot be 100% consistent while retaining the\n> > > identical previous behavior)\n> > \n> > IMHO this does not warrant a version bump. It should be mostly \n> > behind-the-scenes, after all.\n> \n> Yes, it should be, but I think there will be a few user-visible fallouts\n> (like \"--abbrev $foo\" in scripts should now be \"--abbrev-default $foo\"\n> for safety).\n\nBut we are on our way to fix this, no? IOW this warrants not a version \nbump, but an extended feature freeze/bug fix period (like Junio suggested, \nuntil January).\n\nCiao,\nDscho\n"},{"id":"63606","messageId":"200712181447.36228.jnareb@gmail.com","threadId":"11102","inReplyTo":"Pine.LNX.4.64.0712181204500.23902@racer.site","subject":"Re: [PATCH] provide advance warning of some future pack default changes","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-12-18T13:47:35Z","receivedAt":"2007-12-18T13:47:35Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Johannes Schindelin wrote:\n> On Tue, 18 Dec 2007, Jeff King wrote:\n> \n>> - moving dashed forms out of paths\n> \n> Playing it safe, and waiting with this after announcing it more obviously, \n> is something that I appreciate. Too many scripts can break, and I am sure \n> quite a few of mine will; I simply do not have the time right now to audit \n> them.\n\nWe could do it IMVHO in two (or two an a half :-)) steps:\n\n1. Decide where separate exec-path area should be, following FHS. Create\n it during install. Install helper scripts there, moving it out of PATH.\n Test those tools which use helper scripts (helper commands), which\n should be _much_ easier than testing whole git for \"moving dashed forms\n out of path\" breakage.\n\n2. Move dashed forms out of PATH, perhaps leaving (or with option of\n leaving) dashed forms of porcelain in PATH. Test all scripts and tests\n ;-)\n \nI think that the first step can be done before 1.6.0, perhaps even\nbefore 1.5.4\n-- \nJakub Narebski\nPoland\n"},{"id":"63610","messageId":"alpine.LFD.0.999999.0712180909140.8467@xanadu.home","threadId":"11102","inReplyTo":"200712181024.52495.jnareb@gmail.com","subject":"Re: [PATCH] provide advance warning of some future pack default changes","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-12-18T14:16:20Z","receivedAt":"2007-12-18T14:16:20Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 18 Dec 2007, Jakub Narebski wrote:\n\n> Junio C Hamano wrote:\n> > \"Martin Langhoff\" writes:\n> > \n> >> If cvs 1.11 doesn't talk with 1.12 I'll say there are nuts - minor\n> >> revisions should interoperate with end users not even thinking about\n> >> it. But 1.5.5 has in its changelog lots of deprecations and interop\n> >> changes.\n> >>\n> >> It's not good communication to label it 1.5.5.\n> > \n> > There indeed are handful scheduled removals. I do not mind declaring\n> > that 1.6.0 comes after 1.5.4, or just relabel the removal schedule for\n> > 1.6.0 and keep the scheduled change on hold a bit longer.\n\nI think Git development is dynamic enough to justify 1.6.0 right after \n1.5.4.\n\n> By the way, I wonder if there would be packv4 in time for 1.6.0;\n> perhaps not enabled by default.\n\nI don't think so. First, if packv4 actually happens, it might justify \nv2.0.0 and not v1.6.0.\n\nBut so far there were steady improvement made to the system even with \nthe current pack format, so the return on the investment for packv4 is \ndiminishing. The largest road block for packv4 at the moment is a \ncomplete refactoring of the tree walking code.\n\n\nNicolas\n"},{"id":"63655","messageId":"20071218193035.GA4583@sigill.intra.peff.net","threadId":"11102","inReplyTo":"Pine.LNX.4.64.0712181329340.23902@racer.site","subject":"Re: [PATCH] provide advance warning of some future pack default changes","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-12-18T19:30:35Z","receivedAt":"2007-12-18T19:30:35Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Dec 18, 2007 at 01:30:49PM +0000, Johannes Schindelin wrote:\n\n> > Yes, it should be, but I think there will be a few user-visible fallouts\n> > (like \"--abbrev $foo\" in scripts should now be \"--abbrev-default $foo\"\n> > for safety).\n> \n> But we are on our way to fix this, no? IOW this warrants not a version \n> bump, but an extended feature freeze/bug fix period (like Junio suggested, \n> until January).\n\nI think the resolution seems to be that we will now support \"--abbrev\nfoo\", though we didn't in the past. Because the \"foo\" here is optional,\nthe old \"git log --abbrev HEAD\" is ambiguous. In this case we'll see\nthat \"HEAD\" isn't a number and DWIM. But that means a script trying to\nbe unambiguous should use \"git log --abbrev-default $foo\" to make sure\nthat \"$foo\" doesn't accidentally match as a number.\n\nSo there will be user-visible changes (though I don't expect them to be\nhuge...there simply aren't that many variables with optional arguments).\n\n-Peff\n"},{"id":"63662","messageId":"alpine.LFD.0.999999.0712181511030.8467@xanadu.home","threadId":"11102","inReplyTo":"20071218193035.GA4583@sigill.intra.peff.net","subject":"Re: [PATCH] provide advance warning of some future pack default changes","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-12-18T20:12:56Z","receivedAt":"2007-12-18T20:12:56Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 18 Dec 2007, Jeff King wrote:\n\n> So there will be user-visible changes (though I don't expect them to be\n> huge...there simply aren't that many variables with optional arguments).\n\nOTOH, there are quite a bunch of changes affecting the user experience. \nMany of the feedback messages printed by Git were completely revamped, \nstarting with the progress display to the fetch summary.\n\n\nNicolas\n"},{"id":"63665","messageId":"7v4pefzr7o.fsf@gitster.siamese.dyndns.org","threadId":"11102","inReplyTo":"20071218111136.GA6266@coredump.intra.peff.net","subject":"Re: [PATCH] provide advance warning of some future pack default changes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-12-18T20:24:27Z","receivedAt":"2007-12-18T20:24:27Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> I can think of two other user-visible changes which have been discussed\n> that might warrant such a version bump:\n>\n> - option parsing tweaks (hopefully these should be minor, but it is\n> clear that we cannot be 100% consistent while retaining the\n> identical previous behavior)\n\nThis could have a fallout, like *-default disambiguation which scripts\ndid not have to implement.\n\n> - moving dashed forms out of paths\n\nThis is already planned for 1.5.5 and it is not among \"other\nuser-visible changes\". Technically the use of git-foo form without\npreparing the environment has not been supported for quite some time,\nbut people have come to rely on it and I'd agree this warrants a 1.6.0.\n"}]}