[RFC/PATCH 0/3] New kind of upstream branch: downstream branch

[RFC/PATCH 0/3] New kind of upstream branch: downstream branch

[Felipe Contreras]

Hi,

After thinking a bit more about, I think the current 'upstream' branch serves
most of the purposes; actually tracks an upstream branch; makes sense to rebase
onto that, makes sense to fetch from that remote, merge, and pull.

The only job it doesn't make sense to use the 'upstream' branch for is to push,
so here's a new notion of 'downstream' branch.

These patches are only exploratory, 'git branch -v' doesn't show these
branches, there's no @{downstream}, no documentation, and there isn't even a
way to set it.

If there's no downstream branch configured, nothing changes.

Felipe Contreras (3):
  remote: don't override default if cur head remote is '.'
  pull: trivial cleanups
  push: add separate 'downstream' branch

 builtin/push.c | 65 ++++++++++++++++++++++++++++++++++++----------------------
 git-pull.sh    | 15 +++++++++-----
 remote.c       | 10 ++++++---
 remote.h       |  3 +++
 4 files changed, 61 insertions(+), 32 deletions(-)

-- 
1.8.3.rc1.579.g184e698

[RFC/PATCH 1/3] remote: don't override default if cur head remote is '.'

[Felipe Contreras]

'git fetch .' makes no sense, so let's keep using the default ('origin')
when the current branch's remote is '.'.

Also update 'git pull' so that pulling works the same way as before.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 git-pull.sh | 9 ++++++++-
 remote.c    | 2 +-
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/git-pull.sh b/git-pull.sh
index 638aabb..75297c7 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -220,7 +220,14 @@ test true = "$rebase" && {
 	done
 }
 orig_head=$(git rev-parse -q --verify HEAD)
-git fetch $verbosity $progress $dry_run $recurse_submodules --update-head-ok "$@" || exit 1
+# get the default remote
+remote="$(git config "branch.$curr_branch_short.remote")"
+if test $# == 0 && test -n "$remote"
+then
+	git fetch $verbosity $progress $dry_run $recurse_submodules --update-head-ok "$remote" || exit 1
+else
+	git fetch $verbosity $progress $dry_run $recurse_submodules --update-head-ok "$@" || exit 1
+fi
 test -z "$dry_run" || exit 0
 
 curr_head=$(git rev-parse -q --verify HEAD)
diff --git a/remote.c b/remote.c
index 68eb99b..322a1b6 100644
--- a/remote.c
+++ b/remote.c
@@ -360,7 +360,7 @@ static int handle_config(const char *key, const char *value, void *cb)
 		if (!strcmp(subkey, ".remote")) {
 			if (git_config_string(&branch->remote_name, key, value))
 				return -1;
-			if (branch == current_branch) {
+			if (branch == current_branch && strcmp(branch->remote_name, ".")) {
 				default_remote_name = branch->remote_name;
 				explicit_default_remote_name = 1;
 			}
-- 
1.8.3.rc1.579.g184e698

[RFC/PATCH 2/3] pull: trivial cleanups

[Felipe Contreras]

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 git-pull.sh | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/git-pull.sh b/git-pull.sh
index 75297c7..b207df2 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -166,9 +166,7 @@ error_on_no_merge_candidates () {
 		op_prep=with
 	fi
 
-	curr_branch=${curr_branch#refs/heads/}
-	upstream=$(git config "branch.$curr_branch.merge")
-	remote=$(git config "branch.$curr_branch.remote")
+	upstream=$(git config "branch.$curr_branch_short.merge")
 
 	if [ $# -gt 1 ]; then
 		if [ "$rebase" = true ]; then
@@ -183,7 +181,7 @@ error_on_no_merge_candidates () {
 		echo "You asked to pull from the remote '$1', but did not specify"
 		echo "a branch. Because this is not the default configured remote"
 		echo "for your current branch, you must specify a branch on the command line."
-	elif [ -z "$curr_branch" -o -z "$upstream" ]; then
+	elif [ -z "$curr_branch_short" -o -z "$upstream" ]; then
 		. git-parse-remote
 		error_on_missing_default_upstream "pull" $op_type $op_prep \
 			"git pull <remote> <branch>"
-- 
1.8.3.rc1.579.g184e698

Re: [RFC/PATCH 2/3] pull: trivial cleanups

[Ramkumar Ramachandra]

Felipe Contreras wrote:
>  git-pull.sh | 6 ++----
>  1 file changed, 2 insertions(+), 4 deletions(-)

This one obviously looks good.  I'm not sure why you sent it along
with the other two patches though.

On a related note, I'm interested in fixing pull.  What I have on paper so far:

- pull.condition = clean-worktree | ff-update | no-local-changes |
always | never
- pull.action = merge | rebase* | reset
- pull.resetType = soft | hard | merge | keep
- pull.autostash = true | false

(ff-update is satisfied when FETCH_HEAD is directly ahead of
refs/remotes/<branch>, while no-local-changes is satisfied when
FETCH_HEAD is directly ahead of refs/heads/<branch>)

Any clue how to design branch-specific pull configuration?

Re: [RFC/PATCH 2/3] pull: trivial cleanups

[Felipe Contreras]

On Thu, May 16, 2013 at 3:29 AM, Ramkumar Ramachandra
<artagnon@gmail.com> wrote:
> Felipe Contreras wrote:
>>  git-pull.sh | 6 ++----
>>  1 file changed, 2 insertions(+), 4 deletions(-)
>
> This one obviously looks good.  I'm not sure why you sent it along
> with the other two patches though.

Because this patch depends on the previous one.

> On a related note, I'm interested in fixing pull.  What I have on paper so far:
>
> - pull.condition = clean-worktree | ff-update | no-local-changes |
> always | never
> - pull.action = merge | rebase* | reset
> - pull.resetType = soft | hard | merge | keep
> - pull.autostash = true | false

I don't understand that. But my only concern is that there's no way to
do something like:

% git fetch backup 'refs/tags/*:refs/tags/*' 'refs/heads/*:refs/heads/*'

-- 
Felipe Contreras

Re: [RFC/PATCH 2/3] pull: trivial cleanups

[Ramkumar Ramachandra]

Felipe Contreras wrote:
> But my only concern is that there's no way to
> do something like:
>
> % git fetch backup 'refs/tags/*:refs/tags/*' 'refs/heads/*:refs/heads/*'

[remote "backup"]
    fetch = refs/tags/*:refs/tags/*
    fetch = refs/heads/*:refs/heads/*

What am I missing?

Re: [RFC/PATCH 2/3] pull: trivial cleanups

[Felipe Contreras]

On Thu, May 16, 2013 at 4:34 AM, Ramkumar Ramachandra
<artagnon@gmail.com> wrote:
> Felipe Contreras wrote:
>> But my only concern is that there's no way to
>> do something like:
>>
>> % git fetch backup 'refs/tags/*:refs/tags/*' 'refs/heads/*:refs/heads/*'
>
> [remote "backup"]
>     fetch = refs/tags/*:refs/tags/*
>     fetch = refs/heads/*:refs/heads/*
>
> What am I missing?

Actually trying that command:

% git fetch origin 'refs/tags/*:refs/tags/*' 'refs/heads/*:refs/heads/*'
fatal: Refusing to fetch into current branch
refs/heads/fc/fast-export/cleanup of non-bare repository
fatal: The remote end hung up unexpectedly

-- 
Felipe Contreras

Re: [RFC/PATCH 2/3] pull: trivial cleanups

[Ramkumar Ramachandra]

Felipe Contreras wrote:
> % git fetch origin 'refs/tags/*:refs/tags/*' 'refs/heads/*:refs/heads/*'
> fatal: Refusing to fetch into current branch
> refs/heads/fc/fast-export/cleanup of non-bare repository
> fatal: The remote end hung up unexpectedly

That's because your HEAD is pointing to something under refs/heads/*:
it would work otherwise.  When I'm developing on my personal branch, I
sometimes do 'git fetch origin master:master +pu:pu +next:next', and
it works as expected.  When on master branch, I can't git fetch origin
master:master and this is a cute safety feature.

Either way, I think it's a bad practice to fetch directly into
refs/heads/*: you should really be fetching to refs/remotes and then
merging your changes in.  I do want shortcuts though, which is why I'm
interested in fixing pull: there is nothing to fix in fetch as far as
I'm concerned.

Re: [RFC/PATCH 2/3] pull: trivial cleanups

[Felipe Contreras]

On Thu, May 16, 2013 at 4:54 AM, Ramkumar Ramachandra
<artagnon@gmail.com> wrote:
> Felipe Contreras wrote:
>> % git fetch origin 'refs/tags/*:refs/tags/*' 'refs/heads/*:refs/heads/*'
>> fatal: Refusing to fetch into current branch
>> refs/heads/fc/fast-export/cleanup of non-bare repository
>> fatal: The remote end hung up unexpectedly
>
> That's because your HEAD is pointing to something under refs/heads/*:
> it would work otherwise.  When I'm developing on my personal branch, I
> sometimes do 'git fetch origin master:master +pu:pu +next:next', and
> it works as expected.  When on master branch, I can't git fetch origin
> master:master and this is a cute safety feature.

Now you know what's the problem.

> Either way, I think it's a bad practice to fetch directly into
> refs/heads/*: you should really be fetching to refs/remotes and then
> merging your changes in.  I do want shortcuts though, which is why I'm
> interested in fixing pull: there is nothing to fix in fetch as far as
> I'm concerned.

It doesn't matter if you think it's a bad practice or not, 'git push
--mirror' works, and it's possible to update a branch even if HEAD is
point to it. There should be a possibility to do the same with 'git
fetch'.

Right now the user is forced to do something like:

	git checkout -q -b tmp &&
	git fetch origin 'refs/tags/*:refs/tags/*' 'refs/heads/*:refs/heads/*' &&
	git checkout -q @{-1} &&
	git branch -q -D tmp 2> /dev/null

Which doesn't seem to be quite right.

-- 
Felipe Contreras

Re: [RFC/PATCH 2/3] pull: trivial cleanups

[Ramkumar Ramachandra]

Felipe Contreras wrote:
> It doesn't matter if you think it's a bad practice or not, 'git push
> --mirror' works, and it's possible to update a branch even if HEAD is
> point to it. There should be a possibility to do the same with 'git
> fetch'.

So, introduce a configuration variable to turn off this safety feature?

Re: [RFC/PATCH 2/3] pull: trivial cleanups

[Felipe Contreras]

On Thu, May 16, 2013 at 5:18 AM, Ramkumar Ramachandra
<artagnon@gmail.com> wrote:
> Felipe Contreras wrote:
>> It doesn't matter if you think it's a bad practice or not, 'git push
>> --mirror' works, and it's possible to update a branch even if HEAD is
>> point to it. There should be a possibility to do the same with 'git
>> fetch'.
>
> So, introduce a configuration variable to turn off this safety feature?

I thought you were interested in fixing 'git pull'. My bad.

-- 
Felipe Contreras

Re: [RFC/PATCH 2/3] pull: trivial cleanups

[Antoine Pelisse]

On Thu, May 16, 2013 at 11:36 AM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> Actually trying that command:
>
> % git fetch origin 'refs/tags/*:refs/tags/*' 'refs/heads/*:refs/heads/*'
> fatal: Refusing to fetch into current branch
> refs/heads/fc/fast-export/cleanup of non-bare repository
> fatal: The remote end hung up unexpectedly

Can you try something like this instead ?

    git fetch --update-head-ok # or -u

Re: [RFC/PATCH 2/3] pull: trivial cleanups

[Felipe Contreras]

On Thu, May 16, 2013 at 6:54 AM, Antoine Pelisse <apelisse@gmail.com> wrote:
> On Thu, May 16, 2013 at 11:36 AM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
>> Actually trying that command:
>>
>> % git fetch origin 'refs/tags/*:refs/tags/*' 'refs/heads/*:refs/heads/*'
>> fatal: Refusing to fetch into current branch
>> refs/heads/fc/fast-export/cleanup of non-bare repository
>> fatal: The remote end hung up unexpectedly
>
> Can you try something like this instead ?
>
>     git fetch --update-head-ok # or -u

Nice! That does the trick.

-- 
Felipe Contreras

[RFC/PATCH 3/3] push: add separate 'downstream' branch

[Felipe Contreras]

It doesn't make sense to push to the upstream branch, so create new
configurations for the notion of 'downstream' branch, which is basically
the branch to push to by default.

The upstream branch is remote+merge, the downstream branch is
pushremote+push.

  [branch "master"]
	  remote = origin
	  merge = refs/heads/master
	  pushremote = github
	  push = refs/heads/master

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 builtin/push.c | 65 ++++++++++++++++++++++++++++++++++++----------------------
 remote.c       |  8 ++++++--
 remote.h       |  3 +++
 3 files changed, 50 insertions(+), 26 deletions(-)

diff --git a/builtin/push.c b/builtin/push.c
index 909c34d..c062fa5 100644
--- a/builtin/push.c
+++ b/builtin/push.c
@@ -76,21 +76,23 @@ static int push_url_of_remote(struct remote *remote, const char ***url_p)
 	return remote->url_nr;
 }
 
-static NORETURN int die_push_simple(struct branch *branch, struct remote *remote) {
+static NORETURN int die_push_simple(struct branch *branch, struct remote *remote,
+		const char *kind, const char *related)
+{
 	/*
 	 * There's no point in using shorten_unambiguous_ref here,
 	 * as the ambiguity would be on the remote side, not what
 	 * we have locally. Plus, this is supposed to be the simple
 	 * mode. If the user is doing something crazy like setting
-	 * upstream to a non-branch, we should probably be showing
+	 * upstream/downstream to a non-branch, we should probably be showing
 	 * them the big ugly fully qualified ref.
 	 */
 	const char *advice_maybe = "";
-	const char *short_upstream =
-		skip_prefix(branch->merge[0]->src, "refs/heads/");
+	const char *short_upstream = skip_prefix(related, "refs/heads/");
 
 	if (!short_upstream)
-		short_upstream = branch->merge[0]->src;
+		short_upstream = related;
+
 	/*
 	 * Don't show advice for people who explicitely set
 	 * push.default.
@@ -99,8 +101,8 @@ static NORETURN int die_push_simple(struct branch *branch, struct remote *remote
 		advice_maybe = _("\n"
 				 "To choose either option permanently, "
 				 "see push.default in 'git help config'.");
-	die(_("The upstream branch of your current branch does not match\n"
-	      "the name of your current branch.  To push to the upstream branch\n"
+	die(_("The %s branch of your current branch does not match\n"
+	      "the name of your current branch.  To push to the %s branch\n"
 	      "on the remote, use\n"
 	      "\n"
 	      "    git push %s HEAD:%s\n"
@@ -109,6 +111,7 @@ static NORETURN int die_push_simple(struct branch *branch, struct remote *remote
 	      "\n"
 	      "    git push %s %s\n"
 	      "%s"),
+	    kind, kind,
 	    remote->name, short_upstream,
 	    remote->name, branch->name, advice_maybe);
 }
@@ -117,6 +120,8 @@ static void setup_push_upstream(struct remote *remote, int simple)
 {
 	struct strbuf refspec = STRBUF_INIT;
 	struct branch *branch = branch_get(NULL);
+	const char *related, *kind, *pushremote_name;
+
 	if (!branch)
 		die(_("You are not currently on a branch.\n"
 		    "To push the history leading to the current (detached HEAD)\n"
@@ -124,26 +129,38 @@ static void setup_push_upstream(struct remote *remote, int simple)
 		    "\n"
 		    "    git push %s HEAD:<name-of-remote-branch>\n"),
 		    remote->name);
-	if (!branch->merge_nr || !branch->merge || !branch->remote_name)
-		die(_("The current branch %s has no upstream branch.\n"
-		    "To push the current branch and set the remote as upstream, use\n"
-		    "\n"
-		    "    git push --set-upstream %s %s\n"),
-		    branch->name,
-		    remote->name,
-		    branch->name);
-	if (branch->merge_nr != 1)
-		die(_("The current branch %s has multiple upstream branches, "
-		    "refusing to push."), branch->name);
-	if (strcmp(branch->remote_name, remote->name))
-		die(_("You are pushing to remote '%s', which is not the upstream of\n"
+
+	if (branch->push) {
+		kind = _("downstream");
+		related = branch->push;
+		pushremote_name = branch->pushremote_name;
+	} else {
+		if (!branch->merge_nr || !branch->merge || !branch->remote_name)
+			die(_("The current branch %s has no upstream branch.\n"
+			    "To push the current branch and set the remote as upstream, use\n"
+			    "\n"
+			    "    git push --set-upstream %s %s\n"),
+			    branch->name,
+			    remote->name,
+			    branch->name);
+		if (branch->merge_nr != 1)
+			die(_("The current branch %s has multiple upstream branches, "
+			    "refusing to push."), branch->name);
+
+		kind = _("upstream");
+		related = branch->merge[0]->src;
+		pushremote_name = branch->remote_name;
+	}
+
+	if (strcmp(pushremote_name, remote->name))
+		die(_("You are pushing to remote '%s', which is not the %s of\n"
 		      "your current branch '%s', without telling me what to push\n"
 		      "to update which remote branch."),
-		    remote->name, branch->name);
-	if (simple && strcmp(branch->refname, branch->merge[0]->src))
-		die_push_simple(branch, remote);
+		    remote->name, kind, branch->name);
+	if (simple && strcmp(branch->refname, related))
+		die_push_simple(branch, remote, kind, related);
 
-	strbuf_addf(&refspec, "%s:%s", branch->name, branch->merge[0]->src);
+	strbuf_addf(&refspec, "%s:%s", branch->name, related);
 	add_refspec(refspec.buf);
 }
 
diff --git a/remote.c b/remote.c
index 322a1b6..f057b5f 100644
--- a/remote.c
+++ b/remote.c
@@ -365,13 +365,17 @@ static int handle_config(const char *key, const char *value, void *cb)
 				explicit_default_remote_name = 1;
 			}
 		} else if (!strcmp(subkey, ".pushremote")) {
+			if (git_config_string(&branch->pushremote_name, key, value))
+				return -1;
 			if (branch == current_branch)
-				if (git_config_string(&pushremote_name, key, value))
-					return -1;
+				pushremote_name = xstrdup(branch->pushremote_name);
 		} else if (!strcmp(subkey, ".merge")) {
 			if (!value)
 				return config_error_nonbool(key);
 			add_merge(branch, xstrdup(value));
+		} else if (!strcmp(subkey, ".push")) {
+			if (git_config_string(&branch->push, key, value))
+				return -1;
 		}
 		return 0;
 	}
diff --git a/remote.h b/remote.h
index cf56724..24433af 100644
--- a/remote.h
+++ b/remote.h
@@ -138,6 +138,9 @@ struct branch {
 	struct refspec **merge;
 	int merge_nr;
 	int merge_alloc;
+
+	const char *pushremote_name;
+	const char *push;
 };
 
 struct branch *branch_get(const char *name);
-- 
1.8.3.rc1.579.g184e698

Re: [RFC/PATCH 3/3] push: add separate 'downstream' branch

[Junio C Hamano]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> It doesn't make sense to push to the upstream branch, so create new
> configurations for the notion of 'downstream' branch, which is basically
> the branch to push to by default.

It doesn't?  That depends.

To people coming from (and people who are still using) central
shared repository workflow, pushing to anywhere other than the
upstream makes no sense.

If qualified with something like "When using a triangular workflow
to pull from one place and push to another place" in front, I can
see why having a separate upstream and downstream makes sense, and...

> The upstream branch is remote+merge, the downstream branch is
> pushremote+push.

... this is a perfect explanation of what a downsream is.

Re: [RFC/PATCH 3/3] push: add separate 'downstream' branch

[Felipe Contreras]

On Thu, May 16, 2013 at 12:36 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> It doesn't make sense to push to the upstream branch, so create new
>> configurations for the notion of 'downstream' branch, which is basically
>> the branch to push to by default.
>
> It doesn't?  That depends.
>
> To people coming from (and people who are still using) central
> shared repository workflow, pushing to anywhere other than the
> upstream makes no sense.

Semantics I guess; you can say they are pushing to the upstream, or
that they are pushing downstream, which happens to be the same as the
upstream.

My rationale was that at some point in the future we might want to
remove the code that pushes upstream, and only push downstream. And
either way configure downstream when creating new branches with
tracking. But I'm not sure that's a good idea.

> If qualified with something like "When using a triangular workflow
> to pull from one place and push to another place" in front, I can
> see why having a separate upstream and downstream makes sense, and...
>
>> The upstream branch is remote+merge, the downstream branch is
>> pushremote+push.
>
> ... this is a perfect explanation of what a downsream is.

Cool. I haven't decided how best to set the downstream yet, but for me
it's more important that 'git fetch' works sanely (patch #1), and I
don't like the proposed patch, but I can't think of anything better.

-- 
Felipe Contreras

Re: [RFC/PATCH 3/3] push: add separate 'downstream' branch

[Junio C Hamano]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> ...for me
> it's more important that 'git fetch' works sanely (patch #1), and I
> don't like the proposed patch, but I can't think of anything better.

I do not like that either, but I haven't formed a firm opinion on it
yet.

Re: [RFC/PATCH 3/3] push: add separate 'downstream' branch

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> It doesn't make sense to push to the upstream branch, so create new
>> configurations for the notion of 'downstream' branch, which is basically
>> the branch to push to by default.
>
> It doesn't?  That depends.
>
> To people coming from (and people who are still using) central
> shared repository workflow, pushing to anywhere other than the
> upstream makes no sense.
>
> If qualified with something like "When using a triangular workflow
> to pull from one place and push to another place" in front, I can
> see why having a separate upstream and downstream makes sense, and...
>
>> The upstream branch is remote+merge, the downstream branch is
>> pushremote+push.
>
> ... this is a perfect explanation of what a downsream is.

After thinking about it, I do not think downstream is a good word to
describe where you push to at all.

I'll have more on this topic but the above is the short of it for
now.

Re: [RFC/PATCH 3/3] push: add separate 'downstream' branch

[Ramkumar Ramachandra]

Felipe Contreras wrote:
>   [branch "master"]
>           remote = origin
>           merge = refs/heads/master
>           pushremote = github
>           push = refs/heads/master

Hm.  Some thoughts:

fetch and push aren't symmetric.  By default fetches are batched: when
you say 'git fetch', it fetches all the refs and uses the
remote.<name>.fetch refspec to update the refs on your side.  Now, I
would argue that this is the correct design, because I rarely want to
fetch just one ref (and that is broken, by the way: refs on my side
aren't updated for some weird reason).  The other reason this is
correct is because fetching has nothing to do with local branches: how
you _merge_ your remote branches to your local branches is entirely
orthogonal to the issue (and that is controlled by
branch.<name>.merge).

Now, push is a different ball game altogether.  There are people who
do batched pushes (push.default = matching has been the default for 8
years now).  However, the support for a batched push in a triangular
workflow is very limited: I can't say git push master hot-branch
pickaxe-doc, and expect them to go to the right remotes (this idea has
already been discussed and rejected).  Back to your patch: if you want
to support batched pushes to map refs correctly, you should write a
patch for remote.<name>.push.  It has a very valid usecase too: there
are people who use Gerrit and they shouldn't have to do git push
<name>:refs/for/<name> every single time.  Neither should they have to
configure each branch.<name>.push.  The ref-mapping is an inherent
property of the remote, not of the local branch.  And
branch.<name>.merge is entirely orthogonal to ref-mapping, as I
already explained.

That said, I think the concept of a downstream can be useful.  I have
branch.hot-branch.remote set to origin, and
branch.hot-branch.pushremote set to ram.  Now, I push some changes: my
prompt still says > (indicating unpushed changes), and this is very
annoying.  I would definitely like git to be able to recognize that
I'm ahead of upstream, but in-sync with my downstream.  So, your
branch.<name>.push should probably be named
branch.<name>.downstreamref and be used only for informational
purposes (@{d} and git status)?  Wait, why do we need it at all?  Is
there something that we cannot infer from a proposed
remote.<name>.push?  Why will we ever need to override that refspec
mapping with a local branch configuration?

Re: [RFC/PATCH 3/3] push: add separate 'downstream' branch

[Felipe Contreras]

On Thu, May 16, 2013 at 3:21 AM, Ramkumar Ramachandra
<artagnon@gmail.com> wrote:
> Felipe Contreras wrote:
>>   [branch "master"]
>>           remote = origin
>>           merge = refs/heads/master
>>           pushremote = github
>>           push = refs/heads/master
>
> Hm.  Some thoughts:
>
> fetch and push aren't symmetric.  By default fetches are batched: when
> you say 'git fetch', it fetches all the refs and uses the
> remote.<name>.fetch refspec to update the refs on your side.  Now, I
> would argue that this is the correct design, because I rarely want to
> fetch just one ref (and that is broken, by the way: refs on my side
> aren't updated for some weird reason).  The other reason this is
> correct is because fetching has nothing to do with local branches: how
> you _merge_ your remote branches to your local branches is entirely
> orthogonal to the issue (and that is controlled by
> branch.<name>.merge).
>
> Now, push is a different ball game altogether.  There are people who
> do batched pushes (push.default = matching has been the default for 8
> years now).

And is going to change soon.

> However, the support for a batched push in a triangular
> workflow is very limited: I can't say git push master hot-branch
> pickaxe-doc, and expect them to go to the right remotes (this idea has
> already been discussed and rejected).  Back to your patch: if you want
> to support batched pushes to map refs correctly, you should write a
> patch for remote.<name>.push.  It has a very valid usecase too: there
> are people who use Gerrit and they shouldn't have to do git push
> <name>:refs/for/<name> every single time.  Neither should they have to
> configure each branch.<name>.push.  The ref-mapping is an inherent
> property of the remote, not of the local branch.  And
> branch.<name>.merge is entirely orthogonal to ref-mapping, as I
> already explained.
>
> That said, I think the concept of a downstream can be useful.  I have
> branch.hot-branch.remote set to origin, and
> branch.hot-branch.pushremote set to ram.  Now, I push some changes: my
> prompt still says > (indicating unpushed changes), and this is very
> annoying.  I would definitely like git to be able to recognize that
> I'm ahead of upstream, but in-sync with my downstream.  So, your
> branch.<name>.push should probably be named
> branch.<name>.downstreamref and be used only for informational
> purposes (@{d} and git status)?

That makes absolutely no sense.

[branch "master"]
          remote = origin
          merge = refs/heads/master
          pushremote = github
          downstreamref = refs/heads/whaaa:refs/heads/master

What is the point of 'refs/heads/whaaa'?

> Wait, why do we need it at all?  Is
> there something that we cannot infer from a proposed
> remote.<name>.push?  Why will we ever need to override that refspec
> mapping with a local branch configuration?

[branch "master"]
          remote = origin
          merge = refs/heads/master
          pushremote = github
          push = refs/heads/fc/master

[branch "fc/old-remote/hg"]
          remote = .
          merge = refs/heads/master
          pushremote = github
          push = refs/heads/fc/remote/hg

Tell me how you express that without 'remote.branch.push'.

Cheers.

-- 
Felipe Contreras

Re: [RFC/PATCH 3/3] push: add separate 'downstream' branch

[Ramkumar Ramachandra]

Felipe Contreras wrote:
> And is going to change soon.

Your point being?  How will this patch interact with push.default = matching?

>> branch.<name>.push should probably be named
>> branch.<name>.downstreamref and be used only for informational
>> purposes (@{d} and git status)?
>
> That makes absolutely no sense.

I said downstreamref, not downstreamrefspec.

> [branch "master"]
>           remote = origin
>           merge = refs/heads/master
>           pushremote = github
>           push = refs/heads/fc/master
>
> [branch "fc/old-remote/hg"]
>           remote = .
>           merge = refs/heads/master
>           pushremote = github
>           push = refs/heads/fc/remote/hg
>
> Tell me how you express that without 'remote.branch.push'.

[remote "origin"]
    push = refs/heads/master:refs/heads/fc/master

[remote "."]
    push = refs/heads/fc/old-remote/hg:refs/heads/fc/remote/hg

Advantage being you can do:

[remote "origin"]
    push = refs/heads/*:refs/for/*

While you can't with branch.<name>.push.

Re: [RFC/PATCH 3/3] push: add separate 'downstream' branch

[Felipe Contreras]

On Thu, May 16, 2013 at 4:20 AM, Ramkumar Ramachandra
<artagnon@gmail.com> wrote:
> Felipe Contreras wrote:
>> And is going to change soon.
>
> Your point being?  How will this patch interact with push.default = matching?
>
>>> branch.<name>.push should probably be named
>>> branch.<name>.downstreamref and be used only for informational
>>> purposes (@{d} and git status)?
>>
>> That makes absolutely no sense.
>
> I said downstreamref, not downstreamrefspec.

That's not consistent with branch.A.merge, which is not named
branch.A.upstreamref.

>> [branch "master"]
>>           remote = origin
>>           merge = refs/heads/master
>>           pushremote = github
>>           push = refs/heads/fc/master
>>
>> [branch "fc/old-remote/hg"]
>>           remote = .
>>           merge = refs/heads/master
>>           pushremote = github
>>           push = refs/heads/fc/remote/hg
>>
>> Tell me how you express that without 'remote.branch.push'.
>
> [remote "origin"]
>     push = refs/heads/master:refs/heads/fc/master
>
> [remote "."]
>     push = refs/heads/fc/old-remote/hg:refs/heads/fc/remote/hg

Let's see:

% git checkout master
% git push

It will try to push to 'origin/fc/master' not 'github/fc/master',
which is what I intended.

% git checkout fc/old-remote/hg
% git push

It will try to push to 'fc/remote/hg' not 'github/fc/remote/hg', which
is what I intended.

> Advantage being you can do:
>
> [remote "origin"]
>     push = refs/heads/*:refs/for/*
>
> While you can't with branch.<name>.push.

But I can do 'git push origin "refs/head/*:refs/heads/for/*"', not
that I've ever had the need to do something like that, so I don't
care.

-- 
Felipe Contreras

Re: [RFC/PATCH 3/3] push: add separate 'downstream' branch

[Ramkumar Ramachandra]

Felipe Contreras wrote:
>> [remote "origin"]
>>     push = refs/heads/master:refs/heads/fc/master
>>
>> [remote "."]
>>     push = refs/heads/fc/old-remote/hg:refs/heads/fc/remote/hg

Major thinko.  It should be:

[remote "github"]
    push = refs/heads/master:refs/heads/fc/master
    push = refs/heads/fc/old-remote/hg:refs/heads/fc/remote/hg

>> Advantage being you can do:
>>
>> [remote "origin"]
>>     push = refs/heads/*:refs/for/*
>>
>> While you can't with branch.<name>.push.
>
> But I can do 'git push origin "refs/head/*:refs/heads/for/*"', not
> that I've ever had the need to do something like that, so I don't
> care.

Isn't the entire point of this exercise getting git to dwim without
being explicit?

I don't care about it personally either, which is why I haven't
written a patch yet.  However, there are users of Gerrit who would
appreciate this feature: in the remote.pushdefault thread, some people
requested this feature.

Re: [RFC/PATCH 3/3] push: add separate 'downstream' branch

[Felipe Contreras]

On Thu, May 16, 2013 at 5:06 AM, Ramkumar Ramachandra
<artagnon@gmail.com> wrote:
> Felipe Contreras wrote:
>>> [remote "origin"]
>>>     push = refs/heads/master:refs/heads/fc/master
>>>
>>> [remote "."]
>>>     push = refs/heads/fc/old-remote/hg:refs/heads/fc/remote/hg
>
> Major thinko.  It should be:
>
> [remote "github"]
>     push = refs/heads/master:refs/heads/fc/master
>     push = refs/heads/fc/old-remote/hg:refs/heads/fc/remote/hg

Would I be able to do:

% git branch --set-upstream-to origin/master --set-downstream-to
github/fc/master

?

Would I see these branches when I do 'git branch -vv'?
Would I be able to do 'git push next@{downstream}'?

>>> Advantage being you can do:
>>>
>>> [remote "origin"]
>>>     push = refs/heads/*:refs/for/*
>>>
>>> While you can't with branch.<name>.push.
>>
>> But I can do 'git push origin "refs/head/*:refs/heads/for/*"', not
>> that I've ever had the need to do something like that, so I don't
>> care.
>
> Isn't the entire point of this exercise getting git to dwim without
> being explicit?
>
> I don't care about it personally either, which is why I haven't
> written a patch yet.  However, there are users of Gerrit who would
> appreciate this feature: in the remote.pushdefault thread, some people
> requested this feature.

That is orthogonal to 'branch.A.push' the same way 'remote.B.fetch' is
orthogonal to 'branch.A.merge'.

-- 
Felipe Contreras

Re: [RFC/PATCH 3/3] push: add separate 'downstream' branch

[Ramkumar Ramachandra]

Felipe Contreras wrote:
> Would I be able to do:
>
> % git branch --set-upstream-to origin/master --set-downstream-to
> github/fc/master
>
> ?
>
> Would I see these branches when I do 'git branch -vv'?
> Would I be able to do 'git push next@{downstream}'?

Hm, losing this functionality in the name of generality would
certainly be very undesirable.

> That is orthogonal to 'branch.A.push' the same way 'remote.B.fetch' is
> orthogonal to 'branch.A.merge'.

Not at all (which is what I've been trying to say).
remote.<name>.fetch is operated on by fetch, while branch.<name>.merge
is operated on by merge; they are really orthogonal.  What happens if
both branch.<name>.push and remote.<name>.push are set?  What will
push do?

Perhaps we should get both, and get branch.<name>.push to override
remote.<name>.push.  The issue being @{d} will not work if
remote.<name>.push is set.  Then again, since we're targeting Gerrit
users here, I don't really think it's an issue: refs/for/master is not
really a "downstream branch"; it's a pseudo-ref that Gerrit handles
internally.

Re: [RFC/PATCH 3/3] push: add separate 'downstream' branch

[Felipe Contreras]

On Thu, May 16, 2013 at 6:31 AM, Ramkumar Ramachandra
<artagnon@gmail.com> wrote:
> Felipe Contreras wrote:
>> Would I be able to do:
>>
>> % git branch --set-upstream-to origin/master --set-downstream-to
>> github/fc/master
>>
>> ?
>>
>> Would I see these branches when I do 'git branch -vv'?
>> Would I be able to do 'git push next@{downstream}'?
>
> Hm, losing this functionality in the name of generality would
> certainly be very undesirable.

I don't even know what that means.

>> That is orthogonal to 'branch.A.push' the same way 'remote.B.fetch' is
>> orthogonal to 'branch.A.merge'.
>
> Not at all (which is what I've been trying to say).
> remote.<name>.fetch is operated on by fetch, while branch.<name>.merge
> is operated on by merge; they are really orthogonal.  What happens if
> both branch.<name>.push and remote.<name>.push are set?  What will
> push do?

The same that 'git pull' does when both branch.<name>.merge and
remote.<name>.fetch are set.

> Perhaps we should get both, and get branch.<name>.push to override
> remote.<name>.push.

Does branch.<name>.merge overrides remote.<name>.fetch? No. They
complement each other.

> The issue being @{d} will not work if
> remote.<name>.push is set.

Of course it would work. Does @{u} stop working when remote.<name>.fetch is set?

> Then again, since we're targeting Gerrit
> users here, I don't really think it's an issue: refs/for/master is not
> really a "downstream branch"; it's a pseudo-ref that Gerrit handles
> internally.

It is a downstream branch.

-- 
Felipe Contreras

Re: [RFC/PATCH 3/3] push: add separate 'downstream' branch

[Ramkumar Ramachandra]

Felipe Contreras wrote:
> Does branch.<name>.merge overrides remote.<name>.fetch? No. They
> complement each other.

I often wonder if you are reading what you're responding to:

remote.<name>.fetch is operated on by fetch, while branch.<name>.merge
is operated on by merge; they are really orthogonal.

> The same that 'git pull' does when both branch.<name>.merge and
> remote.<name>.fetch are set.

Are you reading this?

git pull _fetches_ from remote.<name>.fetch and _merges_ from
branch.<name>.merge.  What is "the same" in git push terms?  It's a
simple question; which ref does push update: the one specified by
remote.<name>.push or branch.<name>.push?

> Of course it would work. Does @{u} stop working when remote.<name>.fetch is set?

It doesn't work when _only_ remote.<name>.fetch is set: you need
branch.<name>.merge to determine @{u}, just like you would need
branch.<name>.push to determine @{d}.

> It is a downstream branch.

Which commit does git show @{d} show you?  There is no ref called
refs/for/master.

Re: [RFC/PATCH 3/3] push: add separate 'downstream' branch

[Felipe Contreras]

On Thu, May 16, 2013 at 8:52 AM, Ramkumar Ramachandra
<artagnon@gmail.com> wrote:
> Felipe Contreras wrote:
>> Does branch.<name>.merge overrides remote.<name>.fetch? No. They
>> complement each other.
>
> I often wonder if you are reading what you're responding to:

And I wonder if you care if what you say is actually true.

> remote.<name>.fetch is operated on by fetch, while branch.<name>.merge
> is operated on by merge; they are really orthogonal.

You keep saying they are orthogonal, but they are not. Read
remote.c::branch_get().

And try this:

[remote "origin"]
	url = git@github.com:felipec/git.git
	# fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
	remote = origin
	merge = refs/heads/master

Can you merge? No. Can you do master@{u}? No. Several other things don't work.

>> The same that 'git pull' does when both branch.<name>.merge and
>> remote.<name>.fetch are set.
>
> Are you reading this?
>
> git pull _fetches_ from remote.<name>.fetch and _merges_ from
> branch.<name>.merge.  What is "the same" in git push terms?  It's a
> simple question; which ref does push update: the one specified by
> remote.<name>.push or branch.<name>.push?

[remote]
	pushdefault = origin
[remote "origin"]
	push = refs/head/*:refs/heads/for/*
[branch "master"]
	pushremote = github
	push = refs/heads/new-master
[branch "next"]
	pushremote = origin
	push = refs/heads/new-next

% git checkout master && git push

Where should it go? github/new-master. Obviously.

% git checkout next && git push

Where should it go? origin/new-next. Obviously.

% git checkout main && git push

Where should it go? origin/for/maint. Obviously.

I don't see what the big deal is.

>> Of course it would work. Does @{u} stop working when remote.<name>.fetch is set?
>
> It doesn't work when _only_ remote.<name>.fetch is set: you need
> branch.<name>.merge to determine @{u}, just like you would need
> branch.<name>.push to determine @{d}.

So? The answer is no.

>> It is a downstream branch.
>
> Which commit does git show @{d} show you?  There is no ref called
> refs/for/master.

The same commit 'git show @{-10000}' shows you. The fact it doesn't
resolve to a commit doesn't mean @{-100} is not the nth-hundredth
previous checkout.

-- 
Felipe Contreras