{"thread":{"id":"24567","subject":"What's cooking in git.git (Jul 2010, #05; Wed, 28)","startedAt":"2010-07-29T04:00:16Z","lastAt":"2010-08-05T19:35:45Z","messageCount":12,"participants":["Junio C Hamano","Jeff King","Jonathan Nieder","Matthieu Moy"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"146690","messageId":"7vvd7zuecv.fsf@alter.siamese.dyndns.org","threadId":"24567","inReplyTo":null,"subject":"What's cooking in git.git (Jul 2010, #05; Wed, 28)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-07-29T04:00:16Z","receivedAt":"2010-07-29T04:00:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Here are the topics that have been cooking.  Commits prefixed with '-' are\nonly in 'pu' while commits prefixed with '+' are in 'next'.  The ones\nmarked with '.' do not appear in any of the integration branches, but I am\nstill holding onto them.\n\nNow that the latest feature release 1.7.2 is out, we should rewind and\nrebuild 'next' and start cooking new topics.\n\n--------------------------------------------------\n[New Topics]\n\n* ab/test-coverage (2010-07-26) 8 commits\n - Makefile: make gcov invocation configurable\n - t/README: Add a note about the dangers of coverage chasing\n - t/README: A new section about test coverage\n - Makefile: Add cover_db_html target\n - Makefile: Add cover_db target\n - Makefile: Split out the untested functions target\n - Makefile: Include subdirectories in \"make cover\" reports\n - gitignore: Ignore files generated by \"make coverage\"\n\n* ab/test-no-skip (2010-07-28) 5 commits\n - t/README: Update \"Skipping tests\" to align with best practices\n - t/t7800-difftool.sh: Skip with prereq on no PERL\n - t/t5800-remote-helpers.sh: Skip with prereq on python <2.4\n - t/t4004-diff-rename-symlink.sh: use three-arg <prereq>\n - tests: implicitly skip SYMLINKS tests using <prereq>\n\n* bc/use-more-hardlinks-in-install (2010-07-23) 2 commits\n - Makefile: make hard/symbolic links for non-builtins too\n - Makefile: link builtins residing in bin directory to main git binary too\n\n* cc/find-commit-subject (2010-07-22) 6 commits\n - blame: use find_commit_subject() instead of custom code\n - merge-recursive: use find_commit_subject() instead of custom code\n - bisect: use find_commit_subject() instead of custom code\n - revert: rename variables related to subject in get_message()\n - revert: refactor code to find commit subject in find_commit_subject()\n - revert: fix off by one read when searching the end of a commit subject\n\n* gb/shell-ext (2010-07-28) 3 commits\n - Add sample commands for git-shell\n - Add interactive mode to git-shell for user-friendliness\n - Allow creation of arbitrary git-shell commands\n\n* jc/log-grep (2010-07-19) 1 commit\n - git log: add -G<regexp> that greps in the patch text\n\n* jh/clean-exclude (2010-07-20) 2 commits\n - Add test for git clean -e.\n - Add -e/--exclude to git-clean.\n\n* jh/use-test-must-fail (2010-07-20) 1 commit\n - Convert \"! git\" to \"test_must_fail git\"\n\n* jn/apply-filename-with-sp (2010-07-23) 4 commits\n - apply: Handle traditional patches with space in filename\n - t4135 (apply): use expand instead of pr for portability\n - tests: Test how well \"git apply\" copes with weird filenames\n - apply: Split quoted filename handling into new function\n\n* jn/fix-abbrev (2010-07-27) 3 commits\n - examples/commit: use --abbrev for commit summary\n - checkout, commit: remove confusing assignments to rev.abbrev\n - archive: abbreviate substituted commit ids again\n\n* jn/maint-setup-fix (2010-07-24) 10 commits\n - setup: split off a function to handle ordinary .git directories\n - Revert \"rehabilitate 'git index-pack' inside the object store\"\n - setup: do not forget working dir from subdir of gitdir\n - setup: split off get_device_or_die helper\n - setup: split off a function to handle hitting ceiling in repo search\n - setup: split off code to handle stumbling upon a repository\n - setup: split off a function to checks working dir for .git file\n - setup: split off $GIT_DIR-set case from setup_git_directory_gently\n - tests: try git apply from subdir of toplevel\n - t1501 (rev-parse): clarify\n\n* jn/rebase-rename-am (2008-11-10) 5 commits\n - rebase: protect against diff.renames configuration\n - t3400 (rebase): whitespace cleanup\n - Teach \"apply --index-info\" to handle rename patches\n - t4150 (am): futureproof against failing tests\n - t4150 (am): style fix\n\n* ml/rebase-x-strategy (2010-07-29) 1 commit\n - rebase: support -X to pass through strategy options\n\n* mm/shortopt-detached (2010-07-28) 4 commits\n - Allow detached form for --glob, --branches, --tags and --remote.\n - Allow detached form (e.g. \"git log --grep foo\") in log options.\n - Allow detached form for git diff --stat-name-width and --stat-width.\n - Allow detached form (e.g. \"-S foo\" instead of \"-Sfoo\") for diff options\n\n* nd/fix-sparse-checkout (2010-07-26) 3 commits\n - Mark new entries skip-worktree appropriately\n - unpack-trees.c: Do not check ce_stage in will_have_skip_worktree()\n - Fix sparse checkout not removing files from index\n\n* tr/ab-i18n-fix (2010-07-25) 1 commit\n - tests: locate i18n lib&data correctly under --valgrind\n (this branch uses ab/i18n.)\n\n* tr/maint-no-unquote-plus (2010-07-24) 1 commit\n - Do not unquote + into ' ' in URLs\n\n* tr/xsize-bits (2010-07-28) 1 commit\n - xsize_t: check whether we lose bits\n\n* vs/doc-spell (2010-07-20) 1 commit\n - Documentation: spelling fixes\n\n--------------------------------------------------\n[Stalled -- would discard unless there are some movements soon]\n\n* by/log-range-diff (2010-07-12) 18 commits\n . Minimum fix to make by/log-range-diff topic at least compile\n . add test cases for '--graph' of line level log\n . line.c output the '--graph' padding before each line\n . add parent rewrite feature to line level log\n . make rewrite_parents an external function\n . some document update\n . add two test cases\n . add --always-print option\n . map/print ranges along traversing the history topologically\n . print the line log\n . map/take range to parent\n . add range clone functions\n . export three functions from diff.c\n . parse the -L options\n . refactor parse_loc\n . add the basic data structure for line level history\n . parse-options: add two helper functions\n . parse-options: stop when encounter a non-option\n\nPerhaps a re-roll is coming?  I suspect that we would have some overlaps\nto mm/shortopt-detached topic.\n\n* ps/gitweb-soc (2010-06-02) 2 commits\n  (merged to 'next' on 2010-06-13 at 92245ae)\n + git-instaweb: Add option to reuse previous config file\n + Makefile: Use $(sharedir)/gitweb for target 'install-gitweb'\n\nIf we are going to have a configuration variable to control this, I\nstrongly suspect that --reuse-config should be renamed so that the\nvariable can be named more sanely and in line with whatever option\nthat replaces it.\n\nNo responses; I think we will eventually want to have a configuration to\nalways enable the new option, so the renaming of the command line option\nis inevitable.  I plan to kick this out of 'next' once the upcoming\nrelease is out, and expect a re-roll with configuration variable.\n\n* js/rebase-origin-x (2010-02-05) 1 commit\n - [RFC w/o test and incomplete] rebase: add -x option to record original commit name\n\nI retract my objection against the idea of -x; needs polishing before\nmoving forward.\n\nNo responses; I plan to drop this entirely after the upcoming release\nwithout prejudice.\n\n* zl/mailinfo-recode-patch (2010-06-14) 2 commits\n - add --recode-patch option to git-am\n - add --recode-patch option to git-mailinfo\n\nI recall there was another round of re-roll planned for this one.\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\n--------------------------------------------------\n[Cooking]\n\n* ab/report-corrupt-object-with-type (2010-06-10) 1 commit\n - sha1_file: Show the the type and path to corrupt objects\n\n* cc/revert (2010-07-21) 5 commits\n - t3508: add check_head_differs_from() helper function and use it\n - revert: improve success message by adding abbreviated commit sha1\n - revert: don't print \"Finished one cherry-pick.\" if commit failed\n - revert: refactor commit code into a new run_git_commit() function\n - revert: report success when using option --strategy\n\n* en/fast-export-fix (2010-07-17) 2 commits\n - fast-export: Add a --full-tree option\n - fast-export: Fix dropping of files with --import-marks and path limiting\n\n* jn/parse-date-basic (2010-07-15) 1 commit\n - Export parse_date_basic() to convert a date string to timestamp\n (this branch is used by rr/svn-export.)\n\n* kf/post-receive-sample-hook (2010-07-16) 1 commit\n - post-receive-email: optional message line count limit\n\n* tr/rfc-reset-doc (2010-07-18) 5 commits\n - Documentation/reset: move \"undo permanently\" example behind \"make topic\"\n - Documentation/reset: reorder examples to match description\n - Documentation/reset: promote 'examples' one section up\n - Documentation/reset: separate options by mode\n - Documentation/git-reset: reorder modes for soft-mixed-hard progression\n\n* rr/svn-export (2010-07-15) 8 commits\n - Add SVN dump parser\n - Add infrastructure to write revisions in fast-export format\n - Add stream helper library\n - Add string-specific memory pool\n - vcs-svn: treap_search should return NULL for missing items\n - Add treap implementation\n - Add memory pool library\n - Introduce vcs-svn lib\n (this branch uses jn/parse-date-basic.)\n\n* hv/autosquash-config (2010-07-14) 1 commit\n - add configuration variable for --autosquash option of interactive rebase\n\n* jh/graph-next-line (2010-07-13) 2 commits\n - Enable custom schemes for column colors in the graph API\n - Make graph_next_line() available in the graph.h API\n\n* ar/string-list-foreach (2010-07-03) 2 commits\n - Convert the users of for_each_string_list to for_each_string_list_item macro\n - Add a for_each_string_list_item macro\n (this branch is used by tf/string-list-init.)\n\n* il/rfc-remote-fd-ext (2010-07-19) 3 commits\n - gitignore: Ignore the new /git-remote-{ext,fd} helpers\n - New remote helper: git-remote-ext\n - New remote helper git-remote-fd\n\n* gp/pack-refs-remove-empty-dirs (2010-07-06) 1 commit\n  (merged to 'next' on 2010-07-14 at 7d25131)\n + pack-refs: remove newly empty directories\n\n* hv/submodule-find-ff-merge (2010-07-07) 3 commits\n - Implement automatic fast-forward merge for submodules\n - setup_revisions(): Allow walking history in a submodule\n - Teach ref iteration module about submodules\n\n* jn/fast-import-subtree (2010-06-30) 1 commit\n - Teach fast-import to import subtrees named by tree id\n\n* sg/rerere-gc-old-still-used (2010-07-13) 2 commits\n - rerere: fix overeager gc\n - mingw_utime(): handle NULL times parameter\n\n* tf/string-list-init (2010-07-04) 1 commit\n - string_list: Add STRING_LIST_INIT macro and make use of it.\n (this branch uses ar/string-list-foreach.)\n\n* en/d-f-conflict-fix (2010-07-27) 7 commits\n  (merged to 'next' on 2010-07-28 at 75e8ac1)\n + t/t6035-merge-dir-to-symlink.sh: Remove TODO on passing test\n  (merged to 'next' on 2010-07-14 at 2b2a810)\n + fast-import: Improve robustness when D->F changes provided in wrong order\n + fast-export: Fix output order of D/F changes\n + merge_recursive: Fix renames across paths below D/F conflicts\n + merge-recursive: Fix D/F conflicts\n + Add a rename + D/F conflict testcase\n + Add additional testcases for D/F conflicts\n\n* ab/i18n (2010-07-19) 2 commits\n - tests: rename test to work around GNU gettext bug\n - Add infrastructure for translating Git with gettext\n (this branch is used by tr/ab-i18n-fix.)\n\n* tc/checkout-B (2010-06-24) 3 commits\n - builtin/checkout: learn -B\n - builtin/checkout: reword hint for -b\n - add tests for checkout -b\n\n* eb/double-convert-before-merge (2010-07-02) 3 commits\n - Don't expand CRLFs when normalizing text during merge\n - Try normalizing files to avoid delete/modify conflicts when merging\n - Avoid conflicts when merging branches with mixed normalization\n"},{"id":"146792","messageId":"20100730183709.GC18544@coredump.intra.peff.net","threadId":"24567","inReplyTo":"7vvd7zuecv.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Jul 2010, #05; Wed, 28)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-07-30T18:37:09Z","receivedAt":"2010-07-30T18:37:09Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Jul 28, 2010 at 09:00:16PM -0700, Junio C Hamano wrote:\n\n> --------------------------------------------------\n> [Stalled -- would discard unless there are some movements soon]\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\nWhat do we want to do with this?\n\nThe first patch by itself produces a pretty big speedup for Ted's case,\nand does not impact correctness.  However, it does do a mindless\ndepth-first search, so there are cases where it can be slower than the\ncurrent code (basically, if you never have to go to the roots for your\ntagset, then my code will be slower, as it will almost certainly go to\nthe roots, but it will do so only one time for the whole set, instead of\npotentially once per tag).\n\nThe second patch by itself is harmless, as the user has to turn it\non explicitly. And the amount of code is quite small, so even if most\npeople don't use it, I don't think it is a problem.\n\nThe third one is where we start defaulting things to \"assume no more\nthan 1 day of clock skew by default\", which can cause incorrect answers\nin the face of skew.\n\nThe fourth is just an illustrative patch for per-repo skew detection.\n\nSo if the tradeoff for patch 1 is acceptable, we can merge the first\ntwo. If the tradeoff in patch 3 is acceptable, then we can merge up to\npatch 3. The fourth one should be thrown out either way. I can work up a\n\"detect clock skew on clone and gc\" patch based on it if we want to go\nthat way.\n\n-Peff\n"},{"id":"146843","messageId":"20100731060703.GA21207@burratino","threadId":"24567","inReplyTo":"20100730183709.GC18544@coredump.intra.peff.net","subject":"jk/tag-contains (Re: What's cooking in git.git (Jul 2010, #05; Wed, 28))","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-07-31T06:07:03Z","receivedAt":"2010-07-31T06:07:03Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Jeff King wrote:\n\n> What do we want to do with this?\n\nProbably I have already said too much about this topic, but here I go:\n\n> The third one is where we start defaulting things to \"assume no more\n> than 1 day of clock skew by default\", which can cause incorrect answers\n> in the face of skew.\n\nI think the default should be something that (just barely) works\ncorrectly for linux-2.6.git.\n\n> The fourth is just an illustrative patch for per-repo skew detection.\n\nI have been hoping for a chance to look these over, time hasn’t come my\nway yet.\n\n>                                                          I can work up a\n> \"detect clock skew on clone and gc\" patch based on it if we want to go\n> that way.\n\nThat sounds very sane.\n\nAdditional things to do (this is mostly a note to myself):\n\n - refuse to commit with a timestamp long before any parent\n\n - refuse to make a commit that would make the total slop too high?\n\n - check slop and warn about it in fsck (maybe your patch does this\n   already)\n\n - document the maximum-total-slop and maximum-single-commit-slop\n   rules!\n"},{"id":"146855","messageId":"20100731123328.GA5273@coredump.intra.peff.net","threadId":"24567","inReplyTo":"20100731060703.GA21207@burratino","subject":"Re: jk/tag-contains (Re: What's cooking in git.git (Jul 2010, #05; Wed, 28))","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-07-31T12:33:28Z","receivedAt":"2010-07-31T12:33:28Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Jul 31, 2010 at 01:07:03AM -0500, Jonathan Nieder wrote:\n\n> > The third one is where we start defaulting things to \"assume no more\n> > than 1 day of clock skew by default\", which can cause incorrect answers\n> > in the face of skew.\n> \n> I think the default should be something that (just barely) works\n> correctly for linux-2.6.git.\n\nI am tempted by that (and it is why I made the fourth patch to actually\ncalculate the worst skew). But my concern is that there are projects\nwith even worse skew. Maybe that is unfounded.\n\n> > The fourth is just an illustrative patch for per-repo skew detection.\n> \n> I have been hoping for a chance to look these over, time hasn’t come my\n> way yet.\n\nIt just a git-skew program to calculate the skew, but doesn't do\nanything fancy like detect-on-gc. However, it would be nice to have\nsomebody sanity check the algorithm. Looking at it again, I think it\nmight actually miss some skew if the skewed commit can be reached in\nmultiple ways.\n\n> Additional things to do (this is mostly a note to myself):\n> \n>  - refuse to commit with a timestamp long before any parent\n\nAgreed.\n\n>  - refuse to make a commit that would make the total slop too high?\n\nThat would be expensive to commit, and if we bound each individual\ncommit to parent relationship as you mention above, I don't think it\nshould be necessary.\n\n>  - check slop and warn about it in fsck (maybe your patch does this\n>    already)\n\nNo, it doesn't, but it is something we should probably do.\n\n>  - document the maximum-total-slop and maximum-single-commit-slop\n>    rules!\n\nDefinitely.\n\n-Peff\n"},{"id":"146921","messageId":"7vocdlpsmw.fsf@alter.siamese.dyndns.org","threadId":"24567","inReplyTo":"20100731123328.GA5273@coredump.intra.peff.net","subject":"Re: jk/tag-contains (Re: What's cooking in git.git (Jul 2010, #05; Wed, 28))","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-08-02T04:04:23Z","receivedAt":"2010-08-02T04:04:23Z","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 Sat, Jul 31, 2010 at 01:07:03AM -0500, Jonathan Nieder wrote:\n>\n>> > The third one is where we start defaulting things to \"assume no more\n>> > than 1 day of clock skew by default\", which can cause incorrect answers\n>> > in the face of skew.\n>> \n>> I think the default should be something that (just barely) works\n>> correctly for linux-2.6.git.\n>\n> I am tempted by that (and it is why I made the fourth patch to actually\n> calculate the worst skew). But my concern is that there are projects\n> with even worse skew. Maybe that is unfounded.\n>\n>> > The fourth is just an illustrative patch for per-repo skew detection.\n>> \n>> I have been hoping for a chance to look these over, time hasn’t come my\n>> way yet.\n\nSorry, but I am right in the middle of phisically moving, so my weekend\nand evening git time has been nil recently.\n\n> It just a git-skew program to calculate the skew, but doesn't do\n> anything fancy like detect-on-gc. However, it would be nice to have\n> somebody sanity check the algorithm. Looking at it again, I think it\n> might actually miss some skew if the skewed commit can be reached in\n> multiple ways.\n>\n>> Additional things to do (this is mostly a note to myself):\n>> \n>>  - refuse to commit with a timestamp long before any parent\n>\n> Agreed.\n\nYou need to be careful here, though.  What if you pulled from somebody\nwhose clock is set grossly in the future?\n\n>>  - check slop and warn about it in fsck (maybe your patch does this\n>>    already)\n>\n> No, it doesn't, but it is something we should probably do.\n\nI wonder if we can make fsck to notice a commit with a wrong timestamp\n(i.e. older than some of its parents) and make a note of it (hopefully\nthey are miniscule minority)---then during the revision traversal when we\nhit such a commit, we perhaps ignore its timestamp (pretending as if its\ntimestamp is one of its children or parent---I haven't thought about the\ndetails, but the note fsck leaves can record what adjusted timestamp\nshould be used) to fix the issue?\n"},{"id":"146981","messageId":"20100802200209.GD2180@burratino","threadId":"24567","inReplyTo":"7vocdlpsmw.fsf@alter.siamese.dyndns.org","subject":"Re: jk/tag-contains (Re: What's cooking in git.git (Jul 2010, #05; Wed, 28))","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-08-02T20:02:09Z","receivedAt":"2010-08-02T20:02:09Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Junio C Hamano wrote:\n\n> You need to be careful here, though.  What if you pulled from somebody\n> whose clock is set grossly in the future?\n\nWe could check for that and give relevant advice:\n\n fatal: committer date <date> precedes parent date <date>\n hint: It looks like you are trying to commit on top of a commit\n hint: from 5 years into the future.\n hint: Use \"git rebase -f\" to rewrite the commit with a more\n hint: sensible date, and please, fix your clocks!\n\n> I wonder if we can make fsck to notice a commit with a wrong timestamp\n> (i.e. older than some of its parents) and make a note of it (hopefully\n> they are miniscule minority)---then during the revision traversal when we\n> hit such a commit, we perhaps ignore its timestamp (pretending as if its\n> timestamp is one of its children or parent---I haven't thought about the\n> details, but the note fsck leaves can record what adjusted timestamp\n> should be used) to fix the issue?\n\nThanks --- at first glance, this idea would seem to allow much faster\nrevision limiting.\n"},{"id":"146982","messageId":"vpqk4o8bwwd.fsf@bauges.imag.fr","threadId":"24567","inReplyTo":"20100802200209.GD2180@burratino","subject":"Re: jk/tag-contains (Re: What's cooking in git.git (Jul 2010, #05; Wed, 28))","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2010-08-02T20:08:18Z","receivedAt":"2010-08-02T20:08:18Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Jonathan Nieder <jrnieder@gmail.com> writes:\n\n> Junio C Hamano wrote:\n>\n>> You need to be careful here, though.  What if you pulled from somebody\n>> whose clock is set grossly in the future?\n>\n> We could check for that and give relevant advice:\n>\n>  fatal: committer date <date> precedes parent date <date>\n>  hint: It looks like you are trying to commit on top of a commit\n>  hint: from 5 years into the future.\n>  hint: Use \"git rebase -f\" to rewrite the commit with a more\n>  hint: sensible date, and please, fix your clocks!\n\nIf the problem is the commit you've just pulled, I'd advise against\nre-writing it: it's published, it's too late.\n\nBe careful also: Git can hardly guess whether your clock is late, or\nwhether your co-worker's clock is in the future.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"146983","messageId":"20100802201920.GE2180@burratino","threadId":"24567","inReplyTo":"vpqk4o8bwwd.fsf@bauges.imag.fr","subject":"Re: jk/tag-contains","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-08-02T20:19:20Z","receivedAt":"2010-08-02T20:19:20Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Matthieu Moy wrote:\n> Jonathan Nieder <jrnieder@gmail.com> writes:\n\n>>  fatal: committer date <date> precedes parent date <date>\n>>  hint: It looks like you are trying to commit on top of a commit\n>>  hint: from 5 years into the future.\n>>  hint: Use \"git rebase -f\" to rewrite the commit with a more\n>>  hint: sensible date, and please, fix your clocks!\n>\n> If the problem is the commit you've just pulled, I'd advise against\n> re-writing it: it's published, it's too late.\n\nI guess that is the fundamental question.  What do you do when a\ncompletely bogus commit has been published?\n\n(For example, fsck permits extra headers after the \"encoding\" header,\nbut a commit object using random such headers would be malformed and\nnoticeable as such as soon as fsck learns what header is supposed to\ncome after \"encoding\".)\n\nI would like it to still be possible to publically acknowledge a\nmistake, make people rewrite their history to remove it, and move on.\nBut another viable solution here would be to just warn about the\nproblem and maintain a list of bogus commits as Junio suggested.\n"},{"id":"147010","messageId":"7vbp9kk5ce.fsf@alter.siamese.dyndns.org","threadId":"24567","inReplyTo":"20100802201920.GE2180@burratino","subject":"Re: jk/tag-contains","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-08-02T22:38:41Z","receivedAt":"2010-08-02T22:38:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder <jrnieder@gmail.com> writes:\n\n> I would like it to still be possible to publically acknowledge a\n> mistake, make people rewrite their history to remove it, and move on.\n\nWhile I wish the world were that simple, I do not think that is viable.\nYou may not have any control over your upstream (not to mention the\npossibility that the upstream might even be a foreign SCM).\n\nSo I'd prefer to see us prepared to be lenient with what we accept from\noutside world.\n"},{"id":"147229","messageId":"20100805175640.GB15760@sigill","threadId":"24567","inReplyTo":"7vocdlpsmw.fsf@alter.siamese.dyndns.org","subject":"Re: jk/tag-contains (Re: What's cooking in git.git (Jul 2010, #05; Wed, 28))","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-08-05T17:56:40Z","receivedAt":"2010-08-05T17:56:40Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Aug 01, 2010 at 09:04:23PM -0700, Junio C Hamano wrote:\n\n> Sorry, but I am right in the middle of phisically moving, so my weekend\n> and evening git time has been nil recently.\n\nDidn't you just do that? ;P\n\n> >> Additional things to do (this is mostly a note to myself):\n> >> \n> >>  - refuse to commit with a timestamp long before any parent\n> >\n> > Agreed.\n> \n> You need to be careful here, though.  What if you pulled from somebody\n> whose clock is set grossly in the future?\n\nReading the rest of this thread and thinking about it more, I think\nwarning is the best thing we can do. Because only the user is in a\nposition to know whether it is their clock or the previous commit that\nis in error. And if it is the previous commit, then only the user knows\nwhat the next logical step is: redo the commit, complain to somebody\nelse, or just ignore and continue.\n\n> I wonder if we can make fsck to notice a commit with a wrong timestamp\n> (i.e. older than some of its parents) and make a note of it (hopefully\n> they are miniscule minority)---then during the revision traversal when we\n> hit such a commit, we perhaps ignore its timestamp (pretending as if its\n> timestamp is one of its children or parent---I haven't thought about the\n> details, but the note fsck leaves can record what adjusted timestamp\n> should be used) to fix the issue?\n\nThat's basically a finer-grained version of what I implemented. Mine\nfinds the _worst_ skew for the whole graph, and never lets you optimize\na traversal cutoff more than that skew. So it is nicely bounded\nspace-wise, as it is always a single integer, but you waste effort on\nthe entire traversal because a couple of commits are skewed. Yours\noptimizes perfectly, but needs O(skewed commits) storage. Which is\nprobably a better tradeoff when the number of skewed commits is tiny\n(which is what we expect).\n\nI think your technique would work, but with one note. You probably want\nto pull the timestamp from the parent (pulling from the child makes no\nsense to me, as there can be an infinite number of children), but you\nneed to process the parent first and pull from its _corrected_\ntimestamp. Because at least in the linux-2.6 case, there is a run of\nskewed commits. So if you have something like:\n\n  A -- B -- C -- D\n\nA, timestamp = 1000\nB, timestamp = 900\nC, timestamp = 950\nD, timestamp = 1100\n\nwhere obviously the timestamps are shortened to be readable, but are\nmeant to be seconds-since-epoch.  You'd probably want to end up with:\n\nA, timestamp = 1000\nB, timestamp = 1001\nC, timestamp = 1002\nD, timestamp = 1100\n\nwhich means recursing all the way to the root, and fixing timestamps as\nyou back out.\n\nThis seems like just a straight sha1->int mapping, which presumably one\ncould do using \"git notes\". Though I worry it could slow down traversal\nfor all of the lookup misses for non-skewed commits.\n\n-Peff\n"},{"id":"147230","messageId":"7vd3twex76.fsf@alter.siamese.dyndns.org","threadId":"24567","inReplyTo":"20100805175640.GB15760@sigill","subject":"Re: jk/tag-contains (Re: What's cooking in git.git (Jul 2010, #05; Wed, 28))","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-08-05T18:22:37Z","receivedAt":"2010-08-05T18:22:37Z","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> That's basically a finer-grained version of what I implemented. Mine\n> finds the _worst_ skew for the whole graph, and never lets you optimize\n> a traversal cutoff more than that skew. So it is nicely bounded\n> space-wise, as it is always a single integer, but you waste effort on\n> the entire traversal because a couple of commits are skewed. Yours\n> optimizes perfectly, but needs O(skewed commits) storage. Which is\n> probably a better tradeoff when the number of skewed commits is tiny\n> (which is what we expect).\n\nOne thing missing from the above equation is that O(skewed commits)\napproach will need O(number of commits) look-ups in the skew database (be\nit a notes tree or whatever), only to make sure that most of the look-ups\nsay \"no timestamp tweak required\".  So I think the global single integer\napproach you took would probably be better in the overall picture.\n"},{"id":"147239","messageId":"20100805193545.GA10630@sigill","threadId":"24567","inReplyTo":"7vd3twex76.fsf@alter.siamese.dyndns.org","subject":"Re: jk/tag-contains (Re: What's cooking in git.git (Jul 2010, #05; Wed, 28))","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-08-05T19:35:45Z","receivedAt":"2010-08-05T19:35:45Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Aug 05, 2010 at 11:22:37AM -0700, Junio C Hamano wrote:\n\n> > That's basically a finer-grained version of what I implemented. Mine\n> > finds the _worst_ skew for the whole graph, and never lets you optimize\n> > a traversal cutoff more than that skew. So it is nicely bounded\n> > space-wise, as it is always a single integer, but you waste effort on\n> > the entire traversal because a couple of commits are skewed. Yours\n> > optimizes perfectly, but needs O(skewed commits) storage. Which is\n> > probably a better tradeoff when the number of skewed commits is tiny\n> > (which is what we expect).\n> \n> One thing missing from the above equation is that O(skewed commits)\n> approach will need O(number of commits) look-ups in the skew database (be\n> it a notes tree or whatever), only to make sure that most of the look-ups\n> say \"no timestamp tweak required\".  So I think the global single integer\n> approach you took would probably be better in the overall picture.\n\nI'm not sure it is that bad. Shouldn't it have the same number of\nlookups as this scenario:\n\n  # pretend we have some fake timestamps\n  for i in 20 40 60; do\n    git notes add -m \"fake timestamp\" HEAD~$i\n  done\n\n  # now time it without notes\n  time git log --pretty=raw --no-notes >/dev/null\n\n  # and with notes\n  time git log --pretty=raw --show-notes >/dev/null\n\nFor me, the timing differences are lost in the noise. So perhaps the\nlookup isn't all that expensive compared to the actual traversal.\n\n-Peff\n"}]}