{"thread":{"id":"42259","subject":"Force-with-lease and new branches","startedAt":"2016-05-07T18:09:14Z","lastAt":"2016-05-08T18:29:47Z","messageCount":2,"participants":["John Keeping","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"285826","messageId":"20160507180914.GR14612@serenity.lan","threadId":"42259","inReplyTo":null,"subject":"Force-with-lease and new branches","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2016-05-07T18:09:14Z","receivedAt":"2016-05-07T18:09:14Z","isPatch":false,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"I've noticed a slightly annoying behaviour of git-push's\n--force-with-lease option around branch creation.\n\nI'd like to be able to do:\n\n\tgit push --force-with-lease origin refs/heads/jk/*\n\nto push out a load of topic branches safely in case I've switched client\nmachines and forgotten to pull, but for newly-created branches this\nfails with \"stale-info\", which seems to be intentional via the\nexpect_old_no_trackback field in struct ref.\n\nHowever, if I use the explicit --force-with-lease syntax with the null\nhash then the push does succeed.  I've added a couple of tests to t5533\nwhich demonstrate this in a patch below - the first one fails but the\nsecond passes.\n\nIt looks like this has been the case since the first version of what\nwould become --force-with-lease [1] and I can't find any discussion\naround this particular behaviour in the three versions of that patch set\nI found on Gmane [2], [3], [4].\n\nSo my questions are: what will break if we decide to treat \"no remote\ntracking branch\" as \"new branch\" and is that a reasonable thing to do?\n\n\n[1] http://article.gmane.org/gmane.comp.version-control.git/229992\n[2] http://article.gmane.org/gmane.comp.version-control.git/229430\n[3] http://article.gmane.org/gmane.comp.version-control.git/230142\n[4] http://article.gmane.org/gmane.comp.version-control.git/231021\n\n\n-- >8 --\ndiff --git a/t/t5533-push-cas.sh b/t/t5533-push-cas.sh\nindex c732012..ad9e06f 100755\n--- a/t/t5533-push-cas.sh\n+++ b/t/t5533-push-cas.sh\n@@ -191,4 +191,28 @@ test_expect_success 'cover everything with default force-with-lease (allowed)' '\n \ttest_cmp expect actual\n '\n \n+test_expect_success 'new branch covered by force-with-lease' '\n+\tsetup_srcdst_basic &&\n+\t(\n+\t\tcd dst &&\n+\t\tgit branch branch master &&\n+\t\tgit push --force-with-lease=branch origin branch\n+\t) &&\n+\tgit ls-remote dst refs/heads/branch >expect &&\n+\tgit ls-remote src refs/heads/branch >actual &&\n+\ttest_cmp expect actual\n+'\n+\n+test_expect_success 'new branch with explicit force-with-lease' '\n+\tsetup_srcdst_basic &&\n+\t(\n+\t\tcd dst &&\n+\t\tgit branch branch master &&\n+\t\tgit push --force-with-lease=branch:0000000000000000000000000000000000000000 origin branch\n+\t) &&\n+\tgit ls-remote dst refs/heads/branch >expect &&\n+\tgit ls-remote src refs/heads/branch >actual &&\n+\ttest_cmp expect actual\n+'\n+\n test_done\n"},{"id":"285895","messageId":"xmqqfutsz9lw.fsf@gitster.mtv.corp.google.com","threadId":"42259","inReplyTo":"20160507180914.GR14612@serenity.lan","subject":"Re: Force-with-lease and new branches","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-05-08T18:29:47Z","receivedAt":"2016-05-08T18:29:47Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"John Keeping <john@keeping.me.uk> writes:\n\n> It looks like this has been the case since the first version of what\n> would become --force-with-lease [1] and I can't find any discussion\n> around this particular behaviour in the three versions of that patch set\n> I found on Gmane [2], [3], [4].\n\nI never considered the \"creation of a new ref, ensuring that it must\nnot exist yet\" use case when designing it.  I do not think anybody\nin the discussion did so, either.\n\n> So my questions are: what will break if we decide to treat \"no remote\n> tracking branch\" as \"new branch\" and is that a reasonable thing to do?\n\nIf you are only following a subset of branches they have, you may\nnever get copies of them in your refs/remotes/$there/ hierarchy, so\nyour addition would make 'force-with-lease to create' mistakenly\nthink that a branch does not exist over there, when there is already\none, and it will attempt to push your version through.  As long as\nthat is caught and fail on the receiving end of the request, it is\nOK, I would think.  I didn't think it through nor checked the code\nto make sure the remote end behaves sensibly--please do so yourself\nif you want to pursue this route ;-).\n\nThanks.\n"}]}