Force-with-lease and new branches

Force-with-lease and new branches

[John Keeping]

I've noticed a slightly annoying behaviour of git-push's
--force-with-lease option around branch creation.

I'd like to be able to do:

	git push --force-with-lease origin refs/heads/jk/*

to push out a load of topic branches safely in case I've switched client
machines and forgotten to pull, but for newly-created branches this
fails with "stale-info", which seems to be intentional via the
expect_old_no_trackback field in struct ref.

However, if I use the explicit --force-with-lease syntax with the null
hash then the push does succeed.  I've added a couple of tests to t5533
which demonstrate this in a patch below - the first one fails but the
second passes.

It looks like this has been the case since the first version of what
would become --force-with-lease [1] and I can't find any discussion
around this particular behaviour in the three versions of that patch set
I found on Gmane [2], [3], [4].

So my questions are: what will break if we decide to treat "no remote
tracking branch" as "new branch" and is that a reasonable thing to do?


[1] http://article.gmane.org/gmane.comp.version-control.git/229992
[2] http://article.gmane.org/gmane.comp.version-control.git/229430
[3] http://article.gmane.org/gmane.comp.version-control.git/230142
[4] http://article.gmane.org/gmane.comp.version-control.git/231021


-- >8 --
diff --git a/t/t5533-push-cas.sh b/t/t5533-push-cas.sh
index c732012..ad9e06f 100755
--- a/t/t5533-push-cas.sh
+++ b/t/t5533-push-cas.sh
@@ -191,4 +191,28 @@ test_expect_success 'cover everything with default force-with-lease (allowed)' '
 	test_cmp expect actual
 '
 
+test_expect_success 'new branch covered by force-with-lease' '
+	setup_srcdst_basic &&
+	(
+		cd dst &&
+		git branch branch master &&
+		git push --force-with-lease=branch origin branch
+	) &&
+	git ls-remote dst refs/heads/branch >expect &&
+	git ls-remote src refs/heads/branch >actual &&
+	test_cmp expect actual
+'
+
+test_expect_success 'new branch with explicit force-with-lease' '
+	setup_srcdst_basic &&
+	(
+		cd dst &&
+		git branch branch master &&
+		git push --force-with-lease=branch:0000000000000000000000000000000000000000 origin branch
+	) &&
+	git ls-remote dst refs/heads/branch >expect &&
+	git ls-remote src refs/heads/branch >actual &&
+	test_cmp expect actual
+'
+
 test_done

Re: Force-with-lease and new branches

[Junio C Hamano]

John Keeping <john@keeping.me.uk> writes:

> It looks like this has been the case since the first version of what
> would become --force-with-lease [1] and I can't find any discussion
> around this particular behaviour in the three versions of that patch set
> I found on Gmane [2], [3], [4].

I never considered the "creation of a new ref, ensuring that it must
not exist yet" use case when designing it.  I do not think anybody
in the discussion did so, either.

> So my questions are: what will break if we decide to treat "no remote
> tracking branch" as "new branch" and is that a reasonable thing to do?

If you are only following a subset of branches they have, you may
never get copies of them in your refs/remotes/$there/ hierarchy, so
your addition would make 'force-with-lease to create' mistakenly
think that a branch does not exist over there, when there is already
one, and it will attempt to push your version through.  As long as
that is caught and fail on the receiving end of the request, it is
OK, I would think.  I didn't think it through nor checked the code
to make sure the remote end behaves sensibly--please do so yourself
if you want to pursue this route ;-).

Thanks.