{"thread":{"id":"26952","subject":"What's cooking in git.git (Mar 2011, #06; Thu, 31)","startedAt":"2011-03-31T22:26:31Z","lastAt":"2011-06-13T00:45:36Z","messageCount":13,"participants":["Junio C Hamano","Michael J Gruber","Jeff King","Sebastien Douche"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"164840","messageId":"7v62qzhqp4.fsf@alter.siamese.dyndns.org","threadId":"26952","inReplyTo":null,"subject":"What's cooking in git.git (Mar 2011, #06; Thu, 31)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-03-31T22:26:31Z","receivedAt":"2011-03-31T22:26:31Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Here are the topics that have been cooking.  Commits prefixed with '-' are\nonly in 'pu' while commits prefixed with '+' are in 'next'.\n\nIt's been two months since v1.7.4 and -rc0 was way overdue.  I'll do a -rc1\nsometime next week, hoping that we can finish this cycle by mid April.\n\nWhich means that from now on, we wouldn't be interested in topics that are\nmostly internal clean-ups, new features that is not already in 'master',\nnor fixes for nontrivial bugs that are not regressions.  A bug that\nexisted since v1.7.0 is something we have lived with long enough that it\nis not worth the risk of introducing other new bugs by trying to fix it\nbefore 1.7.5 final).\n\nWhat we would want to see are regression fixes.  There are quite a few new\ntopics that have already graduated in 'master', or have been cooking and\nshould be in 'master' shortly.  If they introduce new bugs that didn't\nexist in v1.7.4, they need to be squashed before anything else.\n\nThe criteria is a bit looser for documentation updates.  Simple grammar\nand spelling fixes are usually safe; changes in the structure and markups\nare riskier.\n\nIn any case, please use your best judgement and help polishing v1.7.5\nrelease.\n\n--------------------------------------------------\n[New Topics]\n\n* jh/notes-add-ui (2011-03-30) 1 commit\n - Make \"git notes add\" more user-friendly when there are existing notes\n\n* jk/maint-remote-mirror-safer (2011-03-30) 3 commits\n - remote: deprecate --mirror\n - remote: separate the concept of push and fetch mirrors\n - remote: disallow some nonsensical option combinations\n\n* jk/notes-ui-updates (2011-03-30) 7 commits\n - log/pretty-options: Document --[no-]notes and deprecate old notes options\n - revision.c: make --no-notes reset --notes list\n - revision.c: support --notes command-line option\n - notes: refactor display notes default handling\n - notes: refactor display notes extra refs field\n - revision.c: refactor notes ref expansion\n - notes: make expand_notes_ref globally accessible\n\n* jr/grep-en-config (2011-03-30) 1 commit\n  (merged to 'next' on 2011-03-31 at 2a73028)\n + grep: allow -E and -n to be turned on by default via configuration\n\nThis is low impact, isolated, and has no risk of breaking the system as a\nwhole. May merge by rc1.\n\n* nd/maint-setup (2011-03-26) 2 commits\n  (merged to 'next' on 2011-03-31 at 2c36f6a)\n + Kill off get_relative_cwd()\n + setup: return correct prefix if worktree is '/'\n\nThis benefits only the minority who use /.git at the root level of the\nfilesystem, but the changed code is used from many codepaths; will not\nmerge before 1.7.5.\n\n--------------------------------------------------\n[Stalled]\n\n* jc/diff-irreversible-delete (2011-02-28) 1 commit\n - git diff -D: omit the preimage of deletes\n\n\"diff -B -D\" should omit the deleting half of a broken pair from the\noutput.  This is low impact, isolated, and has no risk of breaking the\nsystem as a whole, but the topic needs documentation and tests.\n\n* gr/cvsimport-alternative-cvspass-location (2011-02-18) 1 commit\n - Look for password in both CVS and CVSNT password files.\n\nIt seems that we need separate parsers for these two formats in order not\nto regress the users of the original cvs.\n\n* jc/index-pack (2011-02-25) 5 commits\n - index-pack --verify: read anomalous offsets from v2 idx file\n - write_idx_file: need_large_offset() helper function\n - index-pack: --verify\n - write_idx_file: introduce a struct to hold idx customization options\n - index-pack: group the delta-base array entries also by type\n\nStill a WIP, and will not be ready for 1.7.5. Need to put histogram output\ninto index-pack --verify to really kill verify-pack.\n\n* jk/tag-contains (2010-07-05) 4 commits\n - Why is \"git tag --contains\" so slow?\n - default core.clockskew variable to one day\n - limit \"contains\" traversals based on commit timestamp\n - tag: speed up --contains calculation\n\nThe idea of the bottom one is probably Ok, except that the use of object\nflags needs to be rethought, or at least the helper needs to be moved to\nbuiltin/tag.c to make it clear that it should not be used outside the\ncurrent usage context.\n\n* jk/edit-notes-in-commit-log (2011-03-07) 2 commits\n - [wip] commit: allow editing notes in commit message editor\n - notes: make expand_notes_ref globally accessible\n\n* mg/grep-full-tree (2011-03-01) 2 commits\n - grep: make --full-tree work with pathspecs\n - grep: --full-tree\n\nDo not merge; it would be preferable to use \":/\" or whatever magic\npathspec that is relative to the root of the working tree.\n\n--------------------------------------------------\n[Cooking]\n\n* mz/rebase (2011-02-28) 34 commits\n  (merged to 'next' on 2011-03-31 at 3b1343c)\n + rebase: define options in OPTIONS_SPEC\n  (merged to 'next' on 2011-02-25 at 52caa7a)\n + Makefile: do not install sourced rebase scripts\n  (merged to 'next' on 2011-02-22 at 3219155)\n + rebase: use @{upstream} if no upstream specified\n + rebase -i: remove unnecessary state rebase-root\n + rebase -i: don't read unused variable preserve_merges\n + git-rebase--am: remove unnecessary --3way option\n + rebase -m: don't print exit code 2 when merge fails\n + rebase -m: remember allow_rerere_autoupdate option\n + rebase: remember strategy and strategy options\n + rebase: remember verbose option\n + rebase: extract code for writing basic state\n + rebase: factor out sub command handling\n + rebase: make -v a tiny bit more verbose\n + rebase -i: align variable names\n + rebase: show consistent conflict resolution hint\n + rebase: extract am code to new source file\n + rebase: extract merge code to new source file\n + rebase: remove $branch as synonym for $orig_head\n + rebase -i: support --stat\n + rebase: factor out call to pre-rebase hook\n + rebase: factor out clean work tree check\n + rebase: factor out reference parsing\n + rebase: reorder validation steps\n + rebase -i: remove now unnecessary directory checks\n + rebase: factor out command line option processing\n + rebase: align variable content\n + rebase: align variable names\n + rebase: stricter check of standalone sub command\n + rebase: act on command line outside parsing loop\n + rebase: improve detection of rebase in progress\n + rebase: remove unused rebase state 'prev_head'\n + rebase: read state outside loop\n + rebase: refactor reading of state\n + rebase: clearer names for directory variables\n\nI wanted to wait for an independent Ack or two for the tip one, which was\na response to regression concerns raised by J6t, but ended up merging it\nafter giving another look.  Will not merge before 1.7.5, as there is no\nuser visible improvements up to this point.\n\n* jc/merge-sans-branch (2011-03-23) 2 commits\n  (merged to 'next' on 2011-03-31 at 754a6af)\n + merge: merge with the default upstream branch without argument\n + merge: match the help text with the documentation\n\nAllow running \"git merge\" without telling it what to merge.  It will merge\nwith the \"upstream\" of the current branch if configured.  This is low\nimpact, isolated, and has no risk of major regression.  May merge before\nrc1, but it is Ok to wait.\n\n* jh/gitweb-localtime (2011-03-23) 1 commit\n - gitweb: javascript ability to adjust time based on timezone\n\n* jk/maint-merge-rename-create (2011-03-25) 3 commits\n  (merged to 'next' on 2011-03-31 at b9bc9f1)\n + merge: turn on rewrite detection\n + merge: handle renames with replacement content\n + t3030: fix accidental success in symlink rename\n\nMay merge before rc1, but it is Ok to wait.\n\n* jk/pull-into-empty (2011-03-25) 2 commits\n  (merged to 'next' on 2011-03-31 at d4dd598)\n + pull: do not clobber untracked files on initial pull\n + merge: merge unborn index before setting ref\n\nThis is low impact, isolated, and has no risk of major regression. Will\nmerge before rc1.\n\n* mz/maint-rename-unmerged (2011-03-23) 1 commit\n  (merged to 'next' on 2011-03-31 at c7b3d9a)\n + diffcore-rename: don't consider unmerged path as source\n\nWill cook until 1.7.5 final.\n\n* nd/struct-pathspec (2011-03-25) 4 commits\n  (merged to 'next' on 2011-03-31 at 66cbb7d)\n + Improve tree_entry_interesting() handling code\n + Convert read_tree{,_recursive} to support struct pathspec\n + Reimplement read_tree_recursive() using tree_entry_interesting()\n + Merge branch 'en/object-list-with-pathspec' into 'nd/struct-pathspec'\n\nWill cook until 1.7.5 final.\n\n* jc/add-u-migration (2011-03-22) 3 commits\n - add: make \"add -u/-A\" update full tree without pathspec (step 3)\n - add: make \"add -u/-A\" update full tree without pathspec (step 2)\n  (merged to 'next' on 2011-03-31 at 962e058)\n + add: make \"add -u/-A\" update full tree without pathspec\n\nThe bottom one is a necessary first step toward the UI clean-up planned\nfor 1.8.0 which we discussed in length in the earlier part of the cycle;\nthe change is low impact, isolated, and has no risk of breaking the system\nas a whole, but I would wait until the \":/\" magic pathspec materializes,\nas the advice message would have to become different, and the way to get\nmore stable semantics will become more direct.\n\n* jk/progress-with-pager (2011-03-24) 4 commits\n - diff: turn on rename detection progress reporting\n - show: turn on rename detection progress reporting\n - progress: use pager's original_stderr if available\n - pager: save the original stderr when redirecting to pager\n\nWill cook until 1.7.5 final.\n\n* sb/sparse-more (2011-03-21) 1 commit\n  (merged to 'next' on 2011-03-23 at 4bec1d1)\n + Makefile: Cover more files with make check\n\nWill merge.\n\n* jc/rename-degrade-cc-to-c (2011-01-06) 4 commits\n  (merged to 'next' on 2011-03-31 at 8d685d7)\n + diffcore-rename: fall back to -C when -C -C busts the rename limit\n + diffcore-rename: record filepair for rename src\n + diffcore-rename: refactor \"too many candidates\" logic\n + builtin/diff.c: remove duplicated call to diff_result_code()\n\nWill hold.\n\n* cn/system-path-tweak (2011-03-17) 1 commit\n - system_path: use a static buffer\n\n* en/merge-recursive (2011-03-17) 4 commits\n  (merged to 'next' on 2011-03-18 at a32016b)\n + merge-recursive: tweak magic band-aid\n  (merged to 'next' on 2011-03-09 at 3762932)\n + merge-recursive: When we detect we can skip an update, actually skip it\n + t6022: New test checking for unnecessary updates of files in D/F conflicts\n + t6022: New test checking for unnecessary updates of renamed+modified files\n\nI am not happy with these magic band aids.  Will hold.\n\n* nd/init-gitdir (2011-03-19) 2 commits\n  (merged to 'next' on 2011-03-31 at 3b8fb40)\n + init, clone: support --separate-git-dir for .git file\n + git-init.txt: move description section up\n\nWill merge.\n\n* jl/submodule-fetch-on-demand (2011-03-06) 7 commits\n  (merged to 'next' on 2011-03-20 at a5e452d)\n + fetch/pull: Describe --recurse-submodule restrictions in the BUGS section\n + submodule update: Don't fetch when the submodule commit is already present\n + fetch/pull: Don't recurse into a submodule when commits are already present\n + Submodules: Add 'on-demand' value for the 'fetchRecurseSubmodule' option\n + config: teach the fetch.recurseSubmodules option the 'on-demand' value\n + fetch/pull: Add the 'on-demand' value to the --recurse-submodules option\n + fetch/pull: recurse into submodules when necessary\n\nWill merge.\n\n* ab/i18n-st (2011-02-22) 69 commits\n  (merged to 'next' on 2011-03-23 at e2732e2)\n + i18n: git-shortlog basic messages\n + i18n: git-revert split up \"could not revert/apply\" message\n + i18n: git-revert literal \"me\" messages\n + i18n: git-revert \"Your local changes\" message\n + i18n: git-revert basic messages\n + i18n: git-notes GIT_NOTES_REWRITE_MODE error message\n + i18n: git-notes basic commands\n + i18n: git-gc \"Auto packing the repository\" message\n + i18n: git-gc basic messages\n + i18n: git-describe basic messages\n + i18n: git-clean clean.requireForce messages\n + i18n: git-clean basic messages\n + i18n: git-bundle basic messages\n + i18n: git-archive basic messages\n + i18n: git-status \"renamed: \" message\n + i18n: git-status \"Initial commit\" message\n + i18n: git-status \"Changes to be committed\" message\n + i18n: git-status shortstatus messages\n + i18n: git-status \"nothing to commit\" messages\n + i18n: git-status basic messages\n + i18n: git-push \"prevent you from losing\" message\n + i18n: git-push basic messages\n + i18n: git-tag tag_template message\n + i18n: git-tag basic messages\n + i18n: git-reset \"Unstaged changes after reset\" message\n + i18n: git-reset reset_type_names messages\n + i18n: git-reset basic messages\n + i18n: git-rm basic messages\n + i18n: git-mv \"bad\" messages\n + i18n: git-mv basic messages\n + i18n: git-merge \"Wonderful\" message\n + i18n: git-merge \"You have not concluded your merge\" messages\n + i18n: git-merge \"Updating %s..%s\" message\n + i18n: git-merge basic messages\n + i18n: git-log \"--OPT does not make sense\" messages\n + i18n: git-log basic messages\n + i18n: git-grep \"--open-files-in-pager\" message\n + i18n: git-grep basic messages\n + i18n: git-fetch split up \"(non-fast-forward)\" message\n + i18n: git-fetch update_local_ref messages\n + i18n: git-fetch formatting messages\n + i18n: git-fetch basic messages\n + i18n: git-diff basic messages\n + i18n: git-commit advice messages\n + i18n: git-commit \"enter the commit message\" message\n + i18n: git-commit print_summary messages\n + i18n: git-commit formatting messages\n + i18n: git-commit \"middle of a merge\" message\n + i18n: git-commit basic messages\n + i18n: git-checkout \"Switched to a .. branch\" message\n + i18n: git-checkout \"HEAD is now at\" message\n + i18n: git-checkout describe_detached_head messages\n + i18n: git-checkout: our/their version message\n + i18n: git-checkout basic messages\n + i18n: git-branch \"(no branch)\" message\n + i18n: git-branch \"git branch -v\" messages\n + i18n: git-branch \"Deleted branch [...]\" message\n + i18n: git-branch \"remote branch '%s' not found\" message\n + i18n: git-branch basic messages\n + i18n: git-add \"Unstaged changes\" message\n + i18n: git-add \"remove '%s'\" message\n + i18n: git-add \"did not match any files\" message\n + i18n: git-add \"The following paths are ignored\" message\n + i18n: git-add basic messages\n + i18n: git-clone \"Cloning into\" message\n + i18n: git-clone \"Cloning into\" message\n + i18n: git-clone basic messages\n + i18n: git-init \"Initialized [...] repository\" message\n + i18n: git-init basic messages\n\nWill merge.\n\n--------------------------------------------------\n[Discarded]\n\n* jc/diff-dotdot (2011-03-23) 2 commits\n . warn use of \"git diff A..B\"\n . diff: remove dead code that flips arguments order\n\nThis was 1/4 tongue-in-cheek. Now we seem to have a handful of volunteer\ncluebat bearers, and I wouldn't have to worry about this topic very much.\n\n* jh/merge-sans-branch (2011-02-10) 4 commits\n . merge: add support for merging from upstream by default\n . merge: introduce per-branch-configuration helper function\n . merge: introduce setup_merge_commit helper function\n . merge: update the usage information to be more modern\n\nI've been wanting to move this forward for quite some time but \nended up redoing it myself (see jc/merge-sans-branch)\n"},{"id":"164841","messageId":"7vvcyyhq9q.fsf@alter.siamese.dyndns.org","threadId":"26952","inReplyTo":"7v62qzhqp4.fsf@alter.siamese.dyndns.org","subject":"Let's make our cycles shorter","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-03-31T22:35:45Z","receivedAt":"2011-03-31T22:35:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"I've been aiming for 6-8 week cycles but the 1.7.5 cycle ended up being\nway longer than that.  I just tagged a -rc0 and it will be mirroring out,\nand today's \"What's cooking\" has annotations on topics in flight that I\nexpect to be in the -rc1.\n\nThis message is primarily meant to be a reminder to myself and also to\nclarify my intentions.  I'd like one cycle of ours to look roughly like\nthis:\n\n - 1.7.5 is released.\n\n - Week 1: post release clean-up.  People are strongly encouraged to give\n   the highest priority to the regression fixes for the most recent\n   release.\n\n - Week 2: new features, restructuring, non-regression bugfixes start to\n   flow in and graduate in preparation for 1.7.6.  Some may graduate from\n   'next' before 1.7.5 to master, some may be newly queued through 'pu' to\n   'next'.\n\n - Week N: 1.7.6-rc0 is tagged.  Examine topics in 'next' that are still\n   not in 'master' and decide which way they should go, either included in\n   1.7.6-rc1 or wait until the next cycle.\n\n - Week N+1: 1.7.6-rc1 is tagged with (a subset of) candidate topics we\n   decided previous week.\n\n   At this point, people are again strongly encouraged to give the highest\n   priority to the regression fixes for the upcoming release.\n\n - Week N+2: 1.7.6-rc2 is tagged.\n\n - Week X: 1.7.6 is released.\n\nHistorically we have done at least two rc releases, and often three, so I\nwould expect X is at least N+3 but possibly N+4.  Since I want to have at\nmost an 8-week cycle, it would mean N=4 or 5, so we have three to four\nweeks to concentrate the real development for the next release.\n\nWe are at \"Week N\" for this cycle as of today.\n\nThis of course does not mean that people are forbidden from working on or\ndiscussing anything but regression fixes during the rc and post-release\nperiod.  It may take longer than a month to stabilize for a large-ish\ntopic to be properly reviewed, discussed and guinea-pigged in 'next'.  \n\nSo during Weeks N thru X, there may appear new topics in flight and I may\nend up queueing them in 'pu' or even move some of them to 'next', with an\nunderstanding that they will not be part of the current cycle, but are\nqueued merely to make it easier for people interested in the new topic to\ntry out and discuss ideas for the next cycle.  Also handling these new\ntopics during the rc period will receive much lower priority and time from\nme.\n\nI hope all the above sound sensible.  Thanks.\n"},{"id":"164883","messageId":"b6975fdc80a338e47c1426e8bf8450b68130b84a.1301664623.git.git@drmicha.warpmail.net","threadId":"26952","inReplyTo":"7v62qzhqp4.fsf@alter.siamese.dyndns.org","subject":"[PATCH] git diff -D: omit the preimage of deletes","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-04-01T13:31:38Z","receivedAt":"2011-04-01T13:31:38Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Introduce the -D/--irreversible-delete option which omits the diff for\ntotal deletes. It is similar to -M,-C in its output but irreversible in\nthe sense that the resulting patch can not be reversed (-R).\n\nWhen used in connection with -B, omit the diff of the deletion part of a\ncomplete rewrite.\n\nHelped-by: Junio C Hamano <gitster@pobox.com>\nSigned-off-by: Michael J Gruber <git@drmicha.warpmail.net>\n---\n Documentation/diff-options.txt |   10 +++++++++\n diff.c                         |   14 +++++++++---\n diff.h                         |    1 +\n t/t4022-diff-rewrite.sh        |   43 +++++++++++++++++++++++++++++++++++++++-\n 4 files changed, 63 insertions(+), 5 deletions(-)\n\ndiff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt\nindex c93124b..4760d7a 100644\n--- a/Documentation/diff-options.txt\n+++ b/Documentation/diff-options.txt\n@@ -259,6 +259,16 @@ endif::git-log[]\n \tprojects, so use it with caution.  Giving more than one\n \t`-C` option has the same effect.\n \n+-D::\n+--irreversible-delete::\n+\tOmit the preimage for deletes, i.e. print only the header but not\n+\tthe diff between the preimage and `/dev/null`. The resulting patch\n+\tis irreversible in the sense that it can not be applied in reverse\n+\t(-R).\n++\n+When used together with `-B`, omit also the preimage in the deletion part\n+of a delete/create pair.\n+\n -l<num>::\n \tThe `-M` and `-C` options require O(n^2) processing time where n\n \tis the number of potential rename/copy targets.  This\ndiff --git a/diff.c b/diff.c\nindex 5422c43..9ea1de1 100644\n--- a/diff.c\n+++ b/diff.c\n@@ -1943,7 +1943,11 @@ static void builtin_diff(const char *name_a,\n \t\t}\n \t}\n \n-\tif (!DIFF_OPT_TST(o, TEXT) &&\n+\tif (o->irreversible_delete && lbl[1][0] == '/') {\n+\t\tfprintf(o->file, \"%s\", header.buf);\n+\t\tstrbuf_reset(&header);\n+\t\tgoto free_ab_and_return;\n+\t} else if (!DIFF_OPT_TST(o, TEXT) &&\n \t    ( (!textconv_one && diff_filespec_is_binary(one)) ||\n \t      (!textconv_two && diff_filespec_is_binary(two)) )) {\n \t\tif (fill_mmfile(&mf1, one) < 0 || fill_mmfile(&mf2, two) < 0)\n@@ -1963,8 +1967,7 @@ static void builtin_diff(const char *name_a,\n \t\t\tfprintf(o->file, \"%sBinary files %s and %s differ\\n\",\n \t\t\t\tline_prefix, lbl[0], lbl[1]);\n \t\to->found_changes = 1;\n-\t}\n-\telse {\n+\t} else {\n \t\t/* Crazy xdl interfaces.. */\n \t\tconst char *diffopts = getenv(\"GIT_DIFF_OPTS\");\n \t\txpparam_t xpp;\n@@ -3160,6 +3163,9 @@ int diff_opt_parse(struct diff_options *options, const char **av, int ac)\n \t\t\treturn error(\"invalid argument to -M: %s\", arg+2);\n \t\toptions->detect_rename = DIFF_DETECT_RENAME;\n \t}\n+\telse if (!strcmp(arg, \"-D\") || !strcmp(arg, \"--irreversible-delete\")) {\n+\t\toptions->irreversible_delete = 1;\n+\t}\n \telse if (!prefixcmp(arg, \"-C\") || !prefixcmp(arg, \"--find-copies=\") ||\n \t\t !strcmp(arg, \"--find-copies\")) {\n \t\tif (options->detect_rename == DIFF_DETECT_COPY)\n@@ -4205,7 +4211,7 @@ void diffcore_std(struct diff_options *options)\n \t\t\tdiffcore_break(options->break_opt);\n \t\tif (options->detect_rename)\n \t\t\tdiffcore_rename(options);\n-\t\tif (options->break_opt != -1)\n+\t\tif (options->break_opt != -1 && !options->irreversible_delete)\n \t\t\tdiffcore_merge_broken();\n \t}\n \tif (options->pickaxe)\ndiff --git a/diff.h b/diff.h\nindex 310bd6b..11d13cf 100644\n--- a/diff.h\n+++ b/diff.h\n@@ -104,6 +104,7 @@ struct diff_options {\n \tint interhunkcontext;\n \tint break_opt;\n \tint detect_rename;\n+\tint irreversible_delete;\n \tint skip_stat_unmatch;\n \tint line_termination;\n \tint output_format;\ndiff --git a/t/t4022-diff-rewrite.sh b/t/t4022-diff-rewrite.sh\nindex 2a537a2..c00a94b 100755\n--- a/t/t4022-diff-rewrite.sh\n+++ b/t/t4022-diff-rewrite.sh\n@@ -11,7 +11,9 @@ test_expect_success setup '\n \ttr \\\n \t  \"abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ\" \\\n \t  \"nopqrstuvwxyzabcdefghijklmNOPQRSTUVWXYZABCDEFGHIJKLM\" \\\n-\t  <\"$TEST_DIRECTORY\"/../COPYING >test\n+\t  <\"$TEST_DIRECTORY\"/../COPYING >test &&\n+\techo \"to be deleted\" >test2 &&\n+\tgit add test2\n \n '\n \n@@ -25,5 +27,44 @@ test_expect_success 'detect rewrite' '\n \n '\n \n+cat >expect <<EOF\n+diff --git a/test2 b/test2\n+deleted file mode 100644\n+index 4202011..0000000\n+--- a/test2\n++++ /dev/null\n+@@ -1 +0,0 @@\n+-to be deleted\n+EOF\n+test_expect_success 'show deletion diff without -D' '\n+\n+\trm test2 &&\n+\tgit diff -- test2 >actual &&\n+\ttest_cmp expect actual\n+'\n+\n+cat >expect <<EOF\n+diff --git a/test2 b/test2\n+deleted file mode 100644\n+index 4202011..0000000\n+EOF\n+test_expect_success 'suppress deletion diff with -D' '\n+\n+\tgit diff -D -- test2 >actual &&\n+\ttest_cmp expect actual\n+'\n+\n+test_expect_success 'show deletion diff with -B' '\n+\n+\tgit diff -B -- test >actual &&\n+\tgrep \"Linus Torvalds\" actual\n+'\n+\n+test_expect_success 'suppress deletion diff with -B -D' '\n+\n+\tgit diff -B -D -- test >actual &&\n+\tgrep -v \"Linus Torvalds\" actual\n+'\n+\n test_done\n \n-- \n1.7.4.2.668.gba03a4\n"},{"id":"164896","messageId":"20110401152623.GA4553@sigill.intra.peff.net","threadId":"26952","inReplyTo":"7v62qzhqp4.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Mar 2011, #06; Thu, 31)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-04-01T15:26:23Z","receivedAt":"2011-04-01T15:26:23Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Mar 31, 2011 at 03:26:31PM -0700, Junio C Hamano wrote:\n\n> * jk/maint-remote-mirror-safer (2011-03-30) 3 commits\n>  - remote: deprecate --mirror\n>  - remote: separate the concept of push and fetch mirrors\n>  - remote: disallow some nonsensical option combinations\n> \n> * jk/notes-ui-updates (2011-03-30) 7 commits\n>  - log/pretty-options: Document --[no-]notes and deprecate old notes options\n>  - revision.c: make --no-notes reset --notes list\n>  - revision.c: support --notes command-line option\n>  - notes: refactor display notes default handling\n>  - notes: refactor display notes extra refs field\n>  - revision.c: refactor notes ref expansion\n>  - notes: make expand_notes_ref globally accessible\n\nBoth probably post-1.7.5 material. I am of course tempted to get new\noptions in place ASAP (since the sooner they are in, the sooner script\nwriters can say \"they are in long enough\" and start using them).  But I\ndon't think either is critical.\n\n> * jk/edit-notes-in-commit-log (2011-03-07) 2 commits\n>  - [wip] commit: allow editing notes in commit message editor\n>  - notes: make expand_notes_ref globally accessible\n\nYou may want to drop this for now. The bottom one is in\njk/notes-ui-updates, which hopefully will go to master soon after 1.7.5,\nand the top one is going to be rewritten.\n\n> * jk/maint-merge-rename-create (2011-03-25) 3 commits\n>   (merged to 'next' on 2011-03-31 at b9bc9f1)\n>  + merge: turn on rewrite detection\n>  + merge: handle renames with replacement content\n>  + t3030: fix accidental success in symlink rename\n> \n> May merge before rc1, but it is Ok to wait.\n\nI would hold off on this. I _think_ it's fine, but I would really prefer\nfor it to get more exposure in 'next' to shake out any bugs.\n\n> * jk/pull-into-empty (2011-03-25) 2 commits\n>   (merged to 'next' on 2011-03-31 at d4dd598)\n>  + pull: do not clobber untracked files on initial pull\n>  + merge: merge unborn index before setting ref\n> \n> This is low impact, isolated, and has no risk of major regression. Will\n> merge before rc1.\n\nAgreed.\n\n> * jc/add-u-migration (2011-03-22) 3 commits\n>  - add: make \"add -u/-A\" update full tree without pathspec (step 3)\n>  - add: make \"add -u/-A\" update full tree without pathspec (step 2)\n>   (merged to 'next' on 2011-03-31 at 962e058)\n>  + add: make \"add -u/-A\" update full tree without pathspec\n> \n> The bottom one is a necessary first step toward the UI clean-up planned\n> for 1.8.0 which we discussed in length in the earlier part of the cycle;\n> the change is low impact, isolated, and has no risk of breaking the system\n> as a whole, but I would wait until the \":/\" magic pathspec materializes,\n> as the advice message would have to become different, and the way to get\n> more stable semantics will become more direct.\n\nI have been meaning to look closer at this. Were you wanting to get the\nfirst stage of the transition into 1.7.5?\n\n> * jk/progress-with-pager (2011-03-24) 4 commits\n>  - diff: turn on rename detection progress reporting\n>  - show: turn on rename detection progress reporting\n>  - progress: use pager's original_stderr if available\n>  - pager: save the original stderr when redirecting to pager\n> \n> Will cook until 1.7.5 final.\n\nI'm not sure if this whole thing should be scrapped. There are potential\nproblems with starting a pager that wants to grab the whole screen\n(i.e., not less). Maybe it would be enough to have a pager.noprogress\noption for people who use such a pager.\n\n-Peff\n"},{"id":"164897","messageId":"7vbp0phpmx.fsf@alter.siamese.dyndns.org","threadId":"26952","inReplyTo":"20110401152623.GA4553@sigill.intra.peff.net","subject":"Re: What's cooking in git.git (Mar 2011, #06; Thu, 31)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-04-01T17:01:42Z","receivedAt":"2011-04-01T17:01:42Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Thu, Mar 31, 2011 at 03:26:31PM -0700, Junio C Hamano wrote:\n>\n> (... parts that I do not disagree with are omitted ...)\n>\n>> * jc/add-u-migration (2011-03-22) 3 commits\n>>  - add: make \"add -u/-A\" update full tree without pathspec (step 3)\n>>  - add: make \"add -u/-A\" update full tree without pathspec (step 2)\n>>   (merged to 'next' on 2011-03-31 at 962e058)\n>>  + add: make \"add -u/-A\" update full tree without pathspec\n>> \n>> The bottom one is a necessary first step toward the UI clean-up planned\n>> for 1.8.0 which we discussed in length in the earlier part of the cycle;\n>> the change is low impact, isolated, and has no risk of breaking the system\n>> as a whole, but I would wait until the \":/\" magic pathspec materializes,\n>> as the advice message would have to become different, and the way to get\n>> more stable semantics will become more direct.\n>\n> I have been meaning to look closer at this. Were you wanting to get the\n> first stage of the transition into 1.7.5?\n\nI was tempted to but I think it would be far more pleasant if the first\nstep were to add the warning against \"add -u\" without pathspec that is ran\nfrom a subdirectory to advise \"if you meant 'from here', say '.', if you\nmeant 'everywhere', say ':/'---for now we pretend you said '.' to match\nthe traditional behaviour.\"\n\nIt is adding even more confusion to add the \"in this repository, 'add -u'\nis tree-wide\" configuration variable without giving people who need to\noverride that in unfamiliar repositories (read: scripts).\n\nRight now, we don't have a good advice to force the tree-wide behaviour\nother than \"cd $(git rev-parse --show-cdup)/. && git add -u\", which is\nquite a mouthful.\n\nWe know how the magic \"this pathspec is from the root\" should work, and I\nthink we even saw \"should look like this\" patches, but haven't applied to\nany branch so far yet.\n\n>> * jk/progress-with-pager (2011-03-24) 4 commits\n>>  - diff: turn on rename detection progress reporting\n>>  - show: turn on rename detection progress reporting\n>>  - progress: use pager's original_stderr if available\n>>  - pager: save the original stderr when redirecting to pager\n>> \n>> Will cook until 1.7.5 final.\n>\n> I'm not sure if this whole thing should be scrapped. There are potential\n> problems with starting a pager that wants to grab the whole screen\n> (i.e., not less). Maybe it would be enough to have a pager.noprogress\n> option for people who use such a pager.\n\nPerhaps.  With \"Will cook until\" I only meant \"will not graduate until\"; I\nwas not even making any prediction after 1.7.5 in the message.\n\nThanks.\n"},{"id":"164898","messageId":"20110401170610.GA23014@sigill.intra.peff.net","threadId":"26952","inReplyTo":"7vbp0phpmx.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Mar 2011, #06; Thu, 31)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-04-01T17:06:10Z","receivedAt":"2011-04-01T17:06:10Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Apr 01, 2011 at 10:01:42AM -0700, Junio C Hamano wrote:\n\n> >> * jc/add-u-migration (2011-03-22) 3 commits\n> >>  - add: make \"add -u/-A\" update full tree without pathspec (step 3)\n> >>  - add: make \"add -u/-A\" update full tree without pathspec (step 2)\n> >>   (merged to 'next' on 2011-03-31 at 962e058)\n> >>  + add: make \"add -u/-A\" update full tree without pathspec\n> [...]\n> > I have been meaning to look closer at this. Were you wanting to get the\n> > first stage of the transition into 1.7.5?\n> \n> I was tempted to but I think it would be far more pleasant if the first\n> step were to add the warning against \"add -u\" without pathspec that is ran\n> from a subdirectory to advise \"if you meant 'from here', say '.', if you\n> meant 'everywhere', say ':/'---for now we pretend you said '.' to match\n> the traditional behaviour.\"\n\nYes, I think that is definitely the right first step.\n\n> It is adding even more confusion to add the \"in this repository, 'add -u'\n> is tree-wide\" configuration variable without giving people who need to\n> override that in unfamiliar repositories (read: scripts).\n> \n> Right now, we don't have a good advice to force the tree-wide behaviour\n> other than \"cd $(git rev-parse --show-cdup)/. && git add -u\", which is\n> quite a mouthful.\n> \n> We know how the magic \"this pathspec is from the root\" should work, and I\n> think we even saw \"should look like this\" patches, but haven't applied to\n> any branch so far yet.\n\nThat reasoning makes sense. Let's let the :/ patches develop and cook\nfor post-1.7.5, then, and worry about it in the next cycle when we can\nbuild on top of them.\n\n-Peff\n"},{"id":"164910","messageId":"7vbp0pg4d7.fsf@alter.siamese.dyndns.org","threadId":"26952","inReplyTo":"b6975fdc80a338e47c1426e8bf8450b68130b84a.1301664623.git.git@drmicha.warpmail.net","subject":"Re: [PATCH] git diff -D: omit the preimage of deletes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-04-01T19:26:28Z","receivedAt":"2011-04-01T19:26:28Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber <git@drmicha.warpmail.net> writes:\n\n> diff --git a/diff.c b/diff.c\n> index 5422c43..9ea1de1 100644\n> --- a/diff.c\n> +++ b/diff.c\n> @@ -4205,7 +4211,7 @@ void diffcore_std(struct diff_options *options)\n>  \t\t\tdiffcore_break(options->break_opt);\n>  \t\tif (options->detect_rename)\n>  \t\t\tdiffcore_rename(options);\n> -\t\tif (options->break_opt != -1)\n> +\t\tif (options->break_opt != -1 && !options->irreversible_delete)\n>  \t\t\tdiffcore_merge_broken();\n>  \t}\n>  \tif (options->pickaxe)\n\nThanks, but this hunk looks fishy.\n\nWhat happens to a path that was tentatively broken for the purpose of\nrename detection with -B -M (break to match with another file) but then\nfound to be with no counterpart after all after running diffcore_rename(),\nwhich now needs to get merged back?  Such a path is shown as a normal\npatch when the dissimlarity between the preimage and postimage is not\nlarge enough and merge-broken is the step that combines such a broken but\nunmatched pair back.\n\nI would have expected that the patch relative to jc/diff-irreversible-delete\ntopic would consist only of changes to diff.c:emit_rewrite_diff(), docs\nand tests.\n"},{"id":"164979","messageId":"7vtyefg8fi.fsf@alter.siamese.dyndns.org","threadId":"26952","inReplyTo":"7vbp0pg4d7.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] git diff -D: omit the preimage of deletes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-04-03T06:23:13Z","receivedAt":"2011-04-03T06:23:13Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> I would have expected that the patch relative to jc/diff-irreversible-delete\n> topic would consist only of changes to diff.c:emit_rewrite_diff(), docs\n> and tests.\n\nHere is an \"in other words\" follow-up.  Your tests looked reasonable (and\npass with this patch on top of what has been queued in 'pu').\n\n\n diff.c |    7 +++++--\n 1 files changed, 5 insertions(+), 2 deletions(-)\n\ndiff --git a/diff.c b/diff.c\nindex 5c66a53..05f443c 100644\n--- a/diff.c\n+++ b/diff.c\n@@ -572,11 +572,14 @@ static void emit_rewrite_diff(const char *name_a,\n \t\tline_prefix, metainfo, a_name.buf, name_a_tab, reset,\n \t\tline_prefix, metainfo, b_name.buf, name_b_tab, reset,\n \t\tline_prefix, fraginfo);\n-\tprint_line_count(o->file, lc_a);\n+\tif (!o->irreversible_delete)\n+\t\tprint_line_count(o->file, lc_a);\n+\telse\n+\t\tfprintf(o->file, \"?,?\");\n \tfprintf(o->file, \" +\");\n \tprint_line_count(o->file, lc_b);\n \tfprintf(o->file, \" @@%s\\n\", reset);\n-\tif (lc_a)\n+\tif (lc_a && !o->irreversible_delete)\n \t\temit_rewrite_lines(&ecbdata, '-', data_one, size_one);\n \tif (lc_b)\n \t\temit_rewrite_lines(&ecbdata, '+', data_two, size_two);\n"},{"id":"164980","messageId":"7vpqp3g7pb.fsf@alter.siamese.dyndns.org","threadId":"26952","inReplyTo":"7vtyefg8fi.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] git diff -D: omit the preimage of deletes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-04-03T06:38:56Z","receivedAt":"2011-04-03T06:38:56Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Junio C Hamano <gitster@pobox.com> writes:\n>\n>> I would have expected that the patch relative to jc/diff-irreversible-delete\n>> topic would consist only of changes to diff.c:emit_rewrite_diff(), docs\n>> and tests.\n>\n> Here is an \"in other words\" follow-up.  Your tests looked reasonable (and\n> pass with this patch on top of what has been queued in 'pu').\n\nAnd this is the documentation part, based on your version but somewhat\nrewritten.  Your version said \"cannot be applied with -R\", but at the\nmechanical application level, the format is deliberately designed to make\n`patch` and `git apply` to fail, and I think that should be mentioned\ntogether with the reason why such an option exists (i.e. for human eyeball\nconsumption).\n\nI'll squash these two to what is queued in 'pu'.  We may want to polish it\nagain after 1.7.5 but I think it is in much better shape now.\n\nThanks.\n\n Documentation/diff-options.txt |   13 +++++++++++++\n 1 files changed, 13 insertions(+), 0 deletions(-)\n\ndiff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt\nindex c93124b..30a00d3 100644\n--- a/Documentation/diff-options.txt\n+++ b/Documentation/diff-options.txt\n@@ -259,6 +259,19 @@ endif::git-log[]\n \tprojects, so use it with caution.  Giving more than one\n \t`-C` option has the same effect.\n \n+-D::\n+--irreversible-delete::\n+\tOmit the preimage for deletes, i.e. print only the header but not\n+\tthe diff between the preimage and `/dev/null`. The resulting patch\n+\tis not meant to be applied with `patch` nor `git apply`; this is\n+\tsolely for people who want to just concentrate on reviewing the\n+\ttext after the change. In addition, the output obviously lack\n+\tenough information to apply such a patch in reverse, even manually,\n+\thence the name of the option.\n++\n+When used together with `-B`, omit also the preimage in the deletion part\n+of a delete/create pair.\n+\n -l<num>::\n \tThe `-M` and `-C` options require O(n^2) processing time where n\n \tis the number of potential rename/copy targets.  This\n"},{"id":"164989","messageId":"4D986D4B.80208@drmicha.warpmail.net","threadId":"26952","inReplyTo":"7vbp0pg4d7.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] git diff -D: omit the preimage of deletes","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-04-03T12:51:23Z","receivedAt":"2011-04-03T12:51:23Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Junio C Hamano venit, vidit, dixit 01.04.2011 21:26:\n> Michael J Gruber <git@drmicha.warpmail.net> writes:\n> \n>> diff --git a/diff.c b/diff.c\n>> index 5422c43..9ea1de1 100644\n>> --- a/diff.c\n>> +++ b/diff.c\n>> @@ -4205,7 +4211,7 @@ void diffcore_std(struct diff_options *options)\n>>  \t\t\tdiffcore_break(options->break_opt);\n>>  \t\tif (options->detect_rename)\n>>  \t\t\tdiffcore_rename(options);\n>> -\t\tif (options->break_opt != -1)\n>> +\t\tif (options->break_opt != -1 && !options->irreversible_delete)\n>>  \t\t\tdiffcore_merge_broken();\n>>  \t}\n>>  \tif (options->pickaxe)\n> \n> Thanks, but this hunk looks fishy.\n> \n> What happens to a path that was tentatively broken for the purpose of\n> rename detection with -B -M (break to match with another file) but then\n> found to be with no counterpart after all after running diffcore_rename(),\n> which now needs to get merged back?  Such a path is shown as a normal\n> patch when the dissimlarity between the preimage and postimage is not\n> large enough and merge-broken is the step that combines such a broken but\n> unmatched pair back.\n> \n> I would have expected that the patch relative to jc/diff-irreversible-delete\n> topic would consist only of changes to diff.c:emit_rewrite_diff(), docs\n> and tests.\n> \n\nI think I misunderstood what you intended \"-B -D\" to do (and I even\ndidn't know about -B until -D came up; my understanding of \"-B\" is still\nfishy). I just didn't want to let this die before 1.7.5. Thanks for\ntaking this up and clarifying it.\n\nMichael\n"},{"id":"166294","messageId":"BANLkTinzXLK0dHYjBMpBgLqZ_7KNHeu3uA@mail.gmail.com","threadId":"26952","inReplyTo":"7vvcyyhq9q.fsf@alter.siamese.dyndns.org","subject":"Re: Let's make our cycles shorter","fromName":"Sebastien Douche","fromEmail":"sdouche@gmail.com","sentAt":"2011-04-25T00:34:58Z","receivedAt":"2011-04-25T00:34:58Z","isPatch":false,"sender":{"key":"sdouche@gmail.com","avatar":"https://gravatar.com/avatar/1b4a6cb11f6237ff9dc78b953ce48e416afa42e947143e14273cdc2c7f6f9c1a?d=mp&s=160"},"body":"On Fri, Apr 1, 2011 at 00:35, Junio C Hamano <gitster@pobox.com> wrote:\n\nHi Junio,\nI was surprised to not read response, it's having sensitive impact on\nthe project. Junio, it's effective now?\n\n\n-- \nSebastien Douche <sdouche@gmail.com>\nTwitter: @sdouche (agile, lean, python, git, open source)\n"},{"id":"166317","messageId":"7v1v0ql0uw.fsf@alter.siamese.dyndns.org","threadId":"26952","inReplyTo":"BANLkTinzXLK0dHYjBMpBgLqZ_7KNHeu3uA@mail.gmail.com","subject":"Re: Let's make our cycles shorter","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-04-25T17:03:35Z","receivedAt":"2011-04-25T17:03:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sebastien Douche <sdouche@gmail.com> writes:\n\n> On Fri, Apr 1, 2011 at 00:35, Junio C Hamano <gitster@pobox.com> wrote:\n> ...\n> I was surprised to not read response, it's having sensitive impact on\n> the project.\n\nHmm, what sensitive impact on which project do you have in mind?\n\n> Junio, it's effective now?\n\nThe structure of clean-up, development, freeze and then release has always\nbeen in effect in this project, but historically the duration of the\ndevelopment stretch varied a lot from cycle to cycle.\n\nI just spelled the structure out for the next cycle, and tried to give\nsome predictable bounds to that elastic development stretch, in order to\nforce myself to stick to a schedule in which we can make measurable\nprogress in reasonable amount of time.\n\nIt does not mean that we won't be tackling issues that will take more than\nN weeks to perfect.  Either a topic gets polished enough in a single cycle\nto graduate to 'master' before -rc0, or it keeps cooking in 'next' during\nthe feature freeze, and will attempt to be in the release after that.\n\nI've tentatively set the following dates on my calendar, based on 9-week\ncycle:\n\n - Today is the beginning of week #1 for this cycle.\n\n - The entire month of May 2011 will be the development stretch (lasting\n   up to Week #5 that ends May 29th).\n\n - Aim to tag 1.7.6-rc0 on June 1st, 2011, -rc1 on 8th, -rc2 on 15th.\n\n - Either tag 1.7.6 final on 19th or have -rc3 on 22nd and final on 26th\n   of June.\n\nIf you happen to use Google Calendar, you can paste:\n\n    jfgbl2mrlipp4pb6ieih0qr3so@group.calendar.google.com\n\nin the \"Other calendars\" box (where a gray \"Add a friend's calendar\"\nappears), but you won't be missing much even if you don't (I only have\nweek numbers and the target tagging dates, nothing more interesting than\nthat).\n"},{"id":"169908","messageId":"BANLkTim4STXM-r0aujsmu4YeJ9WLt+Y_VEvZ_rG5PEqLnAAq6Q@mail.gmail.com","threadId":"26952","inReplyTo":"7v1v0ql0uw.fsf@alter.siamese.dyndns.org","subject":"Re: Let's make our cycles shorter","fromName":"Sebastien Douche","fromEmail":"sdouche@gmail.com","sentAt":"2011-06-13T00:45:36Z","receivedAt":"2011-06-13T00:45:36Z","isPatch":false,"sender":{"key":"sdouche@gmail.com","avatar":"https://gravatar.com/avatar/1b4a6cb11f6237ff9dc78b953ce48e416afa42e947143e14273cdc2c7f6f9c1a?d=mp&s=160"},"body":"On Mon, Apr 25, 2011 at 19:03, Junio C Hamano <gitster@pobox.com> wrote:\n>> I was surprised to not read response, it's having sensitive impact on\n>> the project.\n>\n> Hmm, what sensitive impact on which project do you have in mind?\n\nShort cycle means less time to write code for the next release, the\n\"frame\" to add feature is reduced. I'm surely wrong, Git is a stable\nproject and well managed (with 4 branches: unstable, integration, next\nstable & stable).\n\n> I just spelled the structure out for the next cycle, and tried to give\n> some predictable bounds to that elastic development stretch, in order to\n> force myself to stick to a schedule in which we can make measurable\n> progress in reasonable amount of time.\n\nCool :).\n\n\n-- \nSebastien Douche <sdouche@gmail.com>\nTwitter : @sdouche\n"}]}