Thread (1 message) 1 message, 1 author, 2016-06-15

Re: [PATCH v2] Add push --set-upstream

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:48:02

Ilari Liusvaara [off-list ref] writes:
quoted hunk
@@ -974,6 +1016,10 @@ int transport_push(struct transport *transport,
 	verify_remote_names(refspec_nr, refspec);
 
 	if (transport->push) {
+		/* Maybe FIXME. But no important transport uses this case. */
+		if (flags & TRANSPORT_PUSH_SET_UPSTREAM)
+			die("This transport does not support using --set-upstream");
+
Would it be better to just warn() and continue instead of dying?  I think
it can be argued both ways, and I personally think die() is better by
making it more visible that the user does not have the config s/he wanted
to add, but I am pointing it out just in case somebody thinks of a better
solution (of course, doing an extra ls-remote and doing the configuration
is such a "better solution" but that is not what I mean---I am not that
greedy).
quoted hunk
@@ -1002,6 +1048,9 @@ int transport_push(struct transport *transport,
 					verbose | porcelain, porcelain,
 					nonfastforward);
 
+		if (flags & TRANSPORT_PUSH_SET_UPSTREAM)
+			set_upstreams(transport, remote_refs);
+
 		if (!(flags & TRANSPORT_PUSH_DRY_RUN)) {
 			struct ref *ref;
 			for (ref = remote_refs; ref; ref = ref->next)
Shouldn't this honor TRANSPORT_PUSH_DRY_RUN?  IOW, when should it touch
the configuration if you do this sequence?

	# I am paranoid and want to check what happens first
	git push -n --track there this
        # Ok let's do it for real.
        git push    --track there this
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help