threads / rfc / 19849

RFC patch, 2 partsremote tracking: return the tracking branch for the given branches

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

## tl;dr

19 messages between Jun 18, 2009 and Jun 19, 2009. Diffs are folded; open one to read it.

replies: 18people: 5as markdown or json

Santi Béjar· Jun 18, 2009, 07:57 UTC · lore

[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(-)
Santi Béjar· Jun 18, 2009, 07:57 UTC · re: Santi Béjar · lore
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(-)
Show changes to 2 files +42 −0

Documentation/git-remote.txt, builtin-remote.c

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
Santi Béjar· Jun 18, 2009, 13:23 UTC · re: Paolo Bonzini · lore

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

2009/6/18 Paolo Bonzini <bonzini@gnu.org>:
> Having a testcase would be nice (just a reminder for the final submission).
Sure.
Santi
Johannes Schindelin· Jun 18, 2009, 12:35 UTC · re: Santi Béjar · lore

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

Hi,
On Thu, 18 Jun 2009, Santi Béjar wrote:
Show 22 quoted lines
> 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

Santi Béjar· Jun 18, 2009, 13:22 UTC · re: Johannes Schindelin · lore

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

2009/6/18 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
Show 29 quoted lines
> 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
Jakub Narebski· Jun 18, 2009, 13:44 UTC · re: Santi Béjar · lore

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

Santi Béjar <santi@agolina.net> writes:
Show 39 quoted lines
> 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
Santi Béjar· Jun 18, 2009, 13:55 UTC · re: Jakub Narebski · lore

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

2009/6/18 Jakub Narebski <jnareb@gmail.com>:
Show 42 quoted lines
> 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.
Show 5 quoted lines
>
>  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).

Show 6 quoted lines
> while
>
>  git remote tracking <local branch>
>
> would show <remote> and <remote branch> if <local branch> is following
> remote-tracking branch.
Good idea.
Santi
Show 5 quoted lines
> --
> Jakub Narebski
> Poland
> ShadeHawk on #git
>
Jakub Narebski· Jun 18, 2009, 14:17 UTC · re: Santi Béjar · lore

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

On Thu, 18 June 2009, Santi Béjar wrote:
> 2009/6/18 Jakub Narebski <jnareb@gmail.com>:
[cut]
Show 10 quoted lines
> >
> >  $ 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
Santi Béjar· Jun 18, 2009, 14:40 UTC · re: Jakub Narebski · lore

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

2009/6/18 Jakub Narebski <jnareb@gmail.com>:
Show 36 quoted lines
> 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.

Show 9 quoted lines
>
>
> 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
Santi Béjar· Jun 18, 2009, 19:01 UTC · re: Santi Béjar · lore

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

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?
Junio C Hamano· Jun 18, 2009, 19:19 UTC · re: Santi Béjar · lore

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

Santi Béjar <santi@agolina.net> writes:
Show 6 quoted lines
> 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.

Show 9 quoted lines
> 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?
Show 5 quoted lines
> $ 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
Santi Béjar· Jun 18, 2009, 21:31 UTC · re: Junio C Hamano · lore

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

2009/6/18 Junio C Hamano <gitster@pobox.com>:
Show 11 quoted lines
> 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.

Show 21 quoted lines
> 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
Santi Béjar· Jun 18, 2009, 07:57 UTC · re: Santi Béjar · lore

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

2009/6/16 Junio C Hamano <gitster@pobox.com>
Show 19 quoted lines
>
> 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(-)
Show changes to builtin-remote.c +34 −0
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
Santi Béjar· Jun 18, 2009, 07:57 UTC · re: Santi Béjar · lore

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

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(-)
Show changes to git-parse-remote.sh +12 −9
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
Santi Béjar· Jun 18, 2009, 09:27 UTC · re: Santi Béjar · lore

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

2009/6/18 Santi Béjar <santi@agolina.net>
Show 12 quoted lines
>
> 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
[...]
Show 6 quoted lines
> @@ -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
Santi Béjar· Jun 18, 2009, 09:24 UTC · re: Johannes Schindelin · lore

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

2009/6/18 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
Show 7 quoted lines
> 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
Santi Béjar· Jun 19, 2009, 13:42 UTC · re: Santi Béjar · lore

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

2009/6/18 Santi Béjar <santi@agolina.net>:
Show 13 quoted lines
> 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

← back to recent threads