From: Jeff King <hidden> Date: 2016-06-15 23:04:37
This is a re-roll of the series at:
http://thread.gmane.org/gmane.comp.version-control.git/266532
There were some minor fixes in response to review, but the main change
here is support for "git for-each-ref --format=%(push)". To do that, I
pulled the push logic into remote.[ch], where it can be used from both
sha1_name.c and for-each-ref.c. This is a better place for it to reside,
anyway, and may help in the future unifying it with the other remote
code that is used by `git push`.
In an effort to reuse as much of the @{upstream} code as possible, I did
similar refactoring for that side; we now have branch_get_upstream().
Even though the logic for getting @{upstream} isn't nearly as
complicated as for @{push}, I think several call-sites are improved by
using the new helper.
[01/12]: remote.c: drop default_remote_name variable
[02/12]: remote.c: drop "remote" pointer from "struct branch"
[03/12]: remote.c: hoist branch.*.remote lookup out of remote_get_1
[04/12]: remote.c: provide per-branch pushremote name
[05/12]: remote.c: introduce branch_get_upstream helper
[06/12]: remote.c: report specific errors from branch_get_upstream
[07/12]: remote.c: add branch_get_push
[08/12]: sha1_name: refactor upstream_mark
[09/12]: sha1_name: refactor interpret_upstream_mark
[10/12]: sha1_name: implement @{push} shorthand
[11/12]: for-each-ref: use skip_prefix instead of starts_with
[12/12]: for-each-ref: accept "%(push)" format
-Peff
From: Jeff King <hidden> Date: 2016-06-15 23:04:37
When we read the remote config from disk, we update a
default_remote_name variable if we see branch.*.remote
config for the current branch. This isn't wrong, or even all
that complicated, but it is a bit simpler (because it
reduces our overall state) to just lazily compute the
default when we need it.
The ulterior motive here is that the push config uses a
similar structure, and _is_ much more complicated as a
result. That will be simplified in a future patch, and it's
more readable if the logic for remotes and push-remotes
matches.
Note that we also used default_remote_name as a signal that
the remote config has been loaded; after this patch, we now
use an explicit flag.
Signed-off-by: Jeff King <redacted>
---
Same as v1.
remote.c | 23 +++++++++++------------
1 file changed, 11 insertions(+), 12 deletions(-)
From: Jeff King <hidden> Date: 2016-06-15 23:04:37
When we create each branch struct, we fill in the
"remote_name" field from the config, and then fill in the
actual "remote" field (with a "struct remote") based on that
name. However, it turns out that nobody really cares about
the latter field. The only two sites that access it at all
are:
1. git-merge, which uses it to notice when the branch does
not have a remote defined. But we can easily replace this
with looking at remote_name instead.
2. remote.c itself, when setting up the @{upstream} merge
config. But we don't need to save the "remote" in the
"struct branch" for that; we can just look it up for
the duration of the operation.
So there is no need to have both fields; they are redundant
with each other (the struct remote contains the name, or you
can look up the struct from the name). It would be nice to
simplify this, especially as we are going to add matching
pushremote config in a future patch (and it would be nice to
keep them consistent).
So which one do we keep and which one do we get rid of?
If we had a lot of callers accessing the struct, it would be
more efficient to keep it (since you have to do a lookup to
go from the name to the struct, but not vice versa). But we
don't have a lot of callers; we have exactly one, so
efficiency doesn't matter. We can decide this based on
simplicity and readability.
And the meaning of the struct value is somewhat unclear. Is
it always the remote matching remote_name? If remote_name is
NULL (i.e., no per-branch config), does the struct fall back
to the "origin" remote, or is it also NULL? These questions
will get even more tricky with pushremotes, whose fallback
behavior is more complicated. So let's just store the name,
which pretty clearly represents the branch.*.remote config.
Any lookup or fallback behavior can then be implemented in
helper functions.
Signed-off-by: Jeff King <redacted>
---
Versus v1, I tried to explain the rationale a bit better in the commit
message. The code is the same.
builtin/merge.c | 2 +-
remote.c | 14 ++++++++------
remote.h | 1 -
3 files changed, 9 insertions(+), 8 deletions(-)
@@ -955,7 +955,7 @@ static int setup_with_upstream(const char ***argv)if(!branch)die(_("No current branch."));-if(!branch->remote)+if(!branch->remote_name)die(_("No remote for the current branch."));if(!branch->merge_nr)die(_("No default upstream defined for the current branch."));
From: Jeff King <hidden> Date: 2016-06-15 23:04:37
We'll want to use this logic as a fallback when looking up
the pushremote, so let's pull it out into its own function.
We don't technically need to make this available outside of
remote.c, but doing so will provide a consistent API with
pushremote_for_branch, which we will add later.
Signed-off-by: Jeff King <redacted>
---
Same as v1.
remote.c | 21 ++++++++++++++-------
remote.h | 1 +
2 files changed, 15 insertions(+), 7 deletions(-)
From: Jeff King <hidden> Date: 2016-06-15 23:04:37
When remote.c loads its config, it records the
branch.*.pushremote for the current branch along with the
global remote.pushDefault value, and then binds them into a
single value: the default push for the current branch. We
then pass this value (which may be NULL) to remote_get_1
when looking up a remote for push.
This has a few downsides:
1. It's confusing. The early-binding of the "current
value" led to bugs like the one fixed by 98b406f
(remote: handle pushremote config in any order,
2014-02-24). And the fact that pushremotes fall back to
ordinary remotes is not explicit at all; it happens
because remote_get_1 cannot tell the difference between
"we are not asking for the push remote" and "there is
no push remote configured".
2. It throws away intermediate data. After read_config()
finishes, we have no idea what the value of
remote.pushDefault was, because the string has been
overwritten by the current branch's
branch.*.pushremote.
3. It doesn't record other data. We don't note the
branch.*.pushremote value for anything but the current
branch.
Let's make this more like the fetch-remote config. We'll
record the pushremote for each branch, and then explicitly
compute the correct remote for the current branch at the
time of reading.
Signed-off-by: Jeff King <redacted>
---
Versus v1, I did something a little clever by passing a function pointer
around (versus a flag and letting the caller do a conditional based on
the flag). Too clever?
remote.c | 40 ++++++++++++++++++++++------------------
remote.h | 2 ++
2 files changed, 24 insertions(+), 18 deletions(-)
From: Jeff King <hidden> Date: 2016-06-15 23:04:37
All of the information needed to find the @{upstream} of a
branch is included in the branch struct, but callers have to
navigate a series of possible-NULL values to get there.
Let's wrap that logic up in an easy-to-read helper.
Signed-off-by: Jeff King <redacted>
---
New in v2.
builtin/branch.c | 8 +++-----
builtin/for-each-ref.c | 5 ++---
builtin/log.c | 7 ++-----
remote.c | 12 +++++++++---
remote.h | 7 +++++++
5 files changed, 23 insertions(+), 16 deletions(-)
@@ -1695,6 +1695,13 @@ int branch_merge_matches(struct branch *branch,returnrefname_match(branch->merge[i]->src,refname);}+constchar*branch_get_upstream(structbranch*branch)+{+if(!branch||!branch->merge||!branch->merge[0])+returnNULL;+returnbranch->merge[0]->dst;+}+staticintignore_symref_update(constchar*refname){unsignedcharsha1[20];
@@ -1904,12 +1911,11 @@ int stat_tracking_info(struct branch *branch, int *num_ours, int *num_theirs)intrev_argc;/* Cannot stat unless we are marked to build on top of somebody else. */-if(!branch||-!branch->merge||!branch->merge[0]||!branch->merge[0]->dst)+base=branch_get_upstream(branch);+if(!base)return0;/* Cannot stat if what we used to build on no longer exists */-base=branch->merge[0]->dst;if(read_ref(base,sha1))return-1;theirs=lookup_commit_reference(sha1);
From: Jeff King <hidden> Date: 2016-06-15 23:04:37
When the previous commit introduced the branch_get_upstream
helper, there was one call-site that could not be converted:
the one in sha1_name.c, which gives detailed error messages
for each possible failure.
Let's teach the helper to optionally report these specific
errors. This lets us convert another callsite, and means we
can use the helper in other locations that want to give the
same error messages.
The logic and error messages come straight from sha1_name.c,
with the exception that we start each error with a lowercase
letter, as is our usual style (note that a few tests need
updated as a result).
Signed-off-by: Jeff King <redacted>
---
So this uses the recently discussed "pass the error back in a strbuf"
technique. We don't need an integer flag here because nobody cares about
the reason; only whether to die and report it (so a "_gently" form would
also work).
This adds an extra NULL parameter to every call-site of
branch_get_upstream (in the _gently paradigm, we'd pass an extra "0"
flag). I waffled on just leaving that as-is, and implementing it as a
wrapper to a new branch_get_upstream_err.
Overall, I think it makes the flow work pretty well, and the allocation
issues are non-existent because the callers all either want to die with
the error or ignore it. As an aside, while thinking about this I
recalled that one of the complaints against using a statically-sized
buffer for error messages is that we didn't want to truncate them. But
note that calling die() will end up in vreportf, which will itself
truncate.
builtin/branch.c | 2 +-
builtin/for-each-ref.c | 2 +-
builtin/log.c | 2 +-
remote.c | 33 +++++++++++++++++++++++++++++----
remote.h | 6 +++++-
sha1_name.c | 25 +++++++------------------
t/t1507-rev-parse-upstream.sh | 8 ++++----
7 files changed, 48 insertions(+), 30 deletions(-)
@@ -1695,10 +1695,35 @@ int branch_merge_matches(struct branch *branch,returnrefname_match(branch->merge[i]->src,refname);}-constchar*branch_get_upstream(structbranch*branch)+__attribute((format(printf,2,3)))+staticconstchar*error_buf(structstrbuf*err,constchar*fmt,...){-if(!branch||!branch->merge||!branch->merge[0])-returnNULL;+if(err){+va_listap;+va_start(ap,fmt);+strbuf_vaddf(err,fmt,ap);+va_end(ap);+}+returnNULL;+}++constchar*branch_get_upstream(structbranch*branch,structstrbuf*err)+{+if(!branch)+returnerror_buf(err,_("HEAD does not point to a branch"));+if(!branch->merge||!branch->merge[0]||!branch->merge[0]->dst){+if(!ref_exists(branch->refname))+returnerror_buf(err,_("no such branch: '%s'"),+branch->name);+if(!branch->merge)+returnerror_buf(err,+_("no upstream configured for branch '%s'"),+branch->name);+returnerror_buf(err,+_("upstream branch '%s' not stored as a remote-tracking branch"),+branch->merge[0]->src);+}+returnbranch->merge[0]->dst;}
@@ -1911,7 +1936,7 @@ int stat_tracking_info(struct branch *branch, int *num_ours, int *num_theirs)intrev_argc;/* Cannot stat unless we are marked to build on top of somebody else. */-base=branch_get_upstream(branch);+base=branch_get_upstream(branch,NULL);if(!base)return0;
@@ -222,8 +222,12 @@ int branch_merge_matches(struct branch *, int n, const char *);*Returnthefully-qualifiedrefnameofthetrackingbranchfor`branch`.*I.e.,what"branch@{upstream}"wouldgiveyou.ReturnsNULLifno*upstreamisdefined.+*+*If`err`isnotNULLandnoupstreamisdefined,amorespecificerror+*messageisrecordedthere(ifthefunctiondoesnotreturnNULL,then+*`err`isnottouched).*/-constchar*branch_get_upstream(structbranch*branch);+constchar*branch_get_upstream(structbranch*branch,structstrbuf*err);/* Flags to match_refs. */enummatch_refs_flags{
@@ -1059,27 +1059,16 @@ static const char *get_upstream_branch(const char *branch_buf, int len){char*branch=xstrndup(branch_buf,len);structbranch*upstream=branch_get(*branch?branch:NULL);+structstrbuferr=STRBUF_INIT;+constchar*ret;-/*-*UpstreamcanbeNULLonlyifbranchreferstoHEADandHEAD-*pointstosomethingdifferentthanabranch.-*/-if(!upstream)-die(_("HEAD does not point to a branch"));-if(!upstream->merge||!upstream->merge[0]->dst){-if(!ref_exists(upstream->refname))-die(_("No such branch: '%s'"),branch);-if(!upstream->merge){-die(_("No upstream configured for branch '%s'"),-upstream->name);-}-die(-_("Upstream branch '%s' not stored as a remote-tracking branch"),-upstream->merge[0]->src);-}free(branch);-returnupstream->merge[0]->dst;+ret=branch_get_upstream(upstream,&err);+if(!ret)+die("%s",err.buf);++returnret;}staticintinterpret_upstream_mark(constchar*name,intnamelen,
@@ -150,7 +150,7 @@ test_expect_success 'branch@{u} works when tracking a local branch' ' test_expect_success'branch@{u} error message when no upstream''cat>expect<<-EOF&&-fatal:Noupstreamconfiguredforbranch${sq}non-tracking${sq}+fatal:noupstreamconfiguredforbranch${sq}non-tracking${sq}EOFerror_messagenon-tracking@{u}2>actual&&test_i18ncmpexpectactual
@@ -158,7 +158,7 @@ test_expect_success 'branch@{u} error message when no upstream' ' test_expect_success'@{u} error message when no upstream''cat>expect<<-EOF&&-fatal:Noupstreamconfiguredforbranch${sq}master${sq}+fatal:noupstreamconfiguredforbranch${sq}master${sq}EOFtest_must_failgitrev-parse--verify@{u}2>actual&&test_i18ncmpexpectactual
@@ -166,7 +166,7 @@ test_expect_success '@{u} error message when no upstream' ' test_expect_success'branch@{u} error message with misspelt branch''cat>expect<<-EOF&&-fatal:Nosuchbranch:${sq}no-such-branch${sq}+fatal:nosuchbranch:${sq}no-such-branch${sq}EOFerror_messageno-such-branch@{u}2>actual&&test_i18ncmpexpectactual
@@ -183,7 +183,7 @@ test_expect_success '@{u} error message when not on a branch' ' test_expect_success'branch@{u} error message if upstream branch not fetched''cat>expect<<-EOF&&-fatal:Upstreambranch${sq}refs/heads/side${sq}notstoredasaremote-trackingbranch+fatal:upstreambranch${sq}refs/heads/side${sq}notstoredasaremote-trackingbranchEOFerror_messagebad-upstream@{u}2>actual&&test_i18ncmpexpectactual
From: Jeff King <hidden> Date: 2016-06-15 23:04:37
In a triangular workflow, the place you pull from and the
place you push to may be different. As we have
branch_get_upstream for the former, this patch adds
branch_get_push for the latter (and as the former implements
@{upstream}, so will this implement @{push} in a future
patch).
Note that the memory-handling for the return value bears
some explanation. Some code paths require allocating a new
string, and some let us return an existing string. We should
provide a consistent interface to the caller, so it knows
whether to free the result or not.
We could do so by xstrdup-ing any existing strings, and
having the caller always free. But that makes us
inconsistent with branch_get_upstream, so we would prefer to
simply take ownership of the resulting string. We do so by
storing it inside the "struct branch", just as we do with
the upstream refname (in that case we compute it when the
branch is created, but there's no reason not to just fill
it in lazily in this case).
Signed-off-by: Jeff King <redacted>
---
This patch is new in v2, but the logic is basically ripped from
sha1_name.c in v1.
remote.c | 85 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
remote.h | 10 ++++++++
2 files changed, 95 insertions(+)
@@ -1727,6 +1727,91 @@ const char *branch_get_upstream(struct branch *branch, struct strbuf *err)returnbranch->merge[0]->dst;}+staticconstchar*tracking_for_push_dest(structremote*remote,+constchar*refname,+structstrbuf*err)+{+char*ret;++ret=apply_refspecs(remote->fetch,remote->fetch_refspec_nr,refname);+if(!ret)+returnerror_buf(err,+_("push destination '%s' on remote '%s' has no local tracking branch"),+refname,remote->name);+returnret;+}++staticconstchar*branch_get_push_1(structbranch*branch,structstrbuf*err)+{+structremote*remote;++if(!branch)+returnerror_buf(err,_("HEAD does not point to a branch"));++remote=remote_get(pushremote_for_branch(branch,NULL));+if(!remote)+returnerror_buf(err,+_("branch '%s' has no remote for pushing"),+branch->name);++if(remote->push_refspec_nr){+char*dst;+constchar*ret;++dst=apply_refspecs(remote->push,remote->push_refspec_nr,+branch->refname);+if(!dst)+returnerror_buf(err,+_("push refspecs for '%s' do not include '%s'"),+remote->name,branch->name);++ret=tracking_for_push_dest(remote,dst,err);+free(dst);+returnret;+}++if(remote->mirror)+returntracking_for_push_dest(remote,branch->refname,err);++switch(push_default){+casePUSH_DEFAULT_NOTHING:+returnerror_buf(err,_("push has no destination (push.default is 'nothing')"));++casePUSH_DEFAULT_MATCHING:+casePUSH_DEFAULT_CURRENT:+returntracking_for_push_dest(remote,branch->refname,err);++casePUSH_DEFAULT_UPSTREAM:+returnbranch_get_upstream(branch,err);++casePUSH_DEFAULT_UNSPECIFIED:+casePUSH_DEFAULT_SIMPLE:+{+constchar*up,*cur;++up=branch_get_upstream(branch,err);+if(!up)+returnNULL;+cur=tracking_for_push_dest(remote,branch->refname,err);+if(!cur)+returnNULL;+if(strcmp(cur,up))+returnerror_buf(err,+_("cannot resolve 'simple' push to a single destination"));+returncur;+}+}++die("BUG: unhandled push situation");+}++constchar*branch_get_push(structbranch*branch,structstrbuf*err)+{+if(!branch->push_tracking_ref)+branch->push_tracking_ref=branch_get_push_1(branch,err);+returnbranch->push_tracking_ref;+}+staticintignore_symref_update(constchar*refname){unsignedcharsha1[20];
@@ -229,6 +231,14 @@ int branch_merge_matches(struct branch *, int n, const char *);*/constchar*branch_get_upstream(structbranch*branch,structstrbuf*err);+/**+*Returnthetrackingbranchthatcorrespondstotherefwewouldpushto+*givenabare`gitpush`while`branch`ischeckedout.+*+*Thereturnvalueand`err`conventionsmatchthoseof`branch_get_upstream`.+*/+constchar*branch_get_push(structbranch*branch,structstrbuf*err);+/* Flags to match_refs. */enummatch_refs_flags{MATCH_REFS_NONE=0,
From: Jeff King <hidden> Date: 2016-06-15 23:04:37
We will be adding new mark types in the future, so separate
the suffix data from the logic.
Signed-off-by: Jeff King <redacted>
---
Same as v1.
sha1_name.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
From: Jeff King <hidden> Date: 2016-06-15 23:04:37
Now that most of the logic for our local get_upstream_branch
has been pushed into the generic branch_get_upstream, we can
fold the remainder into interpret_upstream_mark.
Furthermore, what remains is generic to any branch-related
"@{foo}" we might add in the future, and there's enough
boilerplate that we'd like to reuse it. Let's parameterize
the two operations (parsing the mark and computing its
value) so that we can reuse this for "@{push}" in the near
future.
Signed-off-by: Jeff King <redacted>
---
More function pointer cleverness. Here it seems more justified to me,
because we may eventually grow the list of interpret_branch_mark()
users (e.g., for the concept discussed previously as @{publish}).
sha1_name.c | 44 +++++++++++++++++++++++---------------------
1 file changed, 23 insertions(+), 21 deletions(-)
From: Jeff King <hidden> Date: 2016-06-15 23:04:37
In a triangular workflow, each branch may have two distinct
points of interest: the @{upstream} that you normally pull
from, and the destination that you normally push to. There
isn't a shorthand for the latter, but it's useful to have.
For instance, you may want to know which commits you haven't
pushed yet:
git log @{push}..
Or as a more complicated example, imagine that you normally
pull changes from origin/master (which you set as your
@{upstream}), and push changes to your own personal fork
(e.g., as myfork/topic). You may push to your fork from
multiple machines, requiring you to integrate the changes
from the push destination, rather than upstream. With this
patch, you can just do:
git rebase @{push}
rather than typing out the full name.
The heavy lifting is all done by branch_get_push; here we
just wire it up to the "@{push}" syntax.
Signed-off-by: Jeff King <redacted>
---
Most of this is from v1, but the heavy lifting was already extracted.
Documentation/revisions.txt | 25 ++++++++++++++++++
sha1_name.c | 14 +++++++++-
t/t1514-rev-parse-push.sh | 63 +++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 101 insertions(+), 1 deletion(-)
create mode 100755 t/t1514-rev-parse-push.sh
@@ -98,6 +98,31 @@ some output processing may assume ref names in UTF-8. `branch.<name>.merge`). A missing branchname defaults to the current one.+'<branchname>@\{push\}', e.g. 'master@\{push\}', '@\{push\}'::+ The suffix '@\{push}' reports the branch "where we would push to" if+ `git push` were run while `branchname` was checked out (or the current+ 'HEAD' if no branchname is specified). Since our push destination is+ in a remote repository, of course, we report the local tracking branch+ that corresponds to that branch (i.e., something in 'refs/remotes/').+++Here's an example to make it more clear:+++------------------------------+$ git config push.default current+$ git config remote.pushdefault myfork+$ git checkout -b mybranch origin/master++$ git rev-parse --symbolic-full-name @{upstream}+refs/remotes/origin/master++$ git rev-parse --symbolic-full-name @{push}+refs/remotes/myfork/mybranch+------------------------------+++Note in the example that we set up a triangular workflow, where we pull+from one location and push to another. In a non-triangular workflow,+'@\{push}' is the same as '@\{upstream}', and there is no need for it.+ '<rev>{caret}', e.g. 'HEAD{caret}, v1.5.1{caret}0':: A suffix '{caret}' to a revision parameter means the first parent of that commit object. '{caret}<n>' means the <n>th parent (i.e.
@@ -0,0 +1,63 @@+#!/bin/sh++test_description='test <branch>@{push} syntax'+../test-lib.sh++resolve(){+echo"$2">expect&&+gitrev-parse--symbolic-full-name"$1">actual&&+test_cmpexpectactual+}++test_expect_success'setup''+gitinit--bareparent.git&&+gitinit--bareother.git&&+gitremoteaddoriginparent.git&&+gitremoteaddotherother.git&&+test_commitbase&&+gitpushoriginHEAD&&+gitbranch--set-upstream-to=origin/mastermaster&&+gitbranch--tracktopicorigin/master&&+gitpushorigintopic&&+gitpushothertopic+'++test_expect_success'@{push} with default=nothing''+test_configpush.defaultnothing&&+test_must_failgitrev-parsemaster@{push}+'++test_expect_success'@{push} with default=simple''+test_configpush.defaultsimple&&+resolvemaster@{push}refs/remotes/origin/master+'++test_expect_success'triangular @{push} fails with default=simple''+test_configpush.defaultsimple&&+test_must_failgitrev-parsetopic@{push}+'++test_expect_success'@{push} with default=current''+test_configpush.defaultcurrent&&+resolvetopic@{push}refs/remotes/origin/topic+'++test_expect_success'@{push} with default=matching''+test_configpush.defaultmatching&&+resolvetopic@{push}refs/remotes/origin/topic+'++test_expect_success'@{push} with pushremote defined''+test_configpush.defaultcurrent&&+test_configbranch.topic.pushremoteother&&+resolvetopic@{push}refs/remotes/other/topic+'++test_expect_success'@{push} with push refspecs''+test_configpush.defaultnothing&&+test_configremote.origin.pushrefs/heads/*:refs/heads/magic/*&&+gitpush&&+resolvetopic@{push}refs/remotes/origin/magic/topic+'++test_done
From: Jeff King <hidden> Date: 2016-06-15 23:04:37
This saves us having to maintain a magic number to skip past
the matched prefix.
Signed-off-by: Jeff King <redacted>
---
Noticed because I'm adding similar code in the next patch...
builtin/for-each-ref.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
@@ -659,10 +659,12 @@ static void populate_value(struct refinfo *ref)elseif(starts_with(name,"symref"))refname=ref->symref?ref->symref:"";elseif(starts_with(name,"upstream")){+constchar*branch_name;/* only local branches may have an upstream */-if(!starts_with(ref->refname,"refs/heads/"))+if(!skip_prefix(ref->refname,"refs/heads/",+&branch_name))continue;-branch=branch_get(ref->refname+11);+branch=branch_get(branch_name);refname=branch_get_upstream(branch,NULL);if(!refname)
From: Jeff King <hidden> Date: 2016-06-15 23:04:37
Just as we have "%(upstream)" to report the "@{upstream}"
for each ref, this patch adds "%(push)" to match "@{push}".
It supports the same tracking format modifiers as upstream
(because you may want to know, for example, which branches
have commits to push).
Signed-off-by: Jeff King <redacted>
---
Documentation/git-for-each-ref.txt | 6 ++++++
builtin/for-each-ref.c | 17 +++++++++++++++--
t/t6300-for-each-ref.sh | 13 ++++++++++++-
3 files changed, 33 insertions(+), 3 deletions(-)
@@ -97,6 +97,12 @@ upstream:: or "=" (in sync). Has no effect if the ref does not have tracking information associated with it.+push::+ The name of a local ref which represents the `@{push}` location+ for the displayed ref. Respects `:short`, `:track`, and+ `:trackshort` options as `upstream` does. Produces an empty+ string if no `@{push}` ref is configured.+ HEAD:: '*' if HEAD matches current ref (the checked out branch), ' ' otherwise.
From: Eric Sunshine <hidden> Date: 2016-06-15 23:04:37
On Fri, May 1, 2015 at 6:45 PM, Jeff King [off-list ref] wrote:
When we create each branch struct, we fill in the
"remote_name" field from the config, and then fill in the
actual "remote" field (with a "struct remote") based on that
name. However, it turns out that nobody really cares about
the latter field. The only two sites that access it at all
are:
1. git-merge, which uses it to notice when the branch does
not have a remote defined. But we can easily replace this
with looking at remote_name instead.
2. remote.c itself, when setting up the @{upstream} merge
config. But we don't need to save the "remote" in the
"struct branch" for that; we can just look it up for
the duration of the operation.
So there is no need to have both fields; they are redundant
with each other (the struct remote contains the name, or you
can look up the struct from the name). It would be nice to
simplify this, especially as we are going to add matching
pushremote config in a future patch (and it would be nice to
keep them consistent).
[...]
When reading the actual patch, I was surprised to see unmentioned
changes to the reg->merge_nr check. Although the merge_nr
simplification seems sensible, it appears to be unrelated to the
stated purpose of the patch, and made the review more difficult since
it required keeping track of two distinct (yet textually intertwined)
changes. I wonder if it would make more sense to apply the merge_nr
simplification as a separate preparatory patch?
From: Eric Sunshine <hidden> Date: 2016-06-15 23:04:37
On Fri, May 1, 2015 at 6:46 PM, Jeff King [off-list ref] wrote:
When remote.c loads its config, it records the
branch.*.pushremote for the current branch along with the
global remote.pushDefault value, and then binds them into a
single value: the default push for the current branch. We
then pass this value (which may be NULL) to remote_get_1
when looking up a remote for push.
This has a few downsides:
1. It's confusing. The early-binding of the "current
value" led to bugs like the one fixed by 98b406f
(remote: handle pushremote config in any order,
2014-02-24). And the fact that pushremotes fall back to
ordinary remotes is not explicit at all; it happens
because remote_get_1 cannot tell the difference between
"we are not asking for the push remote" and "there is
no push remote configured".
2. It throws away intermediate data. After read_config()
finishes, we have no idea what the value of
remote.pushDefault was, because the string has been
overwritten by the current branch's
branch.*.pushremote.
3. It doesn't record other data. We don't note the
branch.*.pushremote value for anything but the current
branch.
Let's make this more like the fetch-remote config. We'll
record the pushremote for each branch, and then explicitly
compute the correct remote for the current branch at the
time of reading.
Signed-off-by: Jeff King <redacted>
---
Versus v1, I did something a little clever by passing a function pointer
around (versus a flag and letting the caller do a conditional based on
the flag). Too clever?
FWIW: I found this "clever" version easy enough to follow.
However, if you push a tiny bit of the work into the callers of
remote_get_1(), then you can do away with the "cleverness" altogether,
can't you? Something like this:
static struct remote_get_1(const char *name, int explicit)
{
struct remote *ret = make_remote(name, 0);
...
if (explicit && valid_remote(ret))
...
...
}
struct remote *remote_get(const char *name)
{
int explicit = !!name;
read_config();
if (!name)
name = remote_for_branch(current_branch, &explicit);
return remote_get_1(name, explicit);
}
struct remote *pushremote_get(const char *name)
{
int explicit = !!name;
read_config();
if (!name)
name = pushremote_for_branch(current_branch, &explicit);
return remote_get_1(name, explicit);
}
From: Jeff King <hidden> Date: 2016-06-15 23:04:39
On Sat, May 02, 2015 at 11:34:25PM -0400, Eric Sunshine wrote:
quoted
- if (ret && ret->remote_name) {
- ret->remote = remote_get(ret->remote_name);
- if (ret->merge_nr)
- set_merge(ret);
- }
+ if (ret)
+ set_merge(ret);
When reading the actual patch, I was surprised to see unmentioned
changes to the reg->merge_nr check. Although the merge_nr
simplification seems sensible, it appears to be unrelated to the
stated purpose of the patch, and made the review more difficult since
it required keeping track of two distinct (yet textually intertwined)
changes. I wonder if it would make more sense to apply the merge_nr
simplification as a separate preparatory patch?
I didn't actually mean to change any behavior with respect to
ret->merge_nr here (and I don't think I did). What I did was blindly
move everything in the conditional after the remote_get into set_merge,
so that it happened in the same order (and the remote_get moves into
set_merge, because we no longer have the struct element that it was
formerly passed down in).
But actually, ret->merge_nr comes from make_branch, and we could
continue to respect it regardless of the remote values (i.e., they are
both preconditions to setting up the merge data, but it doesn't matter
in which order we check them).
One thing I did notice while looking at this is that it seems like we
may leak if you call branch_get multiple times. The make_branch()
function may sometimes return a brand-new branch and sometimes return a
cached version from the "branches" array. In the latter case, we
continue to update the "remote" pointer (which is wasteful but at least
does not leak because the remotes themselves are part of a cached list).
But then we will repeatedly re-allocate the ret->merge array. We
probably should make sure it is NULL before trying to fill it in.
I'll see if I can insert a cleanup patch in this part of the series.
-Peff
From: Jeff King <hidden> Date: 2016-06-15 23:04:39
On Sun, May 03, 2015 at 12:51:13AM -0400, Eric Sunshine wrote:
quoted
Versus v1, I did something a little clever by passing a function pointer
around (versus a flag and letting the caller do a conditional based on
the flag). Too clever?
FWIW: I found this "clever" version easy enough to follow.
However, if you push a tiny bit of the work into the callers of
remote_get_1(), then you can do away with the "cleverness" altogether,
can't you? Something like this:
Yeah, it's just that it goes in the opposite direction I was trying for,
which is to have as little code as possible in the wrapper functions (in
fact, I think after my changes you could even bump the read_config()
call into remote_get_1; before my changes, it depended on the pushremote
config being set before the call).
I agree it is not so much code, though, and maybe it makes the flow a
little clearer. I'll play with it for the re-roll.
-Peff
From: Eric Sunshine <hidden> Date: 2016-06-15 23:04:39
On Tue, May 5, 2015 at 3:33 PM, Jeff King [off-list ref] wrote:
On Sun, May 03, 2015 at 12:51:13AM -0400, Eric Sunshine wrote:
quoted
quoted
Versus v1, I did something a little clever by passing a function pointer
around (versus a flag and letting the caller do a conditional based on
the flag). Too clever?
FWIW: I found this "clever" version easy enough to follow.
However, if you push a tiny bit of the work into the callers of
remote_get_1(), then you can do away with the "cleverness" altogether,
can't you? Something like this:
Yeah, it's just that it goes in the opposite direction I was trying for,
which is to have as little code as possible in the wrapper functions (in
fact, I think after my changes you could even bump the read_config()
call into remote_get_1; before my changes, it depended on the pushremote
config being set before the call).
I also noticed that read_config() could be moved into remote_get_1().
In fact, with that change, then the wrappers really do collapse nicely
to 1-liners, so the "clever" function pointer approach probably is
cleaner; and it's nicely generalized over the previous round with the
boolean argument to remote_get_1().
From: Jeff King <hidden> Date: 2016-06-15 23:04:40
On Tue, May 05, 2015 at 03:31:05PM -0400, Jeff King wrote:
One thing I did notice while looking at this is that it seems like we
may leak if you call branch_get multiple times. The make_branch()
function may sometimes return a brand-new branch and sometimes return a
cached version from the "branches" array. In the latter case, we
continue to update the "remote" pointer (which is wasteful but at least
does not leak because the remotes themselves are part of a cached list).
But then we will repeatedly re-allocate the ret->merge array. We
probably should make sure it is NULL before trying to fill it in.
I'll see if I can insert a cleanup patch in this part of the series.
Here's what I came up with. I'm sending it separately in case you have
any early comments, but it will be part of the next re-roll (just before
the existing patch 2 we're discussing here).
-- >8 --
Subject: remote.c: refactor setup of branch->merge list
When we call branch_get() to lookup or create a "struct
branch", we make sure the "merge" field is filled in so that
callers can access it. But the conditions under which we do
so are a little confusing, and can lead to two funny
situations:
1. If there's no branch.*.remote config, we cannot provide
branch->merge (because it is really just an application
of branch.*.merge to our remote's refspecs). But
branch->merge_nr may be non-zero, leading callers to be
believe they can access branch->merge (e.g., in
branch_merge_matches and elsewhere).
It doesn't look like this can cause a segfault in
practice, as most code paths dealing with merge config
will bail early if there is no remote defined. But it's
a bit of a dangerous construct.
We can fix this by setting merge_nr to "0" explicitly
when we realize that we have no merge config. Note that
merge_nr also counts the "merge_name" fields (which we
_do_ have; that's how merge_nr got incremented), so we
will "lose" access to them, in the sense that we forget
how many we had. But no callers actually care; we use
merge_name only while iteratively reading the config,
and then convert it to the final "merge" form the first
time somebody calls branch_get().
2. We set up the "merge" field every time branch_get is
called, even if it has already been done. This leaks
memory.
It's not a big deal in practice, since most code paths
will access only one branch, or perhaps each branch
only one time. But if you want to be pathological, you
can leak arbitrary memory with:
yes @{upstream} | head -1000 | git rev-list --stdin
We can fix this by skipping setup when branch->merge is
already non-NULL.
In addition to those two fixes, this patch pushes the "do we
need to setup merge?" logic down into set_merge, where it is
a bit easier to follow.
Signed-off-by: Jeff King <redacted>
---
remote.c | 19 +++++++++++++++----
1 file changed, 15 insertions(+), 4 deletions(-)
From: Jeff King <hidden> Date: 2016-06-15 23:04:40
On Tue, May 05, 2015 at 03:48:29PM -0400, Eric Sunshine wrote:
quoted
Yeah, it's just that it goes in the opposite direction I was trying for,
which is to have as little code as possible in the wrapper functions (in
fact, I think after my changes you could even bump the read_config()
call into remote_get_1; before my changes, it depended on the pushremote
config being set before the call).
I also noticed that read_config() could be moved into remote_get_1().
In fact, with that change, then the wrappers really do collapse nicely
to 1-liners, so the "clever" function pointer approach probably is
cleaner; and it's nicely generalized over the previous round with the
boolean argument to remote_get_1().
I ended up with this patch, which will go right after the one we're
discussing:
-- >8 --
Subject: remote.c: hoist read_config into remote_get_1
Before the previous commit, we had to make sure that
read_config() was called before entering remote_get_1,
because we needed to pass pushremote_name by value. But now
that we pass a function, we can let remote_get_1 handle
loading the config itself, turning our wrappers into true
one-liners.
Signed-off-by: Jeff King <redacted>
---
remote.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
From: Eric Sunshine <hidden> Date: 2016-06-15 23:04:41
On Thu, May 7, 2015 at 5:38 AM, Jeff King [off-list ref] wrote:
On Tue, May 05, 2015 at 03:48:29PM -0400, Eric Sunshine wrote:
quoted
quoted
Yeah, it's just that it goes in the opposite direction I was trying for,
which is to have as little code as possible in the wrapper functions (in
fact, I think after my changes you could even bump the read_config()
call into remote_get_1; before my changes, it depended on the pushremote
config being set before the call).
I also noticed that read_config() could be moved into remote_get_1().
In fact, with that change, then the wrappers really do collapse nicely
to 1-liners, so the "clever" function pointer approach probably is
cleaner; and it's nicely generalized over the previous round with the
boolean argument to remote_get_1().
I ended up with this patch, which will go right after the one we're
discussing:
Nice, I like it.
quoted hunk
-- >8 --
Subject: remote.c: hoist read_config into remote_get_1
Before the previous commit, we had to make sure that
read_config() was called before entering remote_get_1,
because we needed to pass pushremote_name by value. But now
that we pass a function, we can let remote_get_1 handle
loading the config itself, turning our wrappers into true
one-liners.
Signed-off-by: Jeff King <redacted>
---
remote.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)