{"thread":{"id":"12732","subject":"Unresolved issues","startedAt":"2008-03-18T01:12:02Z","lastAt":"2008-03-19T22:48:19Z","messageCount":5,"participants":["Junio C Hamano","Jeff King","Linus Torvalds","Johannes Schindelin","Sam Vilain"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"72331","messageId":"7v7ig096ot.fsf@gitster.siamese.dyndns.org","threadId":"12732","inReplyTo":null,"subject":"Unresolved issues","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-03-18T01:12:02Z","receivedAt":"2008-03-18T01:12:02Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"I tagged 1.5.5-rc0 Sunday night (my time, obviously).\n\nOur contributors have been busy inventing new features and reinventing old\nones in C during the 1.5.5 cycle, and we have a fair number of known\nbreakages.  Here is a short list of issues I know (or I think I've heard)\nabout, that we would like to address (either \"resolve\", or \"declare to\npostpone\") before the final release, but I am sure I missed some things.\n\nLet's hope contributors are as responsive in fixing their own mess as they\nare responsive in scratching their own itch, and we can resolve most of\nthem shortly.\n\n* synopsys: use {} instead of () for grouping alternatives (Jari Aalto)\n  $gmane/72243\n\n  This was discussed during 1.5.4 pre-freeze timeframe but never\n  materialized.\n\n* \"git remote\" showing remotes/origin/HEAD as a candidate for pruning,\n  and pruning it results in removal of what is pointed at by it.\n\n  Pointers?  This may not be a regression but bug-to-bug compatibility\n  with the older implementation, but this should better be fixed.\n\n* fetch with \"refs/*:refs/*\" errors out erroneously\n  $gmane/77335\n\n  Breakage exposed by recent git allowing \"mirror\" layout with \"git remote\n  add --mirror\".\n\n* fetch with tag following uses smudged object database\n  $gmane/74141\n\n  Regression introduced by recent C-rewrite of git-fetch.\n\n* \"git fetch\" does not exit with non-zero status when it failed to update\n  some refs due to non-ffness\n  $gmane/77178\n\n  Regression introduced by recent C-rewrite of git-fetch.\n\n* \"git fetch\" shows error when dangling symref exists at the remote\n  but does not really error out\n  $gmane/76658\n\n  I am not sure what the right course of action is.  Maybe we should\n  ignore dangling symrefs in upload-pack?\n\n* D/F conflict to merge a tree with D into a tree with F\n  $gmane/77352\n\n  Needs more info.\n\n* revision.c::limit_list() breakage\n  $gmane/72324\n  t/t6009\n\n  When you run \"git rev-list A..B C\", and there is a commit in the chain\n  between A and B whose timestamp is much older than its parent, sometimes\n  we fail to mark C as reachable from A (hence not interesting) even when\n  it actualy is.  This is very expensive to solve in general, and we are\n  not going to introduce \"generation number\" field to the commit objects,\n  so we may have to settle with a heuristic.\n\n* \"[alias] st = status\" and \"cd .git && git st\" (Jeff King)\n  $gmane/72327\n\n  This shows everything as deleted, I believe it hasn't resolved.  I am\n  not sure if this is worth resolving, though.\n"},{"id":"72332","messageId":"20080318012624.GA5307@coredump.intra.peff.net","threadId":"12732","inReplyTo":"7v7ig096ot.fsf@gitster.siamese.dyndns.org","subject":"Re: Unresolved issues","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-03-18T01:26:24Z","receivedAt":"2008-03-18T01:26:24Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Mar 17, 2008 at 06:12:02PM -0700, Junio C Hamano wrote:\n\n> * \"[alias] st = status\" and \"cd .git && git st\" (Jeff King)\n>   $gmane/72327\n> \n>   This shows everything as deleted, I believe it hasn't resolved.  I am\n>   not sure if this is worth resolving, though.\n\nI started on a patch for this, but got mired in trying to clean up the\nworktree handling in this area, which is quite confusing and fragile. I\nhave a suspicion that Duy's recent patch series will impact this, but I\nhaven't had time yet to review that carefully.\n\n-Peff\n"},{"id":"72333","messageId":"alpine.LFD.1.00.0803171853180.3020@woody.linux-foundation.org","threadId":"12732","inReplyTo":"7v7ig096ot.fsf@gitster.siamese.dyndns.org","subject":"Re: Unresolved issues","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-03-18T01:56:33Z","receivedAt":"2008-03-18T01:56:33Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\nOn Mon, 17 Mar 2008, Junio C Hamano wrote:\n> \n> * revision.c::limit_list() breakage\n>   $gmane/72324\n>   t/t6009\n> \n>   When you run \"git rev-list A..B C\", and there is a commit in the chain\n>   between A and B whose timestamp is much older than its parent, sometimes\n>   we fail to mark C as reachable from A (hence not interesting) even when\n>   it actualy is.  This is very expensive to solve in general, and we are\n>   not going to introduce \"generation number\" field to the commit objects,\n>   so we may have to settle with a heuristic.\n\nHere is the already posted heuristic that fixes both t/t6009 and the \nreal-world case that triggered the whole discussion.\n\nIt's certainly not perfect, but I think it's likely an improvement on what \nwe have now, and it should be robust in the face of the _occasional_ wrong \ndate.\n\nNow, if there are consistently totally bogus dates, the SLOP thing won't \nhelp, but ...\n\n\t\tLinus\n---\nFrom: Linus Torvalds <torvalds@woody.linux-foundation.org>\n\nMake revision limiting more robust against occasional bad commit dates\n\nThe revision limiter uses the commit date to decide when it has seen\nenough commits to finalize the revision list, but that can get confused\nif there are incorrect dates far in the past on some commits.\n\nThis makes the logic a bit more robust by\n\n - we always walk an extra SLOP commits from the source list even if we\n   decide that the source list is probably all done (unless the source is\n   entirely empty, of course, because then we really can't do anything at\n   all)\n\n - we keep track of the date of the last commit we added to the\n   destination list (this will *generally* be the oldest entry we've seen\n   so far)\n\n - we compare that with the youngest entry (the first one) of the source\n   list, and if the destination is older than the source, we know we want\n   to look at the source.\n\nwhich causes occasional date mishaps to be handled cleanly.\n\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\n---\n revision.c |   46 +++++++++++++++++++++++++++++++++++++---------\n 1 files changed, 37 insertions(+), 9 deletions(-)\n\ndiff --git a/revision.c b/revision.c\nindex 63bf2c5..196fedc 100644\n--- a/revision.c\n+++ b/revision.c\n@@ -564,14 +564,39 @@ static void cherry_pick_list(struct commit_list *list, struct rev_info *revs)\n \tfree_patch_ids(&ids);\n }\n \n-static void add_to_list(struct commit_list **p, struct commit *commit, struct commit_list *n)\n+/* How many extra uninteresting commits we want to see.. */\n+#define SLOP 5\n+\n+static int still_interesting(struct commit_list *src, unsigned long date, int slop)\n {\n-\tp = &commit_list_insert(commit, p)->next;\n-\t*p = n;\n+\t/*\n+\t * No source list at all? We're definitely done..\n+\t */\n+\tif (!src)\n+\t\treturn 0;\n+\n+\t/*\n+\t * Does the destination list contain entries with a date\n+\t * before the source list? Definitely _not_ done.\n+\t */\n+\tif (date < src->item->date)\n+\t\treturn SLOP;\n+\n+\t/*\n+\t * Does the source list still have interesting commits in\n+\t * it? Definitely not done..\n+\t */\n+\tif (!everybody_uninteresting(src))\n+\t\treturn SLOP;\n+\n+\t/* Ok, we're closing in.. */\n+\treturn slop-1;\n }\n \n static int limit_list(struct rev_info *revs)\n {\n+\tint slop = SLOP;\n+\tunsigned long date = ~0ul;\n \tstruct commit_list *list = revs->commits;\n \tstruct commit_list *newlist = NULL;\n \tstruct commit_list **p = &newlist;\n@@ -591,16 +616,19 @@ static int limit_list(struct rev_info *revs)\n \t\t\treturn -1;\n \t\tif (obj->flags & UNINTERESTING) {\n \t\t\tmark_parents_uninteresting(commit);\n-\t\t\tif (everybody_uninteresting(list)) {\n-\t\t\t\tif (revs->show_all)\n-\t\t\t\t\tadd_to_list(p, commit, list);\n-\t\t\t\tbreak;\n-\t\t\t}\n-\t\t\tif (!revs->show_all)\n-\t\t\t\tcontinue;\n+\t\t\tif (revs->show_all)\n+\t\t\t\tp = &commit_list_insert(commit, p)->next;\n+\t\t\tslop = still_interesting(list, date, slop);\n+\t\t\tif (slop)\n+\t\t\t\tcontinue;\n+\t\t\t/* If showing all, add the whole pending list to the end */\n+\t\t\tif (revs->show_all)\n+\t\t\t\t*p = list;\n+\t\t\tbreak;\n \t\t}\n \t\tif (revs->min_age != -1 && (commit->date > revs->min_age))\n \t\t\tcontinue;\n+\t\tdate = commit->date;\n \t\tp = &commit_list_insert(commit, p)->next;\n \n \t\tshow = show_early_output;\n"},{"id":"72424","messageId":"alpine.DEB.1.00.0803182119320.2323@eeepc-johanness","threadId":"12732","inReplyTo":"7v7ig096ot.fsf@gitster.siamese.dyndns.org","subject":"[PATCH] remote show: do not show symbolic refs","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-03-19T00:27:42Z","receivedAt":"2008-03-19T00:27:42Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"\nFor symbolic refs, a sane notion of being \"stale\" is that the ref\nthey point to no longer exists.  Since this is checked already,\n\"remote show\" does not need to show them at all.\n\nIncidentally, this fixes the issue that \"HEAD\" was shown as a\nstale ref by \"remote show\" in a freshly cloned repository.\n\nSigned-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>\n---\n\n\tOn Mon, 17 Mar 2008, Junio C Hamano wrote:\n\n\t> \"git remote\" showing remotes/origin/HEAD as a candidate for \n\t> pruning, and pruning it results in removal of what is pointed at \n\t> by it.\n\t>\n\t> Pointers?  This may not be a regression but bug-to-bug \n\t> compatibility with the older implementation, but this should \n\t> better be fixed.\n\n\tHow about this?\n\n builtin-remote.c  |    5 ++++-\n t/t5505-remote.sh |   10 ++++++++++\n 2 files changed, 14 insertions(+), 1 deletions(-)\n\ndiff --git a/builtin-remote.c b/builtin-remote.c\nindex 8e7fa6a..67139ec 100644\n--- a/builtin-remote.c\n+++ b/builtin-remote.c\n@@ -210,7 +210,10 @@ static int handle_one_branch(const char *refname,\n \tif (!remote_find_tracking(states->remote, &refspec)) {\n \t\tstruct path_list_item *item;\n \t\tconst char *name = skip_prefix(refspec.src, \"refs/heads/\");\n-\t\tif (unsorted_path_list_has_path(&states->tracked, name) ||\n+\t\t/* symbolic refs pointing nowhere were handled already */\n+\t\tif ((flags & REF_ISSYMREF) ||\n+\t\t\t\tunsorted_path_list_has_path(&states->tracked,\n+\t\t\t\t\tname) ||\n \t\t\t\tunsorted_path_list_has_path(&states->new,\n \t\t\t\t\tname))\n \t\t\treturn 0;\ndiff --git a/t/t5505-remote.sh b/t/t5505-remote.sh\nindex ecfc999..004a8dc 100755\n--- a/t/t5505-remote.sh\n+++ b/t/t5505-remote.sh\n@@ -237,4 +237,14 @@ test_expect_success 'update default (overridden, with funny whitespace)' '\n \n '\n \n+test_expect_success '\"remote show\" does not show symbolic refs' '\n+\n+\tgit clone one three &&\n+\t(cd three &&\n+\t git remote show origin > output &&\n+\t ! grep HEAD < output &&\n+\t ! grep -i stale < output)\n+\n+'\n+\n test_done\n-- \n1.5.5.rc0.173.g90d70\n"},{"id":"72437","messageId":"47E19833.60402@vilain.net","threadId":"12732","inReplyTo":"alpine.LFD.1.00.0803171853180.3020@woody.linux-foundation.org","subject":"Re: Unresolved issues","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2008-03-19T22:48:19Z","receivedAt":"2008-03-19T22:48:19Z","isPatch":false,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"Linus Torvalds wrote:\n>>   When you run \"git rev-list A..B C\", and there is a commit in the chain\n>>   between A and B whose timestamp is much older than its parent, sometimes\n>>   we fail to mark C as reachable from A (hence not interesting) even when\n>>   it actualy is.  This is very expensive to solve in general, and we are\n>>   not going to introduce \"generation number\" field to the commit objects,\n>>   so we may have to settle with a heuristic.\n> Here is the already posted heuristic that fixes both t/t6009 and the \n> real-world case that triggered the whole discussion.\n> It's certainly not perfect, but I think it's likely an improvement on what \n> we have now, and it should be robust in the face of the _occasional_ wrong \n> date.\n> Now, if there are consistently totally bogus dates, the SLOP thing won't \n> help, but ...\n\nOuch - I had always supposed that topology was king, and that the commit\ndates were purely informational.  In particular the Perl history that I\nproduced in general takes a position of blatant and wanton disregard to\nsuch consistency.\n\nI can't find the other thread you refer to - is there a good summary of\nthe issues somewhere?  The test script is not very descriptive.\n\nIf timewise out-of-order commits are bad, perhaps git-filter-branch\nshould warn when it is creating histories whose topology disagrees with\ntheir chronology... and also the user manual should probably describe this.\n\nSam\n"}]}