{"thread":{"id":"23461","subject":"[PATCH 1/2] Document gc..reflogexpire variables","startedAt":"2010-04-14T20:34:43Z","lastAt":"2010-04-16T06:08:10Z","messageCount":16,"participants":["Junio C Hamano","Johannes Sixt","Jeff King","Nicolas Pitre"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"139510","messageId":"7vljcppycc.fsf@alter.siamese.dyndns.org","threadId":"23461","inReplyTo":null,"subject":"[PATCH 1/2] Document gc..reflogexpire variables","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-04-14T20:34:43Z","receivedAt":"2010-04-14T20:34:43Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"3cb22b8 (Per-ref reflog expiry configuration, 2008-06-15) added support\nfor setting the expiry parameters differently for different reflog, but\nit was never documented.\n\nSigned-off-by: Junio C Hamano \n---\n\n * This comes on top of b4ca1db (reflog --expire-unreachable: avoid\n merge-base computation, 2010-04-07).\n\n Documentation/config.txt | 10 ++++++++--\n Documentation/git-gc.txt | 10 ++++++++++\n 2 files changed, 18 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex a1e36d7..4e7dab6 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -885,13 +885,19 @@ gc.pruneexpire::\n \tunreachable objects immediately.\n \n gc.reflogexpire::\n+gc..reflogexpire::\n \t'git-reflog expire' removes reflog entries older than\n-\tthis time; defaults to 90 days.\n+\tthis time; defaults to 90 days. With \"\" (e.g.\n+\t\"refs/stash\") in the middle the setting applies only to\n+\tthe refs that match the .\n \n gc.reflogexpireunreachable::\n+gc..reflogexpireunreachable::\n \t'git-reflog expire' removes reflog entries older than\n \tthis time and are not reachable from the current tip;\n-\tdefaults to 30 days.\n+\tdefaults to 30 days. With \"\" (e.g. \"refs/stash\")\n+\tin the middle, the setting applies only to the refs that\n+\tmatch the .\n \n gc.rerereresolved::\n \tRecords of conflicted merge you resolved earlier are\ndiff --git a/Documentation/git-gc.txt b/Documentation/git-gc.txt\nindex 4cd9cdf..85d7111 100644\n--- a/Documentation/git-gc.txt\n+++ b/Documentation/git-gc.txt\n@@ -88,6 +88,16 @@ commits prior to the amend or rebase occurring. Since these changes\n are not part of the current project most users will want to expire\n them sooner. This option defaults to '30 days'.\n \n+The above two configuration variables can be given to a pattern. For\n+example, this sets non-default expiry values only to remote tracking\n+branches:\n+\n+------------\n+[gc \"refs/remotes/*\"]\n+\treflogExpire = never\n+\treflogexpireUnreachable = 3 days\n+------------\n+\n The optional configuration variable 'gc.rerereresolved' indicates\n how long records of conflicted merge you resolved earlier are\n kept. This defaults to 60 days.\n-- \n1.7.1.rc1.252.gce30c\n"},{"id":"139511","messageId":"7vfx2xpyam.fsf@alter.siamese.dyndns.org","threadId":"23461","inReplyTo":"7vljcppycc.fsf@alter.siamese.dyndns.org","subject":"[PATCH 2/2] reflog: ignore expire-unreachable for \"HEAD\" reflog","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-04-14T20:35:45Z","receivedAt":"2010-04-14T20:35:45Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"git reflog expire\" (and \"git gc\") examines the reflog entries and\ndiscards old/stale ones using two criteria. The entries that are older\nthan \"reflogexpire\" (defaults to 90 days) are unconditionally removed, and\nthe entries that are older than \"reflogexpireunreachable\" (defaults to 30\ndays) are removed if the entry point at commits that are not reachable\nfrom the value of the ref.\n\nThis is reasonable for local branches, remote tracking branches and tags.\nYou (or other people) may have failed experiments that have been made and\nthen later discarded by resetting the tip of the branch back, and setting\nthe value of \"reflogexpireunreachable\" shorter than that of \"reflogexpire\"\nwill prune the entries that describe these failed experiments earlier than\nthe entries that describe the steps that led to the current history.\n\nIt however doesn't make much sense for \"HEAD\" reflog. When you switch\nbetween branches, it is normal that the tip of the branch you were on is\nnot an ancestor of the branch you have switched to. Expiring the entries\nthat describe what you did while on the previous branch earlier than usual\ndoes not help.\n\nThe test t7701 relied on this incorrect behaviour of entries being pruned\nfrom the \"HEAD\" reflog. Work it around by setting the \"HEAD\" reflog\nentries to be expired immediately.\n\nSigned-off-by: Junio C Hamano \n---\n builtin-reflog.c | 35 ++++++++++++++++++++++++---------\n t/t7701-repack-unpack-unreachable.sh | 1 +\n 2 files changed, 26 insertions(+), 10 deletions(-)\n\ndiff --git a/builtin-reflog.c b/builtin-reflog.c\nindex 9792090..c4bc5be 100644\n--- a/builtin-reflog.c\n+++ b/builtin-reflog.c\n@@ -34,8 +34,11 @@ struct cmd_reflog_expire_cb {\n \n struct expire_reflog_cb {\n \tFILE *newlog;\n-\tconst char *ref;\n-\tstruct commit *ref_commit;\n+\tenum {\n+\t\tUE_NORMAL,\n+\t\tUE_ALWAYS,\n+\t\tUE_NEVER\n+\t} unreachable_expire_kind;\n \tstruct commit_list *mark_list;\n \tunsigned long mark_limit;\n \tstruct cmd_reflog_expire_cb *cmd;\n@@ -304,8 +307,9 @@ static int expire_reflog_ent(unsigned char *osha1, unsigned char *nsha1,\n \t (!keep_entry(&old, osha1) || !keep_entry(&new, nsha1)))\n \t\tgoto prune;\n \n-\tif (timestamp < cb->cmd->expire_unreachable) {\n-\t\tif (!cb->ref_commit)\n+\tif ((cb->unreachable_expire_kind != UE_NEVER) &&\n+\t (timestamp < cb->cmd->expire_unreachable)) {\n+\t\tif (cb->unreachable_expire_kind == UE_ALWAYS)\n \t\t\tgoto prune;\n \t\tif (unreachable(cb, old, osha1) || unreachable(cb, new, nsha1))\n \t\t\tgoto prune;\n@@ -338,6 +342,7 @@ static int expire_reflog(const char *ref, const unsigned char *sha1, int unused,\n \tstruct expire_reflog_cb cb;\n \tstruct ref_lock *lock;\n \tchar *log_file, *newlog_path = NULL;\n+\tstruct commit *tip_commit;\n \tint status = 0;\n \n \tmemset(&cb, 0, sizeof(cb));\n@@ -357,18 +362,28 @@ static int expire_reflog(const char *ref, const unsigned char *sha1, int unused,\n \t\tcb.newlog = fopen(newlog_path, \"w\");\n \t}\n \n-\tcb.ref_commit = lookup_commit_reference_gently(sha1, 1);\n-\tcb.ref = ref;\n \tcb.cmd = cmd;\n-\tif (cb.ref_commit) {\n+\n+\tif (!cmd->expire_unreachable || !strcmp(ref, \"HEAD\")) {\n+\t\ttip_commit = NULL;\n+\t\tcb.unreachable_expire_kind = UE_NEVER;\n+\t} else {\n+\t\ttip_commit = lookup_commit_reference_gently(sha1, 1);\n+\t\tif (!tip_commit)\n+\t\t\tcb.unreachable_expire_kind = UE_ALWAYS;\n+\t\telse\n+\t\t\tcb.unreachable_expire_kind = UE_NORMAL;\n+\t}\n+\n+\tif (cb.unreachable_expire_kind == UE_NORMAL) {\n \t\tcb.mark_list = NULL;\n-\t\tcommit_list_insert(cb.ref_commit, &cb.mark_list);\n+\t\tcommit_list_insert(tip_commit, &cb.mark_list);\n \t\tcb.mark_limit = cmd->expire_total;\n \t\tmark_reachable(&cb);\n \t}\n \tfor_each_reflog_ent(ref, expire_reflog_ent, &cb);\n-\tif (cb.ref_commit)\n-\t\tclear_commit_marks(cb.ref_commit, REACHABLE);\n+\tif (cb.unreachable_expire_kind == UE_NORMAL)\n+\t\tclear_commit_marks(tip_commit, REACHABLE);\n finish:\n \tif (cb.newlog) {\n \t\tif (fclose(cb.newlog)) {\ndiff --git a/t/t7701-repack-unpack-unreachable.sh b/t/t7701-repack-unpack-unreachable.sh\nindex 5babdf2..e14b110 100755\n--- a/t/t7701-repack-unpack-unreachable.sh\n+++ b/t/t7701-repack-unpack-unreachable.sh\n@@ -9,6 +9,7 @@ csha1=\n tsha1=\n \n test_expect_success '-A with -d option leaves unreachable objects unpacked' '\n+\tgit config gc.HEAD.reflogexpire now &&\n \techo content > file1 &&\n \tgit add . &&\n \tgit commit -m initial_commit &&\n-- \n1.7.1.rc1.252.gce30c\n"},{"id":"139555","messageId":"4BC6B5FF.6030406@viscovery.net","threadId":"23461","inReplyTo":"7vfx2xpyam.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 2/2] reflog: ignore expire-unreachable for \"HEAD\" reflog","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2010-04-15T06:45:19Z","receivedAt":"2010-04-15T06:45:19Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 4/14/2010 22:35, schrieb Junio C Hamano:\n> \"git reflog expire\" (and \"git gc\") examines the reflog entries and\n> discards old/stale ones using two criteria. The entries that are older\n> than \"reflogexpire\" (defaults to 90 days) are unconditionally removed, and\n> the entries that are older than \"reflogexpireunreachable\" (defaults to 30\n> days) are removed if the entry point at commits that are not reachable\n> from the value of the ref.\n> \n> This is reasonable for local branches, remote tracking branches and tags.\n> You (or other people) may have failed experiments that have been made and\n> then later discarded by resetting the tip of the branch back, and setting\n> the value of \"reflogexpireunreachable\" shorter than that of \"reflogexpire\"\n> will prune the entries that describe these failed experiments earlier than\n> the entries that describe the steps that led to the current history.\n> \n> It however doesn't make much sense for \"HEAD\" reflog. When you switch\n> between branches, it is normal that the tip of the branch you were on is\n> not an ancestor of the branch you have switched to. Expiring the entries\n> that describe what you did while on the previous branch earlier than usual\n> does not help.\n\nDoes not help what? What is the problem?\n\n-- Hannes\n"},{"id":"139563","messageId":"7vochlkvtg.fsf@alter.siamese.dyndns.org","threadId":"23461","inReplyTo":"4BC6B5FF.6030406@viscovery.net","subject":"Re: [PATCH 2/2] reflog: ignore expire-unreachable for \"HEAD\" reflog","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-04-15T07:40:27Z","receivedAt":"2010-04-15T07:40:27Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Sixt writes:\n\n> Does not help what? What is the problem?\n\nYou will lose the record from HEAD reflog that records the fact that you\nwere at the tip of \"next\" less than \"reflogexpire\" but more than\n\"reflogexpireunreachable\" time ago, if you run \"gc\" while on \"master\".\n\nSuch a pruning does not have much to do with the real reason why\nexpireunreachable would be a useful thing (namely, to prune failed\nhistories that have been rewound away faster than the history that\nsurvived from reflog of individual branches).\n"},{"id":"139566","messageId":"4BC6D30F.5020004@viscovery.net","threadId":"23461","inReplyTo":"7vochlkvtg.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 2/2] reflog: ignore expire-unreachable for \"HEAD\" reflog","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2010-04-15T08:49:19Z","receivedAt":"2010-04-15T08:49:19Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 4/15/2010 9:40, schrieb Junio C Hamano:\n> Johannes Sixt writes:\n> \n>> Does not help what? What is the problem?\n> \n> You will lose the record from HEAD reflog that records the fact that you\n> were at the tip of \"next\" less than \"reflogexpire\" but more than\n> \"reflogexpireunreachable\" time ago, if you run \"gc\" while on \"master\".\n> \n> Such a pruning does not have much to do with the real reason why\n> expireunreachable would be a useful thing (namely, to prune failed\n> histories that have been rewound away faster than the history that\n> survived from reflog of individual branches).\n\nBut what is the benefit?\n\nWe expire reflogs so that we can garbage-collect objects. If\nexpire-unreachable is ignored for HEAD, then the objects of failed\nexperiments survive due to HEAD's reflog until reflog.expire is reached.\nIf this is what you want, why do we have expire-unreachable at all?\n\n-- Hannes\n"},{"id":"139579","messageId":"7v4ojclwyu.fsf@alter.siamese.dyndns.org","threadId":"23461","inReplyTo":"4BC6D30F.5020004@viscovery.net","subject":"Re: [PATCH 2/2] reflog: ignore expire-unreachable for \"HEAD\" reflog","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-04-15T12:30:17Z","receivedAt":"2010-04-15T12:30:17Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Sixt writes:\n\n> Am 4/15/2010 9:40, schrieb Junio C Hamano:\n>> Johannes Sixt writes:\n>> \n>>> Does not help what? What is the problem?\n>> \n>> You will lose the record from HEAD reflog that records the fact that you\n>> were at the tip of \"next\" less than \"reflogexpire\" but more than\n>> \"reflogexpireunreachable\" time ago, if you run \"gc\" while on \"master\".\n>> \n>> Such a pruning does not have much to do with the real reason why\n>> expireunreachable would be a useful thing (namely, to prune failed\n>> histories that have been rewound away faster than the history that\n>> survived from reflog of individual branches).\n>\n> But what is the benefit?\n\nThat is a funny thing to ask. Since when not losing information is a\nlower priority?\n\n> We expire reflogs so that we can garbage-collect objects.\n\nI am tempted to say \"Wrong!\", but would stop at saying \"We seem to have\ndiffering opinions\" for now.\n\nA reflog consists of entries, each of which records how you got to the\ncurrent history by pointing to different commit objects. Some entries\nmatter more than others do. Dead-end experiments stop mattering faster\nthan others. It is these _entries_ that we expire, because keeping them\nindefinitely is a wasteful clutter.\n\nRemoving stale objects is not a goal; objects are removed merely as an\neffect of them becoming stale after no refs and reflog entries that matter\npoint at them.\n"},{"id":"139584","messageId":"4BC70D75.70801@viscovery.net","threadId":"23461","inReplyTo":"7v4ojclwyu.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 2/2] reflog: ignore expire-unreachable for \"HEAD\" reflog","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2010-04-15T12:58:29Z","receivedAt":"2010-04-15T12:58:29Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 4/15/2010 14:30, schrieb Junio C Hamano:\n> A reflog consists of entries, each of which records how you got to the\n> current history by pointing to different commit objects. Some entries\n> matter more than others do. Dead-end experiments stop mattering faster\n> than others. It is these _entries_ that we expire, because keeping them\n> indefinitely is a wasteful clutter.\n\nI have no problem with this point of view, i.e., that expiration is merely\nabout the entries, and that garbage-collecting objects is just a\nside-effect of removed entries.\n\nBut I don't see yet, why an entry pointing to a dead-end experiment is\nless important when it is an entry in a branch reflog than when it is an\nentry in the HEAD reflog. Care to explain?\n\n-- Hannes\n"},{"id":"139601","messageId":"20100415163607.GA4279@coredump.intra.peff.net","threadId":"23461","inReplyTo":"4BC70D75.70801@viscovery.net","subject":"Re: [PATCH 2/2] reflog: ignore expire-unreachable for \"HEAD\" reflog","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-04-15T16:36:07Z","receivedAt":"2010-04-15T16:36:07Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Apr 15, 2010 at 02:58:29PM +0200, Johannes Sixt wrote:\n\n> Am 4/15/2010 14:30, schrieb Junio C Hamano:\n> > A reflog consists of entries, each of which records how you got to the\n> > current history by pointing to different commit objects. Some entries\n> > matter more than others do. Dead-end experiments stop mattering faster\n> > than others. It is these _entries_ that we expire, because keeping them\n> > indefinitely is a wasteful clutter.\n> \n> I have no problem with this point of view, i.e., that expiration is merely\n> about the entries, and that garbage-collecting objects is just a\n> side-effect of removed entries.\n> \n> But I don't see yet, why an entry pointing to a dead-end experiment is\n> less important when it is an entry in a branch reflog than when it is an\n> entry in the HEAD reflog. Care to explain?\n\nI think it is because the reachability test is defined as \"from the\ncurrent ref\". So if I am doing a reachability test on next@{20}, I will\ncheck whether it is in the current version of next. Unreachable things\nare therefore dead-end experiments. But on HEAD, if I do:\n\n $ git checkout topic1\n $ git checkout topic2\n\nThen the entry for HEAD@{1} will be unreachable from the current HEAD,\neven though it is _not_ a failed experiment. It is just that we are no\nlonger pointing to that branch.\n\nI think another way of addressing the same problem would be to redefine\n\"reachable\" in this context as \"reachable from any current ref\".\n\n-Peff\n"},{"id":"139602","messageId":"7vljcok6ds.fsf@alter.siamese.dyndns.org","threadId":"23461","inReplyTo":"4BC70D75.70801@viscovery.net","subject":"Re: [PATCH 2/2] reflog: ignore expire-unreachable for \"HEAD\" reflog","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-04-15T16:49:51Z","receivedAt":"2010-04-15T16:49:51Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Sixt writes:\n\n> But I don't see yet, why an entry pointing to a dead-end experiment is\n> less important when it is an entry in a branch reflog than when it is an\n> entry in the HEAD reflog. Care to explain?\n\nYou can set both expiry criteria to the same timestamp, unless you feel\n\"dead-end experiment is _more_ important\", so I frankly don't see a strong\nneed to explain. The two expiry setting came from the discussion in:\n\n http://thread.gmane.org/gmane.comp.version-control.git/34653/focus=34734\n\nI can understand the \"Oh, I made a commit that adds a huge garbage blob by\nmistake---I want to get rid of it from my odb\" use case. It may go like\nthis:\n\n # starting from master\n git checkout maint ; did something\n git checkout next ; did something\n git checkout master\n git add huge-gunk ; git commit ; oops\n git reset --hard HEAD^\n\n git gc --expire-unreachable=now\n\nIn the current behaviour, HEAD reflog loses everything that is not\nreachable from the current tip, just like the reflog for ordinary\nbranches. You would lose the last pointer to the commit made by mistake\nand the huge blob will immediately be kicked out from the odb.\n\nBut then I have to lose the record that I was working on 'next' before\ncoming to master, while I still have the record that says I was on\n'maint'. That is what \"git checkout -\" (and git log -g HEAD) will give us\nafter the above sequence. I cannot explain how that could possibly be a\nsane behaviour to the users.\n\nIt would be nicer to lose entries that talk about commits that do not\nappear in history of any ref, and we can have the best of both worlds.\nThe patch does not do that, but it should be easy to implement. Instead\nof marking from the tip of the ref that the reflog we are expiring is for,\nwhen expiring HEAD reflog, you would mark from the tips of _all_ the refs\n(and you would need to clean up afterwards the same way).\n"},{"id":"293750","messageId":"7vhbnck618.fsf@alter.siamese.dyndns.org","threadId":"23461","inReplyTo":"20100415163607.GA4279@coredump.intra.peff.net","subject":"Re: [PATCH 2/2] reflog: ignore expire-unreachable for \"HEAD\" reflog","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-04-15T16:57:23Z","receivedAt":"2010-04-15T16:57:23Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> I think another way of addressing the same problem would be to redefine\n> \"reachable\" in this context as \"reachable from any current ref\".\n\nI tend to agree, but I haven't thought through the case for entries that\npoint at commits on detached HEAD. My gut feeling is that unless they are\nconnected to a real ref by now after all these expireunreachable days,\nthey are \"failed experiments\" and deserve to get pruned, so \"from any ref\"\n"},{"id":"139620","messageId":"alpine.LFD.2.00.1004151545240.7232@xanadu.home","threadId":"23461","inReplyTo":"7vhbnck618.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 2/2] reflog: ignore expire-unreachable for \"HEAD\" reflog","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2010-04-15T19:48:23Z","receivedAt":"2010-04-15T19:48:23Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 15 Apr 2010, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > I think another way of addressing the same problem would be to redefine\n> > \"reachable\" in this context as \"reachable from any current ref\".\n> \n> I tend to agree, but I haven't thought through the case for entries that\n> point at commits on detached HEAD. My gut feeling is that unless they are\n> connected to a real ref by now after all these expireunreachable days,\n> they are \"failed experiments\" and deserve to get pruned, so \"from any ref\"\n> would probably work well for them.\n\nI'm a bit worried about this discussion.\n\nWhat's the point of having a reflog for unreachable stuff if it is to be \npruned faster than stuff that is already reachable without any reflog?\n\n\nNicolas\n"},{"id":"139633","messageId":"7v7ho8ibi3.fsf@alter.siamese.dyndns.org","threadId":"23461","inReplyTo":"alpine.LFD.2.00.1004151545240.7232@xanadu.home","subject":"Re: [PATCH 2/2] reflog: ignore expire-unreachable for \"HEAD\" reflog","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-04-15T22:42:12Z","receivedAt":"2010-04-15T22:42:12Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre writes:\n\n> I'm a bit worried about this discussion.\n>\n> What's the point of having a reflog for unreachable stuff if it is to be \n> pruned faster than stuff that is already reachable without any reflog?\n\nTo keep recently failed experiments alive for some time (30 days), but not\noverly long (90 days)?\n"},{"id":"139646","messageId":"alpine.LFD.2.00.1004152059100.7232@xanadu.home","threadId":"23461","inReplyTo":"7v7ho8ibi3.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 2/2] reflog: ignore expire-unreachable for \"HEAD\" reflog","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2010-04-16T01:11:02Z","receivedAt":"2010-04-16T01:11:02Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 15 Apr 2010, Junio C Hamano wrote:\n\n> Nicolas Pitre writes:\n> \n> > I'm a bit worried about this discussion.\n> >\n> > What's the point of having a reflog for unreachable stuff if it is to be \n> > pruned faster than stuff that is already reachable without any reflog?\n> \n> To keep recently failed experiments alive for some time (30 days), but not\n> overly long (90 days)?\n\nWhat is a \"failed\" experiment is still subjective. It might be possible \nto realize that part of it was not that bad after all and some pieces \ncould be worth cherry-picking.\n\nAgain, keeping reflogs 90 days for stuff that is _already_ reachable \nthrough existing refs is much less useful than keeping otherwise \nunreachable stuff 90 days. So I still don't see the point of this \neagerness to prune deleted stuff faster.\n\nIf you explicitly want to get rid of failed experiments then it should \nbe done through an explicit prune command. Otherwise I'd argue that \nreflogs should take care not to lose track of unreachable stuff, even \nmore so than stuff already reachable.\n\nSome people even tried to convince me that reflogs should never expire \nby default, and that the 3 month grace period was already too short.\n\n\nNicolas\n"},{"id":"139647","messageId":"7vljcogot1.fsf@alter.siamese.dyndns.org","threadId":"23461","inReplyTo":"alpine.LFD.2.00.1004152059100.7232@xanadu.home","subject":"Re: [PATCH 2/2] reflog: ignore expire-unreachable for \"HEAD\" reflog","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-04-16T01:37:46Z","receivedAt":"2010-04-16T01:37:46Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre writes:\n\n> Again, keeping reflogs 90 days for stuff that is _already_ reachable \n> through existing refs is much less useful than keeping otherwise \n> unreachable stuff 90 days. So I still don't see the point of this \n> eagerness to prune deleted stuff faster.\n\nHmph, I honestly cannot care about this very much without knowing where\nthis is going, because the distinction between the two has been with us\npractically forever, since the day one of \"reflog expire\".\n\nIs there any constructive conclusion you are aiming for? For example, is\na proposal to update the default value of both to 90 or 120 days coming?\n\nFWIW, I have this in my primary repository.\n\n [gc]\n packrefs = no\n reflogexpire = '2005-01-01 00:00:00 +0000'\n reflogexpireunreachable = '2005-01-01 00:00:00 +0000'\n"},{"id":"139651","messageId":"alpine.LFD.2.00.1004152237060.7232@xanadu.home","threadId":"23461","inReplyTo":"7vljcogot1.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 2/2] reflog: ignore expire-unreachable for \"HEAD\" reflog","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2010-04-16T03:07:43Z","receivedAt":"2010-04-16T03:07:43Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 15 Apr 2010, Junio C Hamano wrote:\n\n> Nicolas Pitre writes:\n> \n> > Again, keeping reflogs 90 days for stuff that is _already_ reachable \n> > through existing refs is much less useful than keeping otherwise \n> > unreachable stuff 90 days. So I still don't see the point of this \n> > eagerness to prune deleted stuff faster.\n> \n> Hmph, I honestly cannot care about this very much without knowing where\n> this is going, because the distinction between the two has been with us\n> practically forever, since the day one of \"reflog expire\".\n\nArgh. OK you can paint me confused. I was mixing up \n--expire-unreachable with --stale-fix.\n\nHaving my head screwed back on now, I do agree with Jeff when he says:\n\n|I think another way of addressing the same problem would be to redefine\n|\"reachable\" in this context as \"reachable from any current ref\".\n\nOtherwise having a special exception for HEAD would effectively make \nthose unreachable objects non prunable until the HEAD reflog entries are \nthemselves expired.\n\n> Is there any constructive conclusion you are aiming for? For example, is\n> a proposal to update the default value of both to 90 or 120 days coming?\n\nI think that the default value for reflogexpireunreachable should be the \nvalue of reflogexpire, and not 30 days. In my opinion, having a shorter \nexpiration period for non reachable objects by default makes little \nsense. Again, it is for the non reachable objects that the reflog is \nmost useful.\n\n\nNicolas\n"},{"id":"139653","messageId":"4BC7FECA.2010202@viscovery.net","threadId":"23461","inReplyTo":"20100415163607.GA4279@coredump.intra.peff.net","subject":"Re: [PATCH 2/2] reflog: ignore expire-unreachable for \"HEAD\" reflog","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2010-04-16T06:08:10Z","receivedAt":"2010-04-16T06:08:10Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 4/15/2010 18:36, schrieb Jeff King:\n> I think it is because the reachability test is defined as \"from the\n> current ref\".\n\nThanks, this clears my confusion. I see the problem that Junio wants to\nfix, but IMHO this:\n\n> I think another way of addressing the same problem would be to redefine\n> \"reachable\" in this context as \"reachable from any current ref\".\n\nwould be a better approach for a fix rather than an exception for HEAD.\n\n-- Hannes\n"}]}