{"thread":{"id":"14171","subject":"bug related to branches using / in name","startedAt":"2008-06-26T19:42:30Z","lastAt":"2008-06-28T11:42:58Z","messageCount":13,"participants":["Simon Holm Thøgersen","Jeff King","Junio C Hamano","Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"81321","messageId":"1214509350.28344.31.camel@odie.local","threadId":"14171","inReplyTo":null,"subject":"bug related to branches using / in name","fromName":"Simon Holm Thøgersen","fromEmail":"odie@cs.aau.dk","sentAt":"2008-06-26T19:42:30Z","receivedAt":"2008-06-26T19:42:30Z","isPatch":false,"sender":{"key":"odie@cs.aau.dk","avatar":null},"body":"Hi git community\n\nI have a bug report I think is most easily explained by a list of\ncommands that illustrates the bug.\n\ncd /tmp\nmkdir git-bug\ncd git-bug\ngit init\ntouch foo\ngit add foo\ngit commit -a -m '...'\ngit branch sched\ngit clone file:///tmp/git-bug /tmp/git-bug-clone\ngit branch -d sched\ngit branch sched/urgent\ngit branch sched/devel\ncd /tmp/git-bug-clone\ngit pull\n\nThe last command does not succeed, but produces the following output\n\nerror: unable to resolve reference refs/remotes/origin/sched/devel: Not\na directory\n>From file:///tmp/git-bug\n * [new branch]      sched/devel -> origin/sched/devel\nerror: unable to resolve reference refs/remotes/origin/sched/urgent: Not\na directory\n * [new branch]      sched/urgent -> origin/sched/urgent\n\nI can work around it by\nrm /tmp/git-bug-clone/.git/{,logs/}refs/remotes/origin/sched\n\nbut git should take care of this automatically, right?\n\nI'm on git version 1.5.6.\n\n\nSimon Holm Thøgersen\n"},{"id":"81355","messageId":"20080627030245.GA7144@sigill.intra.peff.net","threadId":"14171","inReplyTo":"1214509350.28344.31.camel@odie.local","subject":"Re: bug related to branches using / in name","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-06-27T03:02:46Z","receivedAt":"2008-06-27T03:02:46Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Jun 26, 2008 at 09:42:30PM +0200, Simon Holm Thøgersen wrote:\n\n> The last command does not succeed, but produces the following output\n> \n> error: unable to resolve reference refs/remotes/origin/sched/devel: Not\n> a directory\n> >From file:///tmp/git-bug\n>  * [new branch]      sched/devel -> origin/sched/devel\n> error: unable to resolve reference refs/remotes/origin/sched/urgent: Not\n> a directory\n>  * [new branch]      sched/urgent -> origin/sched/urgent\n\nSo to summarize, the problem is that you have an old tracking branch\n\"refs/remotes/sched\" that exists on the client, but upstream has since\nremoved it in favor of \"sched/devel\", which you are now trying to fetch.\nAnd of course there is a conflict, because of the ref naming rules.\n\nThis doesn't work seamlessly because git-fetch never removes old\ntracking branches, even if they have been deleted upstream. And normally\nthere is no conflict; leaving the old branches means they don't\ndisappear from under you.\n\nIn this case, of course, it's inconvenient. The \"right\" way to solve it\nis to tell git to clean up your tracking branches for \"origin\":\n\n  git remote prune origin\n\nwhich should delete the old \"sched\" tracking branch (since it no longer\nexists on the remote), and then you are free to fetch.\n\nIt might be nicer if this were handled automatically, but it would\nviolate git-fetch's rule about never deleting branches. And presumably\nthis comes up infrequently enough that it isn't a problem. Perhaps a\nbetter error message suggesting git-prune might make sense?\n\n-Peff\n"},{"id":"81356","messageId":"20080627030422.GB7144@sigill.intra.peff.net","threadId":"14171","inReplyTo":"20080627030245.GA7144@sigill.intra.peff.net","subject":"Re: bug related to branches using / in name","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-06-27T03:04:23Z","receivedAt":"2008-06-27T03:04:23Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Jun 26, 2008 at 11:02:46PM -0400, Jeff King wrote:\n\n> So to summarize, the problem is that you have an old tracking branch\n> \"refs/remotes/sched\" that exists on the client, but upstream has since\n> removed it in favor of \"sched/devel\", which you are now trying to fetch.\n> And of course there is a conflict, because of the ref naming rules.\n> \n> This doesn't work seamlessly because git-fetch never removes old\n> tracking branches, even if they have been deleted upstream. And normally\n> there is no conflict; leaving the old branches means they don't\n> disappear from under you.\n\nBTW, you can get the opposite problem, too. If you have\n\"refs/remotes/origin/foo/bar\", and then the remote removes \"foo/bar\" in\nfavor of \"foo\", you will have a conflict on fetch.\n\n-Peff\n"},{"id":"81357","messageId":"20080627035747.GC7144@sigill.intra.peff.net","threadId":"14171","inReplyTo":"20080627030245.GA7144@sigill.intra.peff.net","subject":"Re: bug related to branches using / in name","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-06-27T03:57:47Z","receivedAt":"2008-06-27T03:57:47Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Jun 26, 2008 at 11:02:46PM -0400, Jeff King wrote:\n\n> It might be nicer if this were handled automatically, but it would\n> violate git-fetch's rule about never deleting branches. And presumably\n> this comes up infrequently enough that it isn't a problem. Perhaps a\n> better error message suggesting git-prune might make sense?\n\nAnd here is a 2-patch series improving the error reporting for this\ncase (and it also helps with some other cases). I'm a little iffy on\n2/2, since we don't actually _know_ that remote pruning will help. But\npropagating specific errors up through the call chain would require\nreasonably major surgery.\n\n  1/2: fetch: give a hint to the user when local refs fail to update\n  2/2: fetch: report local storage errors in status table\n\n-Peff\n"},{"id":"81358","messageId":"20080627035950.GA21382@sigill.intra.peff.net","threadId":"14171","inReplyTo":"20080627035747.GC7144@sigill.intra.peff.net","subject":"[PATCH] fetch: report local storage errors in status table","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-06-27T03:59:50Z","receivedAt":"2008-06-27T03:59:50Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"Previously, if there was an error while storing a local\ntracking ref, the low-level functions would report an error,\nbut fetch's status output wouldn't indicate any problem.\nE.g., imagine you have an old \"refs/remotes/origin/foo/bar\" but\nupstream has deleted \"foo/bar\" in favor of a new branch\n\"foo\". You would get output like this:\n\n  error: there are still refs under 'refs/remotes/origin/foo'\n  From $url_of_repo\n   * [new branch]      foo        -> origin/foo\n\nWith this patch, the output takes into account the status of\nupdating the local ref:\n\n  error: there are still refs under 'refs/remotes/origin/foo'\n  From $url_of_repo\n   ! [new branch]      foo        -> origin/foo  (unable to update local ref)\n\nSigned-off-by: Jeff King <peff@peff.net>\n---\n builtin-fetch.c |   36 ++++++++++++++++++++++++------------\n 1 files changed, 24 insertions(+), 12 deletions(-)\n\ndiff --git a/builtin-fetch.c b/builtin-fetch.c\nindex e81ee2d..7c16d38 100644\n--- a/builtin-fetch.c\n+++ b/builtin-fetch.c\n@@ -233,10 +233,12 @@ static int update_local_ref(struct ref *ref,\n \n \tif (!is_null_sha1(ref->old_sha1) &&\n \t    !prefixcmp(ref->name, \"refs/tags/\")) {\n-\t\tsprintf(display, \"- %-*s %-*s -> %s\",\n+\t\tint r;\n+\t\tr = s_update_ref(\"updating tag\", ref, 0);\n+\t\tsprintf(display, \"%c %-*s %-*s -> %s%s\", r ? '!' : '-',\n \t\t\tSUMMARY_WIDTH, \"[tag update]\", REFCOL_WIDTH, remote,\n-\t\t\tpretty_ref);\n-\t\treturn s_update_ref(\"updating tag\", ref, 0);\n+\t\t\tpretty_ref, r ? \"  (unable to update local ref)\" : \"\");\n+\t\treturn r;\n \t}\n \n \tcurrent = lookup_commit_reference_gently(ref->old_sha1, 1);\n@@ -244,6 +246,7 @@ static int update_local_ref(struct ref *ref,\n \tif (!current || !updated) {\n \t\tconst char *msg;\n \t\tconst char *what;\n+\t\tint r;\n \t\tif (!strncmp(ref->name, \"refs/tags/\", 10)) {\n \t\t\tmsg = \"storing tag\";\n \t\t\twhat = \"[new tag]\";\n@@ -253,27 +256,36 @@ static int update_local_ref(struct ref *ref,\n \t\t\twhat = \"[new branch]\";\n \t\t}\n \n-\t\tsprintf(display, \"* %-*s %-*s -> %s\", SUMMARY_WIDTH, what,\n-\t\t\tREFCOL_WIDTH, remote, pretty_ref);\n-\t\treturn s_update_ref(msg, ref, 0);\n+\t\tr = s_update_ref(msg, ref, 0);\n+\t\tsprintf(display, \"%c %-*s %-*s -> %s%s\", r ? '!' : '*',\n+\t\t\tSUMMARY_WIDTH, what, REFCOL_WIDTH, remote, pretty_ref,\n+\t\t\tr ? \"  (unable to update local ref)\" : \"\");\n+\t\treturn r;\n \t}\n \n \tif (in_merge_bases(current, &updated, 1)) {\n \t\tchar quickref[83];\n+\t\tint r;\n \t\tstrcpy(quickref, find_unique_abbrev(current->object.sha1, DEFAULT_ABBREV));\n \t\tstrcat(quickref, \"..\");\n \t\tstrcat(quickref, find_unique_abbrev(ref->new_sha1, DEFAULT_ABBREV));\n-\t\tsprintf(display, \"  %-*s %-*s -> %s\", SUMMARY_WIDTH, quickref,\n-\t\t\tREFCOL_WIDTH, remote, pretty_ref);\n-\t\treturn s_update_ref(\"fast forward\", ref, 1);\n+\t\tr = s_update_ref(\"fast forward\", ref, 1);\n+\t\tsprintf(display, \"%c %-*s %-*s -> %s%s\", r ? '!' : ' ',\n+\t\t\tSUMMARY_WIDTH, quickref, REFCOL_WIDTH, remote,\n+\t\t\tpretty_ref, r ? \"  (unable to update local ref)\" : \"\");\n+\t\treturn r;\n \t} else if (force || ref->force) {\n \t\tchar quickref[84];\n+\t\tint r;\n \t\tstrcpy(quickref, find_unique_abbrev(current->object.sha1, DEFAULT_ABBREV));\n \t\tstrcat(quickref, \"...\");\n \t\tstrcat(quickref, find_unique_abbrev(ref->new_sha1, DEFAULT_ABBREV));\n-\t\tsprintf(display, \"+ %-*s %-*s -> %s  (forced update)\",\n-\t\t\tSUMMARY_WIDTH, quickref, REFCOL_WIDTH, remote, pretty_ref);\n-\t\treturn s_update_ref(\"forced-update\", ref, 1);\n+\t\tr = s_update_ref(\"forced-update\", ref, 1);\n+\t\tsprintf(display, \"%c %-*s %-*s -> %s  (%s)\", r ? '!' : '+',\n+\t\t\tSUMMARY_WIDTH, quickref, REFCOL_WIDTH, remote,\n+\t\t\tpretty_ref,\n+\t\t\tr ? \"unable to update local ref\" : \"forced update\");\n+\t\treturn r;\n \t} else {\n \t\tsprintf(display, \"! %-*s %-*s -> %s  (non fast forward)\",\n \t\t\tSUMMARY_WIDTH, \"[rejected]\", REFCOL_WIDTH, remote,\n-- \n1.5.6.1.79.g7b3a7.dirty\n"},{"id":"81359","messageId":"20080627040140.GB21382@sigill.intra.peff.net","threadId":"14171","inReplyTo":"20080627035747.GC7144@sigill.intra.peff.net","subject":"[PATCH 2/2] fetch: give a hint to the user when local refs fail to update","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-06-27T04:01:41Z","receivedAt":"2008-06-27T04:01:41Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"There are basically two categories of update failures for\nlocal refs:\n\n  1. problems outside of git, like disk full, bad\n     permissions, etc.\n\n  2. D/F conflicts on tracking branch ref names\n\nIn either case, there should already have been an error\nmessage. In case '1', hopefully enough information has\nalready been given that the user can fix it. In the case of\n'2', we can hint that the user can clean up their tracking\nbranch area by using 'git remote prune'.\n\nNote that we don't actually know _which_ case we have, so\nthe user will receive the hint in case 1, as well. In this\ncase the suggestion won't do any good, but hopefully the\nuser is smart enough to figure out that it's just a hint.\n\nSigned-off-by: Jeff King <peff@peff.net>\n---\nActually, I think there might be a third category, \"bad ref format\".\nBut that would only come from a malicious remote trying to send you a\nbadly formatted ref, so I think that is rare enough not to worry about\nshowing the extra hint there.\n\n builtin-fetch.c |   15 +++++++++++----\n 1 files changed, 11 insertions(+), 4 deletions(-)\n\ndiff --git a/builtin-fetch.c b/builtin-fetch.c\nindex 7c16d38..97fdc51 100644\n--- a/builtin-fetch.c\n+++ b/builtin-fetch.c\n@@ -181,9 +181,9 @@ static int s_update_ref(const char *action,\n \tlock = lock_any_ref_for_update(ref->name,\n \t\t\t\t       check_old ? ref->old_sha1 : NULL, 0);\n \tif (!lock)\n-\t\treturn 1;\n+\t\treturn 2;\n \tif (write_ref_sha1(lock, ref->new_sha1, msg) < 0)\n-\t\treturn 1;\n+\t\treturn 2;\n \treturn 0;\n }\n \n@@ -294,7 +294,8 @@ static int update_local_ref(struct ref *ref,\n \t}\n }\n \n-static int store_updated_refs(const char *url, struct ref *ref_map)\n+static int store_updated_refs(const char *url, const char *remote_name,\n+\t\tstruct ref *ref_map)\n {\n \tFILE *fp;\n \tstruct commit *commit;\n@@ -380,6 +381,10 @@ static int store_updated_refs(const char *url, struct ref *ref_map)\n \t\t}\n \t}\n \tfclose(fp);\n+\tif (rc & 2)\n+\t\terror(\"some local refs could not be updated; try running\\n\"\n+\t\t      \" 'git remote prune %s' to remove any old, conflicting \"\n+\t\t      \"branches\", remote_name);\n \treturn rc;\n }\n \n@@ -450,7 +455,9 @@ static int fetch_refs(struct transport *transport, struct ref *ref_map)\n \tif (ret)\n \t\tret = transport_fetch_refs(transport, ref_map);\n \tif (!ret)\n-\t\tret |= store_updated_refs(transport->url, ref_map);\n+\t\tret |= store_updated_refs(transport->url,\n+\t\t\t\ttransport->remote->name,\n+\t\t\t\tref_map);\n \ttransport_unlock_pack(transport);\n \treturn ret;\n }\n-- \n1.5.6.1.79.g7b3a7.dirty\n"},{"id":"81370","messageId":"1214555532.10090.18.camel@odie.local","threadId":"14171","inReplyTo":"20080627030422.GB7144@sigill.intra.peff.net","subject":"Re: bug related to branches using / in name","fromName":"Simon Holm Thøgersen","fromEmail":"odie@cs.aau.dk","sentAt":"2008-06-27T08:32:12Z","receivedAt":"2008-06-27T08:32:12Z","isPatch":false,"sender":{"key":"odie@cs.aau.dk","avatar":null},"body":"Jeff King wrote:\n> Jeff King wrote:\n> \n> > So to summarize, the problem is that you have an old tracking branch\n> > \"refs/remotes/sched\" that exists on the client, but upstream has since\n> > removed it in favor of \"sched/devel\", which you are now trying to fetch.\n> > And of course there is a conflict, because of the ref naming rules.\n> > \n> > This doesn't work seamlessly because git-fetch never removes old\n> > tracking branches, even if they have been deleted upstream. And normally\n> > there is no conflict; leaving the old branches means they don't\n> > disappear from under you.\n> \nYour summary is correct, but I cannot entirely convince myself that\nleaving old branches available is valid in any work flow. But what do I\nknow.\n\n> BTW, you can get the opposite problem, too. If you have\n> \"refs/remotes/origin/foo/bar\", and then the remote removes \"foo/bar\" in\n> favor of \"foo\", you will have a conflict on fetch.\n> \nYes, and you can also hit a similar problem using git-push, but I guess\nthat the user is a bit more aware about what is going on in that case\nand is able resolve the problem without hints.\n\nI tested the two patches and they did indeed seem to do what you\nintended them to for my test case. The solution is not exactly pretty,\nbut it is better than nothing and it is admittedly a corner case.\n\nThank you for your time on this Jeff.\n\n\nSimon Holm Thøgersen\n"},{"id":"81516","messageId":"7vtzfemp4d.fsf@gitster.siamese.dyndns.org","threadId":"14171","inReplyTo":"20080627035747.GC7144@sigill.intra.peff.net","subject":"Re: bug related to branches using / in name","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-06-27T23:31:30Z","receivedAt":"2008-06-27T23:31:30Z","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, Jun 26, 2008 at 11:02:46PM -0400, Jeff King wrote:\n>\n>> It might be nicer if this were handled automatically, but it would\n>> violate git-fetch's rule about never deleting branches.\n\nHmm.  Is there actually such a rule?\n\nI was wondering if it might make more sense to do the equivalent of what\ncheckout_entry() does (i.e. remove_subtree()) when there is such a\nconflict.  After all, tracking branches are meant to accept rewinds and\nanything that happens on the remote end, and having to run \"git remote\nprune\" is not a feature but is a lack of feature in the \"git fetch\", which\nmay make it look like deletion is somewhat special.\n"},{"id":"81517","messageId":"7vprq2moua.fsf@gitster.siamese.dyndns.org","threadId":"14171","inReplyTo":"20080627035950.GA21382@sigill.intra.peff.net","subject":"Re: [PATCH] fetch: report local storage errors in status table","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-06-27T23:37:33Z","receivedAt":"2008-06-27T23:37:33Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> Previously, if there was an error while storing a local\n> tracking ref, the low-level functions would report an error,\n> but fetch's status output wouldn't indicate any problem.\n> E.g., imagine you have an old \"refs/remotes/origin/foo/bar\" but\n> upstream has deleted \"foo/bar\" in favor of a new branch\n> \"foo\". You would get output like this:\n>\n>   error: there are still refs under 'refs/remotes/origin/foo'\n>   From $url_of_repo\n>    * [new branch]      foo        -> origin/foo\n>\n> With this patch, the output takes into account the status of\n> updating the local ref:\n>\n>   error: there are still refs under 'refs/remotes/origin/foo'\n>   From $url_of_repo\n>    ! [new branch]      foo        -> origin/foo  (unable to update local ref)\n>\n> Signed-off-by: Jeff King <peff@peff.net>\n\nMakes sense --- thanks.  This is something we can have automated tests,\nisn't it?\n"},{"id":"81537","messageId":"20080628041841.GA9451@sigill.intra.peff.net","threadId":"14171","inReplyTo":"7vtzfemp4d.fsf@gitster.siamese.dyndns.org","subject":"Re: bug related to branches using / in name","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-06-28T04:18:41Z","receivedAt":"2008-06-28T04:18:41Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jun 27, 2008 at 04:31:30PM -0700, Junio C Hamano wrote:\n\n> >> It might be nicer if this were handled automatically, but it would\n> >> violate git-fetch's rule about never deleting branches.\n> \n> Hmm.  Is there actually such a rule?\n\nI thought so, though I don't necessarily agree with it. But I seem to\nrecall this being touted as a feature in the past; a remote deleting\nsome work will not cause it to be deleted locally.\n\n> I was wondering if it might make more sense to do the equivalent of what\n> checkout_entry() does (i.e. remove_subtree()) when there is such a\n\nAs as long your \"equivalent of\" means \"branch -d\"; we need to kill off\nboth the ref and its reflogs. And therefore...\n\n> conflict.  After all, tracking branches are meant to accept rewinds and\n> anything that happens on the remote end, and having to run \"git remote\n> prune\" is not a feature but is a lack of feature in the \"git fetch\", which\n> may make it look like deletion is somewhat special.\n\nThe one key difference between rewinds and branch deletion is that the\nlatter will kill off the reflog, making the history inaccessible. You\ncan always still access rewound or rebased work via the reflog.\n\nIf we don't care about this \"safety feature\", then I definitely agree\nthat we should fix the problem rather than hint to the user.\n\n-Peff\n"},{"id":"81538","messageId":"20080628042114.GB9451@sigill.intra.peff.net","threadId":"14171","inReplyTo":"7vprq2moua.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] fetch: report local storage errors in status table","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-06-28T04:21:15Z","receivedAt":"2008-06-28T04:21:15Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jun 27, 2008 at 04:37:33PM -0700, Junio C Hamano wrote:\n\n> > With this patch, the output takes into account the status of\n> > updating the local ref:\n> >\n> >   error: there are still refs under 'refs/remotes/origin/foo'\n> >   From $url_of_repo\n> >    ! [new branch]      foo        -> origin/foo  (unable to update local ref)\n>\n> Makes sense --- thanks.  This is something we can have automated tests,\n> isn't it?\n\nWe don't currently have any tests for either the fetch output or the\npush output. Note that we aren't changing the output _status_. Fetch\nalways knew that this condition was a failure, and exited appropriately.\nSo it really would just be testing the expected human-readable output in\nthese situations, something I thought we usually didn't include in the\ntests.\n\nBut if you think it is worth doing, I can whip up a few tests.\n\n-Peff\n"},{"id":"81542","messageId":"7v7icakvgd.fsf@gitster.siamese.dyndns.org","threadId":"14171","inReplyTo":"20080628041841.GA9451@sigill.intra.peff.net","subject":"Re: bug related to branches using / in name","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-06-28T04:57:38Z","receivedAt":"2008-06-28T04:57:38Z","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> As as long your \"equivalent of\" means \"branch -d\"; we need to kill off\n> both the ref and its reflogs. And therefore...\n> ...\n> The one key difference between rewinds and branch deletion is that the\n> latter will kill off the reflog, making the history inaccessible. You\n> can always still access rewound or rebased work via the reflog.\n\nHmm, you are right.\n\nI somehow still had a vague distant memory from late 2006 when we did not\nhave reflogs for remotes/ hierarchy.\n"},{"id":"81549","messageId":"m3hcbdiy4k.fsf@localhost.localdomain","threadId":"14171","inReplyTo":"20080628041841.GA9451@sigill.intra.peff.net","subject":"Re: bug related to branches using / in name","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-06-28T11:42:58Z","receivedAt":"2008-06-28T11:42:58Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jeff King <peff@peff.net> writes:\n> On Fri, Jun 27, 2008 at 04:31:30PM -0700, Junio C Hamano wrote:\n>> \n>> [...]  After all, tracking branches are meant to accept rewinds and\n>> anything that happens on the remote end, and having to run \"git remote\n>> prune\" is not a feature but is a lack of feature in the \"git fetch\", which\n>> may make it look like deletion is somewhat special.\n> \n> The one key difference between rewinds and branch deletion is that the\n> latter will kill off the reflog, making the history inaccessible. You\n> can always still access rewound or rebased work via the reflog.\n> \n> If we don't care about this \"safety feature\", then I definitely agree\n> that we should fix the problem rather than hint to the user.\n\nThere were some attempts to add some kind of \"Attic\" to save\nreflogs for deleted branches, but IIRC the discussion petered out\nafter few initial patches because there were some conflict over\ndetails of implementation (the problem being how to deal with D/F\nconflicts).\n\nIf this makes into git, this trouble will disappear... perhaps\nwith some stronger marker that branches can dissapear, not only\nrewind\n\n        +!refs/heads/*:refs/remotes/origin/*\n\nor\n\n        +refs/heads/*?:refs/remotes/origin/*?\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"}]}