* branch.<branch>.merge and --format='%(upstream)' @ 2009-06-16 11:08 Santi Béjar 2009-06-16 12:23 ` Jeff King 0 siblings, 1 reply; 6+ messages in thread From: Santi Béjar @ 2009-06-16 11:08 UTC (permalink / raw) To: Git Mailing List Hi, 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. $ git clone git.git $ cd git $ git config branch.master.merge refs/heads/master $ git for-each-ref --format='%(upstream)' refs/heads/master refs/remotes/origin/master $ git config branch.master.merge master $ git config branch.master.merge master $ git for-each-ref --format='%(upstream)' refs/heads/master $ Best regards, Santi ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: branch.<branch>.merge and --format='%(upstream)' 2009-06-16 11:08 branch.<branch>.merge and --format='%(upstream)' Santi Béjar @ 2009-06-16 12:23 ` Jeff King 2009-06-16 14:07 ` Santi Béjar 2009-06-16 15:46 ` Junio C Hamano 0 siblings, 2 replies; 6+ messages in thread From: Jeff King @ 2009-06-16 12:23 UTC (permalink / raw) To: Santi Béjar; +Cc: Git Mailing List 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. Fixing it would involve tweaks to remote_find_tracking, I think, but I haven't looked into it too closely. I'm not sure of the impliciations of allowing non-qualified refs in that config. Will we detect and warn about ambiguities? Does it actually work with non-branches? -Peff ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: branch.<branch>.merge and --format='%(upstream)' 2009-06-16 12:23 ` Jeff King @ 2009-06-16 14:07 ` Santi Béjar 2009-06-16 15:46 ` Junio C Hamano 1 sibling, 0 replies; 6+ messages in thread From: Santi Béjar @ 2009-06-16 14:07 UTC (permalink / raw) To: Jeff King; +Cc: Git Mailing List 2009/6/16 Jeff King <peff@peff.net>: > 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. > > Fixing it would involve tweaks to remote_find_tracking, I think, but I > haven't looked into it too closely. It should be interpreted as "git pull branchname" does, or at least as close as possible. Another non-working example is with: remote.origin.fetch=+master:refs/remotes/origin/master branch.master.merge=refs/heads/master so it looks like that both have to match for remote_find_tracking to work (and in this case "git fetch" also works ok). I suppose that remote_find_tracking should DWIM: build the full ref prepending refs/ and heads/, as necessary. > > I'm not sure of the impliciations of allowing non-qualified refs in that > config. They are currently allowed (fetch/pull) since a long time, and it is not only this config, but also remote.<remote>.fetch (see above). In b888d61 (Make fetch a builtin, 2007-09-10): commit b888d61c8308027433df9c243fa551f42db1c76a Author: Daniel Barkalow <barkalow@iabervon.org> Date: Tue Sep 11 05:03:25 2007 [...] This changes a few small bits of behavior: branch.<name>.merge is parsed as if it were the lhs of a fetch refspec, and does not have to exactly match the actual lhs of a refspec, so long as it is a valid abbreviation for the same ref. [...] > Will we detect and warn about ambiguities? Does it actually work > with non-branches? With tags yes, but full qualified. Santi ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: branch.<branch>.merge and --format='%(upstream)' 2009-06-16 12:23 ` Jeff King 2009-06-16 14:07 ` Santi Béjar @ 2009-06-16 15:46 ` Junio C Hamano 2009-06-16 22:34 ` Santi Béjar 1 sibling, 1 reply; 6+ messages in thread From: Junio C Hamano @ 2009-06-16 15:46 UTC (permalink / raw) To: Jeff King; +Cc: Santi Béjar, Git Mailing List 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: branch.<branch>.merge and --format='%(upstream)' 2009-06-16 15:46 ` Junio C Hamano @ 2009-06-16 22:34 ` Santi Béjar 0 siblings, 0 replies; 6+ messages in thread From: Santi Béjar @ 2009-06-16 22:34 UTC (permalink / raw) To: git; +Cc: Junio C Hamano, Jeff King 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 ^ permalink raw reply related [flat|nested] 6+ messages in thread
* [RFC/PATCH 0/2] Support for arbitrary mapping for "git pull --rebase" @ 2009-06-18 7:57 Santi Béjar 2009-06-18 7:57 ` branch.<branch>.merge and --format='%(upstream)' Santi Béjar 0 siblings, 1 reply; 6+ messages in thread From: Santi Béjar @ 2009-06-18 7:57 UTC (permalink / raw) To: git 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(-) ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: branch.<branch>.merge and --format='%(upstream)' 2009-06-18 7:57 [RFC/PATCH 0/2] Support for arbitrary mapping for "git pull --rebase" Santi Béjar @ 2009-06-18 7:57 ` Santi Béjar 0 siblings, 0 replies; 6+ messages in thread From: Santi Béjar @ 2009-06-18 7:57 UTC (permalink / raw) To: git; +Cc: Junio C Hamano, Jeff King 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 ^ permalink raw reply related [flat|nested] 6+ messages in thread
end of thread, other threads:[~2009-06-18 7:57 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2009-06-16 11:08 branch.<branch>.merge and --format='%(upstream)' Santi Béjar 2009-06-16 12:23 ` Jeff King 2009-06-16 14:07 ` Santi Béjar 2009-06-16 15:46 ` Junio C Hamano 2009-06-16 22:34 ` Santi Béjar -- strict thread matches above, loose matches on Subject: below -- 2009-06-18 7:57 [RFC/PATCH 0/2] Support for arbitrary mapping for "git pull --rebase" Santi Béjar 2009-06-18 7:57 ` branch.<branch>.merge and --format='%(upstream)' Santi Béjar
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).