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

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

[Santi Béjar]

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(-)

[RFC/PATCH 1/2] remote tracking: return the tracking branch for the given branches

[Santi Béjar]

Signed-off-by: Santi Béjar <santi@agolina.net>
---
 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

Re: [RFC/PATCH 1/2] remote tracking: return the tracking branch for the given branches

[Paolo Bonzini]

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

Paolo

Re: [RFC/PATCH 1/2] remote tracking: return the tracking branch for the given branches

[Santi Béjar]

2009/6/18 Paolo Bonzini <bonzini@gnu.org>:
> Having a testcase would be nice (just a reminder for the final submission).

Sure.

Santi

Re: [RFC/PATCH 1/2] remote tracking: return the tracking branch for the given branches

[Johannes Schindelin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1224 bytes --]

Hi,

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

> 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.

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

Re: [RFC/PATCH 1/2] remote tracking: return the tracking branch for the given branches

[Santi Béjar]

2009/6/18 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> Hi,
>
> On Thu, 18 Jun 2009, Santi Béjar wrote:
>
>> 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

Re: [RFC/PATCH 1/2] remote tracking: return the tracking branch for the given branches

[Jakub Narebski]

Santi Béjar <santi@agolina.net> writes:
> 2009/6/18 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>> On Thu, 18 Jun 2009, Santi Béjar wrote:
>>
>>> 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.

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

Re: [RFC/PATCH 1/2] remote tracking: return the tracking branch for the given branches

[Santi Béjar]

2009/6/18 Jakub Narebski <jnareb@gmail.com>:
> Santi Béjar <santi@agolina.net> writes:
>> 2009/6/18 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>>> On Thu, 18 Jun 2009, Santi Béjar wrote:
>>>
>>>> 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.
>
> 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
>

Re: [RFC/PATCH 1/2] remote tracking: return the tracking branch for the given branches

[Jakub Narebski]

On Thu, 18 June 2009, Santi Béjar wrote:
> 2009/6/18 Jakub Narebski <jnareb@gmail.com>:

[cut]
> >
> >  $ 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

Re: [RFC/PATCH 1/2] remote tracking: return the tracking branch for the given branches

[Santi Béjar]

2009/6/18 Jakub Narebski <jnareb@gmail.com>:
> On Thu, 18 June 2009, Santi Béjar wrote:
>> 2009/6/18 Jakub Narebski <jnareb@gmail.com>:
>
> [cut]
>> >
>> >  $ 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

Re: [RFC/PATCH 1/2] remote tracking: return the tracking branch for the given branches

[Santi Béjar]

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?

Re: [RFC/PATCH 1/2] remote tracking: return the tracking branch for the given branches

[Junio C Hamano]

Santi Béjar <santi@agolina.net> writes:

> 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

I think the output is sensible, instead of saying something like
'origin/master'.

We can and should allow the end users to use abbreviated form as input to
us (either command line or configuration value) when it is unambiguous,
but when returning values for use by Porcelains, we should be strict and
precise to avoid ambiguities.

> 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

I am not sure what this example is doing.  You asked about refs/heads/master
but you also talk about refs/heads/next?   I guess you meant to say

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

instead, judging from the next example?

> $ 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

Re: [RFC/PATCH 1/2] remote tracking: return the tracking branch for the given branches

[Santi Béjar]

2009/6/18 Junio C Hamano <gitster@pobox.com>:
> Santi Béjar <santi@agolina.net> writes:
>
>> 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
>
> I think the output is sensible, instead of saying something like
> 'origin/master'.

OK.

>
> We can and should allow the end users to use abbreviated form as input to
> us (either command line or configuration value) when it is unambiguous,

OK. Moreover I think it also applies to the %(upstream) case I
reported some days ago.

> but when returning values for use by Porcelains, we should be strict and
> precise to avoid ambiguities.
>
>> 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
>
> I am not sure what this example is doing.  You asked about refs/heads/master
> but you also talk about refs/heads/next?   I guess you meant to say
>
>    $ git remote tracking origin refs/heads/master
>    refs/heads/master:refs/remotes/origin/master
>    refs/heads/master:refs/remotes/another/master
>
> instead, judging from the next example?

Yes.

Santi

Re: branch.<branch>.merge and --format='%(upstream)'

[Santi Béjar]

2009/6/16 Junio C Hamano <gitster@pobox.com>
>
> Jeff King <peff@peff.net> writes:
>
> > On Tue, Jun 16, 2009 at 01:08:02PM +0200, Santi Béjar wrote:
> >
> >>   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

[RFC/PATCH 2/2] get_remote_merge_branch: Support for arbitrary mapping

[Santi Béjar]

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

Signed-off-by: Santi Béjar <santi@agolina.net>
---
 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

Re: [RFC/PATCH 2/2] get_remote_merge_branch: Support for arbitrary mapping

[Santi Béjar]

2009/6/18 Santi Béjar <santi@agolina.net>
>
> This function is used in "git pull --rebase" to know the tracking branch.
>
> Signed-off-by: Santi Béjar <santi@agolina.net>
> ---
>  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

[...]

> @@ -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 ;;
[...]
> +           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

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

[Johannes Schindelin]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 146 bytes --]

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

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

[Santi Béjar]

2009/6/18 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> 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?

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

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

[Santi Béjar]

2009/6/18 Santi Béjar <santi@agolina.net>:
> 2009/6/18 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>> 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?
>
> 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: <1209917092-12146-1-git-send-email-sbejar@gmail.com>
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