[RFC/PATCH 0/2] Support for arbitrary mapping for "git pull --rebase"

Hi *,

  Here you have my patch serie to add support for arbitrary mapping for
"git pull --rebase".

  This is a RFC specially for the new "git remote" subcommand, tracking.
Suggest other things if you think of a better way.

  Santi

Santi Béjar (2):
  remote tracking: return the tracking branch for the given branches
  get_remote_merge_branch: Support for arbitrary mapping

 Documentation/git-remote.txt |    7 +++++++
 builtin-remote.c             |   35 +++++++++++++++++++++++++++++++++++
 git-parse-remote.sh          |   21 ++++++++++++---------
 3 files changed, 54 insertions(+), 9 deletions(-)

Signed-off-by: Santi Béjar <redacted>
---
 Documentation/git-remote.txt |    7 +++++++
 builtin-remote.c             |   35 +++++++++++++++++++++++++++++++++++
 2 files changed, 42 insertions(+), 0 deletions(-)

diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt
index 9e2b4ea..e444899 100644
--- a/Documentation/git-remote.txt
+++ b/Documentation/git-remote.txt

@@ -17,6 +17,7 @@ SYNOPSIS
 'git remote show' [-n] <name>
 'git remote prune' [-n | --dry-run] <name>
 'git remote update' [-p | --prune] [group | remote]...
+'git remote tracking' <name> <branch>...
 
 DESCRIPTION
 -----------

@@ -128,6 +129,12 @@ be updated.  (See linkgit:git-config[1]).
 +
 With `--prune` option, prune all the remotes that are updated.
 
+'tracking'::
+
+Returns the tracking branch for the given remote (<name>) and branch
+(<branch>). Note that <branch> must exactly match the left hand side of
+the refspec of the given remote.
+
 
 DISCUSSION
 ----------

diff --git a/builtin-remote.c b/builtin-remote.c
index 709f8a6..bb8e73b 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c

@@ -16,6 +16,7 @@ static const char * const builtin_remote_usage[] = {
 	"git remote show [-n] <name>",
 	"git remote prune [-n | --dry-run] <name>",
 	"git remote [-v | --verbose] update [-p | --prune] [group]",
+	"git remote tracking <name> <branch>...",
 	NULL
 };
 

@@ -665,6 +666,38 @@ static int remove_branches(struct string_list *branches)
 	return result;
 }
 
+static int tracking(int argc, const char **argv)
+{
+	struct option options[] = {
+		OPT_END()
+	};
+	struct remote *remote;
+	static const char **refs = NULL;
+	int ref_nr = 0;
+	int i = 0;
+	struct refspec *refspec;
+
+	if (argc < 3)
+		usage_with_options(builtin_remote_usage, options);
+	remote = remote_get(argv[1]);
+	if (!remote)
+		die("No such remote: %s", argv[1]);
+	refs = xcalloc(argc + 1, sizeof(const char *));
+	for (i = 2; i < argc; i++) {
+		refs[ref_nr++] = argv[i];
+	}
+	refs[ref_nr] = NULL;
+	memset(&refspec, 0, sizeof(*refspec));
+	refspec = parse_fetch_refspec(ref_nr, refs);
+	for (i = 0; i < ref_nr ; i++) {
+		if (!remote_find_tracking(remote, &refspec[i]))
+			printf("%s\n", refspec[i].dst);
+		else
+			return 1;
+	}
+	return 0;
+}
+
 static int rm(int argc, const char **argv)
 {
 	struct option options[] = {

@@ -1348,6 +1381,8 @@ int cmd_remote(int argc, const char **argv, const char *prefix)
 		result = show_all();
 	else if (!strcmp(argv[0], "add"))
 		result = add(argc, argv);
+	else if (!strcmp(argv[0], "tracking"))
+		result = tracking(argc, argv);
 	else if (!strcmp(argv[0], "rename"))
 		result = mv(argc, argv);
 	else if (!strcmp(argv[0], "rm"))

-- 
1.6.3.2.406.gd6a466

This function is used in "git pull --rebase" to know the tracking branch.

Signed-off-by: Santi Béjar <redacted>
---
 git-parse-remote.sh |   21 ++++++++++++---------
 1 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index 5f47b18..1aa6ffe 100755
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh

@@ -74,8 +74,6 @@ get_remote_merge_branch () {
 	    repo=$1
 	    shift
 	    ref=$1
-	    # FIXME: It should return the tracking branch
-	    #        Currently only works with the default mapping
 	    case "$ref" in
 	    +*)
 		ref=$(expr "z$ref" : 'z+\(.*\)')

@@ -83,13 +81,18 @@ get_remote_merge_branch () {
 	    esac
 	    expr "z$ref" : 'z.*:' >/dev/null || ref="${ref}:"
 	    remote=$(expr "z$ref" : 'z\([^:]*\):')
-	    case "$remote" in
-	    '' | HEAD ) remote=HEAD ;;
-	    heads/*) remote=${remote#heads/} ;;
-	    refs/heads/*) remote=${remote#refs/heads/} ;;
-	    refs/* | tags/* | remotes/* ) remote=
-	    esac
+	    while true ; do
+		case "$remote" in
+		'' | HEAD ) remote=;;
+		heads/*) remote=refs/$remote;;
+		refs/heads/*) ;;
+		refs/* | tags/* | remotes/* ) remote=;;
+		*) remote=heads/$remote
+		esac
 
-	    [ -n "$remote" ] && echo "refs/remotes/$repo/$remote"
+		[ -n "$remote" ] &&
+		git remote tracking $repo $remote && break
+		case "$remote" in refs/heads/* | "" ) break ; esac
+	    done
 	esac
 }

-- 
1.6.3.2.406.gd6a466

2009/6/16 Junio C Hamano [off-list ref]

Jeff King [off-list ref] writes:

quoted

On Tue, Jun 16, 2009 at 01:08:02PM +0200, Santi Béjar wrote:

quoted

  I've noticed that having branch.<branch>.merge set with the branch
name, and not with the full ref, cause problems with
--format='%(upstream)'  and also with the "branch -av" and "git
status" upstream branch outputs. But git-fetch and git-pull works ok,
so it is a valid setting.

Actually, it is broken in a lot of places. for-each-ref relies on the
same code as "git status", "git checkout", etc, which will all fail to
display tracking info. I believe the same code is also used for updating
tracking branches on push. So I'm not sure if it was ever intended to be
a valid setting.

It wasn't.  Some places may accept them gracefully by either being extra
nice or by accident.

And what about the comments in my reply. And in the branch.<name>.merge
docs says: The value is handled like the remote part of a refspec.

In fact I found it trying to implement a patch to get the local tracking
for a given remote and branch. But it only works if you spell the branch with
its full form:

$ git remote tracking origin master # does not work
$ git remote tracking origin refs/heads/master # does work
refs/remotes/origin/master

so I thought it would be better to resolve the %(upstream) first.

So if you know how to resolve this and or the %(upstream) issue, please tell me.

Anyway, here you have the WIP patch to get the tracking branch, I'm not sure
about the UI (or the script interface?), it is also a RFC.

---8<----
Subject: [RFC/PATCH]: Output tracking branch from remote and branch
---

Hi,

  as said above it is a RFC, specially for the UI, and also can anyone help
me with the:

$ git remote tracking origin master # does not work

case?

Thanks,
Santi

P.D: This case will be used in the "git pull --rebase remote branch" case.

 builtin-remote.c |   34 ++++++++++++++++++++++++++++++++++
 1 files changed, 34 insertions(+), 0 deletions(-)

diff --git a/builtin-remote.c b/builtin-remote.c
index 709f8a6..03bcc27 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c

@@ -665,6 +665,38 @@ static int remove_branches(struct string_list *branches)
 	return result;
 }
 
+static int tracking(int argc, const char **argv)
+{
+	struct option options[] = {
+		OPT_END()
+	};
+	struct remote *remote;
+	static const char **refs = NULL;
+	int ref_nr = 0;
+	int i = 0;
+	struct refspec *refspec;
+
+	if (argc < 3)
+		usage_with_options(builtin_remote_usage, options);
+	remote = remote_get(argv[1]);
+	if (!remote)
+		die("No such remote: %s", argv[1]);
+	refs = xcalloc(argc + 1, sizeof(const char *));
+	for (i = 2; i < argc; i++) {
+		refs[ref_nr++] = argv[i];
+	}
+	refs[ref_nr] = NULL;
+	memset(&refspec, 0, sizeof(*refspec));
+	refspec = parse_fetch_refspec(ref_nr, refs);
+	for (i = 0; i < ref_nr ; i++) {
+		if (!remote_find_tracking(remote, &refspec[i]))
+			printf("%s\n", refspec[i].dst);
+		else
+			return 1;
+	}
+	return 0;
+}
+
 static int rm(int argc, const char **argv)
 {
 	struct option options[] = {

@@ -1348,6 +1380,8 @@ int cmd_remote(int argc, const char **argv, const char *prefix)
 		result = show_all();
 	else if (!strcmp(argv[0], "add"))
 		result = add(argc, argv);
+	else if (!strcmp(argv[0], "tracking"))
+		result = tracking(argc, argv);
 	else if (!strcmp(argv[0], "rename"))
 		result = mv(argc, argv);
 	else if (!strcmp(argv[0], "rm"))

-- 
1.6.3.2.406.gd6a466

Hi,

On Thu, 18 Jun 2009, Santi Béjar wrote:

Santi B??jar (2):

Seems something is wrong in the --cover-letter utf-8 handlin, no?

Ciao,
Dscho

2009/6/18 Johannes Schindelin [off-list ref]:

Hi,

On Thu, 18 Jun 2009, Santi Béjar wrote:

quoted

Santi B??jar (2):

Seems something is wrong in the --cover-letter utf-8 handlin, no?

In this case (the cover letter) it is send-email that handles the
utf-8, but I don't know why it is not working, as there is a test in
t9001-send-email that tests it. I think it worked, I'll try to bisect
if I found a working version.

Santi

2009/6/18 Santi Béjar [off-list ref]

[...]

[...]

+           while true ; do
+               case "$remote" in
+               '' | HEAD ) remote=;;

I forgot to say that I changed the HEAD behavior because the remote
HEAD and the local remote HEAD (origin/HEAD) can point to different
branches, as the local remote HEAD represents your preference for
which is the default remote branch.

Santi

Having a testcase would be nice (just a reminder for the final submission).

Paolo

Hi,

On Thu, 18 Jun 2009, Santi Béjar wrote:

From that description, it is not clear to me if the branch is the _remote_ 

branch, the branch _on_ the remote, or the local branch.

If it is the remote branch (or the branch on the remote), I wonder how you 
deal with ambiguities, as I can easily create hundreds of branches 
tracking the same remote branch.

If it is the local branch I wonder why I have to pass the name of the 
remote.

Ciao,
Dscho

2009/6/18 Johannes Schindelin [off-list ref]:

Hi,

On Thu, 18 Jun 2009, Santi Béjar wrote:

quoted

diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt
index 9e2b4ea..e444899 100644
--- a/Documentation/git-remote.txt
+++ b/Documentation/git-remote.txt

@@ -17,6 +17,7 @@ SYNOPSIS
 'git remote show' [-n] <name>
 'git remote prune' [-n | --dry-run] <name>
 'git remote update' [-p | --prune] [group | remote]...
+'git remote tracking' <name> <branch>...

 DESCRIPTION
 -----------

@@ -128,6 +129,12 @@ be updated.  (See linkgit:git-config[1]).
 +
 With `--prune` option, prune all the remotes that are updated.

+'tracking'::
+
+Returns the tracking branch for the given remote (<name>) and branch
+(<branch>). Note that <branch> must exactly match the left hand side of
+the refspec of the given remote.
+

From that description, it is not clear to me if the branch is the _remote_
branch, the branch _on_ the remote, or the local branch.

OK. s/and branch/and remote branch/

If it is the remote branch (or the branch on the remote), I wonder how you
deal with ambiguities, as I can easily create hundreds of branches
tracking the same remote branch.

AFAICS from remote_find_tracking (and some tests), it picks the first match.

So, additional text could be: In case of multiple matches, it picks
the first one.

Santi

2009/6/18 Paolo Bonzini [off-list ref]:

Having a testcase would be nice (just a reminder for the final submission).

Sure.

Santi

Santi Béjar [off-list ref] writes:

2009/6/18 Johannes Schindelin [off-list ref]:

quoted

On Thu, 18 Jun 2009, Santi Béjar wrote:

quoted

diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt
index 9e2b4ea..e444899 100644
--- a/Documentation/git-remote.txt
+++ b/Documentation/git-remote.txt

@@ -17,6 +17,7 @@ SYNOPSIS
 'git remote show' [-n] <name>
 'git remote prune' [-n | --dry-run] <name>
 'git remote update' [-p | --prune] [group | remote]...
+'git remote tracking' <name> <branch>...

 DESCRIPTION
 -----------

@@ -128,6 +129,12 @@ be updated.  (See linkgit:git-config[1]).
 +
 With `--prune` option, prune all the remotes that are updated.

+'tracking'::
+
+Returns the tracking branch for the given remote (<name>) and branch
+(<branch>). Note that <branch> must exactly match the left hand side of
+the refspec of the given remote.
+

From that description, it is not clear to me if the branch is the _remote_
branch, the branch _on_ the remote, or the local branch.

OK. s/and branch/and remote branch/

quoted

If it is the remote branch (or the branch on the remote), I wonder how you
deal with ambiguities, as I can easily create hundreds of branches
tracking the same remote branch.

AFAICS from remote_find_tracking (and some tests), it picks the first match.

So, additional text could be: In case of multiple matches, it picks
the first one.

Why not have both:

  git remote tracking <remote> <remote branch>

would show all local branches that track <remote branch>, and have
<remote> as default remote, while

  git remote tracking <local branch>

would show <remote> and <remote branch> if <local branch> is following
remote-tracking branch.

-- 
Jakub Narebski
Poland
ShadeHawk on #git

2009/6/18 Jakub Narebski [off-list ref]:

Santi Béjar [off-list ref] writes:

quoted

2009/6/18 Johannes Schindelin [off-list ref]:

quoted

On Thu, 18 Jun 2009, Santi Béjar wrote:

quoted

diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt
index 9e2b4ea..e444899 100644
--- a/Documentation/git-remote.txt
+++ b/Documentation/git-remote.txt

@@ -17,6 +17,7 @@ SYNOPSIS
 'git remote show' [-n] <name>
 'git remote prune' [-n | --dry-run] <name>
 'git remote update' [-p | --prune] [group | remote]...
+'git remote tracking' <name> <branch>...

 DESCRIPTION
 -----------

@@ -128,6 +129,12 @@ be updated.  (See linkgit:git-config[1]).
 +
 With `--prune` option, prune all the remotes that are updated.

+'tracking'::
+
+Returns the tracking branch for the given remote (<name>) and branch
+(<branch>). Note that <branch> must exactly match the left hand side of
+the refspec of the given remote.
+

From that description, it is not clear to me if the branch is the _remote_
branch, the branch _on_ the remote, or the local branch.

OK. s/and branch/and remote branch/

quoted

If it is the remote branch (or the branch on the remote), I wonder how you
deal with ambiguities, as I can easily create hundreds of branches
tracking the same remote branch.

AFAICS from remote_find_tracking (and some tests), it picks the first match.

So, additional text could be: In case of multiple matches, it picks
the first one.

Why not have both:

It makes sense.

 git remote tracking <remote> <remote branch>

would show all local branches that track <remote branch>, and have
<remote> as default remote,

Maybe my description is unclear, but it's not about local branches
which track <branch> on <remote>, it is about the local branch
representation of the remote branch, i.e. not 'master' but
origin/master (git remote tracking origin master in a default clone).

while

 git remote tracking <local branch>

would show <remote> and <remote branch> if <local branch> is following
remote-tracking branch.

Good idea.

Santi

--
Jakub Narebski
Poland
ShadeHawk on #git

On Thu, 18 June 2009, Santi Béjar wrote:

2009/6/18 Jakub Narebski [off-list ref]:

[cut]

quoted

 $ git remote tracking <remote> <remote branch>

would show all local branches that track <remote branch>, and have
<remote> as default remote,

Maybe my description is unclear, but it's not about local branches
which track <branch> on <remote>, it is about the local branch
representation of the remote branch, i.e. not 'master' but
origin/master (git remote tracking origin master in a default clone).

Ah, the problem with the same (or similar) name for two different 
things.  If we have local branch 'local' set to track branch 'master'
on remote 'origin', we have:

   /------- local repository ------\            /- origin -\
  /                                 \          /            \
  |                                 |          |            |
  'local'  -------->  'origin/master' -----------> 'master' 
  refs/heads/local    refs/remotes/origin/master   refs/heads/master                

  branch.local.remote = origin
  branch.local.merge  = refs/heads/master

  remote.origin.fetch = +refs/heads/*:refs/remotes/origin/*

'origin/master' is called remote-TRACKING branch (for 'master' branch
on remote 'origin').  Setting up automerge information for local branch
'local' which _follows_ branch 'master' on remote 'origin' is done 
using --TRACK option to git-branch.

Therefore the confusion.


Do I understand correctly that you want for

  $ git remote tracking origin master

to return

  origin/master

(and perhaps also origin/HEAD?).
-- 
Jakub Narebski
Poland

2009/6/18 Jakub Narebski [off-list ref]:

On Thu, 18 June 2009, Santi Béjar wrote:

quoted

2009/6/18 Jakub Narebski [off-list ref]:

[cut]

quoted

quoted

 $ git remote tracking <remote> <remote branch>

would show all local branches that track <remote branch>, and have
<remote> as default remote,

Maybe my description is unclear, but it's not about local branches
which track <branch> on <remote>, it is about the local branch
representation of the remote branch, i.e. not 'master' but
origin/master (git remote tracking origin master in a default clone).

Ah, the problem with the same (or similar) name for two different
things.  If we have local branch 'local' set to track branch 'master'
on remote 'origin', we have:

  /------- local repository ------\            /- origin -\
 /                                 \          /            \
 |                                 |          |            |
 'local'  -------->  'origin/master' -----------> 'master'
 refs/heads/local    refs/remotes/origin/master   refs/heads/master

 branch.local.remote = origin
 branch.local.merge  = refs/heads/master

 remote.origin.fetch = +refs/heads/*:refs/remotes/origin/*

'origin/master' is called remote-TRACKING branch (for 'master' branch
on remote 'origin').  Setting up automerge information for local branch
'local' which _follows_ branch 'master' on remote 'origin' is done
using --TRACK option to git-branch.

Therefore the confusion.

OK, but I wonder if the documentation for the new command is clear
enough or can be improved.

Do I understand correctly that you want for

 $ git remote tracking origin master

to return

 origin/master

In this particular case (the above settings) not exactly, as master
does not match exactly the lhs of the refspec. It would be:

$ git remote tracking origin refs/heads/master
refs/remotes/origin/master

(and perhaps also origin/HEAD?).

HEAD is another beast, as the local HEAD symlink is a local config,
that defaults to the remote default branch, but that you can change
with "git remote set-head".

Ops, you are saying to return origin/HEAD for "git remote tracking
origin master", no? I don't think it makes sense, I think of "git
remote tracking" more as a mapping function, it applies the map (the
refspec) to the given argument.

Santi

One thing it just occurred to me is to return the explicit refspec
instead of the tracking branch. So with the default config (after a
clone):

$ git remote tracking origin refs/heads/master
refs/heads/master:refs/remotes/origin/master

this makes a difference in case we want to allow returning all the
matching tracking branch and not the first one with more than one
branch, as:

$ git config remote.origin.fetch --add +refs/heads/*:refs/remote/another/*

$ git remote tracking origin refs/heads/master
refs/heads/master:refs/remotes/origin/master
refs/heads/next:refs/remotes/origin/next

$ git remote tracking origin refs/heads/master refs/heads/next
refs/heads/master:refs/remotes/origin/master
refs/heads/master:refs/remotes/another/master
refs/heads/next:refs/remotes/origin/next
refs/heads/next:refs/remotes/another/next

Thoughts?

2009/6/18 Santi Béjar [off-list ref]:

2009/6/18 Johannes Schindelin [off-list ref]:

quoted

Hi,

On Thu, 18 Jun 2009, Santi Béjar wrote:

quoted

Santi B??jar (2):

Seems something is wrong in the --cover-letter utf-8 handlin, no?

In this case (the cover letter) it is send-email that handles the
utf-8, but I don't know why it is not working, as there is a test in
t9001-send-email that tests it. I think it worked, I'll try to bisect
if I found a working version.

In fact I've been checking some of my cover letter and almost none of
them have the MIME headers. One that have the MIME headers is:

Subject: [PATCHv4 0/4] Show author and/or committer in some cases
Date: Sun,  4 May 2008 18:04:48 +0200
Message-Id: [off-list ref]
X-Mailer: git-send-email 1.5.5.1.224.gadb29
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

But I don't know/remeber what I did differently and I cannot reproduce
it even using the same git-send-email version.

So I don't know what else to look, and in fact I don't know who is
responsible (if any) for these MIME headers in a cover-letter. But
they are added automatically if you use the --compose flag. So maybe
git-send-email could be enhanced so that it adds the MIME headers to
the cover-letter (0000-cover-letter.patch) as if run with --compose.

Santi