Re: [PATCH v2 6/9] branch: display publish branch
Jeff King wrote:
On Sat, Apr 12, 2014 at 10:05:15AM -0500, Felipe Contreras wrote:
As you can see; some branches are published, others are not. The ones that
are
not published don't have a @{publish}, and `git branch -v` doesn't show
them.
Why is that hard to understand?
Do you ever push the unpublished branches anywhere at all? If not, then
you would not have a tracking branch. E.g., git _would_ push to remote
gh, branch refs/heads/topic, but there is no remote tracking branch
refs/remotes/gh/topic, because you have never actually pushed there.
So there is no @{publish} branch.
Or do you have some branches in a state where they are pushed, but not
published? It wasn't clear to me from your example if your pu or
dev/remote/hg-extra ever get pushed.
Sometimes I do push these branches, but I don't understand what you mean by
pushed state. When you push something no states are changed. Say I do:
% git push tmp wip-feature
% git push backup wip-feature
So I pushed a branch to two different repositories, the former one might not
even exist any more. Who cares? No states have changed. The fact that this
branch was pushed doesn't change anything about the nature of the branch.
I do not use git branch -v myself,
Me neither (at least not the upstream version).
so I don't personally care that much how it behaves. But I do use a separate
script that does the same thing, and I would want it to show the ahead/behind
relationship between each branch and where it would be pushed to (and as I
said, I define mine with refspecs). Right now it uses nasty hackery to guess
at where things will be pushed, but ideally it would ask git via @{push} or
some similar mechanism.
Yes, but you can push a branch to many locations, to which one should the
script show the tracking information? IMO it should be the one location you
explicitly configured, and in the case of wip-feature is no location.
If the former (you do not actually push them), then I think the semantics I
am looking for and the ones you want would coincide. If not, then I think we
are really talking about two different things.
I ask again what is so difficult about the notion that there are two kinds of
branches?
A)
% git checkout ready-feature
% git push tmp ready-feature
% git push -p github ready-feature
% git push backup ready-feature
B)
% git checkout wip-feature
% git push tmp wip-feature
% git push backup wip-feature
In a haste these branches might not look very different, but conceptually they
are. One has a location where it is publicly visible, and where you wish to
push regularly, the other one doesn't.
Whether you push a branch or not is not really important, it's whether or not
the branch has a *special* place where you push to.
--
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 6/9] branch: display publish branch
On Sat, Apr 12, 2014 at 10:05:15AM -0500, Felipe Contreras wrote:
As you can see; some branches are published, others are not. The ones that are
not published don't have a @{publish}, and `git branch -v` doesn't show them.
Why is that hard to understand?
Do you ever push the unpublished branches anywhere at all? If not, then
you would not have a tracking branch. E.g., git _would_ push to remote
gh, branch refs/heads/topic, but there is no remote tracking branch
refs/remotes/gh/topic, because you have never actually pushed there.
So there is no @{publish} branch.
Or do you have some branches in a state where they are pushed, but not
published? It wasn't clear to me from your example if your pu or
dev/remote/hg-extra ever get pushed.
I do not use git branch -v myself, so I don't personally care that
much how it behaves. But I do use a separate script that does the same
thing, and I would want it to show the ahead/behind relationship between
each branch and where it would be pushed to (and as I said, I define
mine with refspecs). Right now it uses nasty hackery to guess at where
things will be pushed, but ideally it would ask git via @{push} or some
similar mechanism.
If the former (you do not actually push them), then I think the
semantics I am looking for and the ones you want would coincide. If not,
then I think we are really talking about two different things.
-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 6/9] branch: display publish branch
On Fri, Apr 11, 2014 at 08:48:01AM -0500, Felipe Contreras wrote:
I think of @{publish} as the branch the user has configured to push
to; it overrides all other configurations (push.default and push
refspecs). I wouldn't mind having a @{push} *in addition* to @{publish}
that would have the behavior you mention, but for @{publish} I'm pretty
certain the behavior I want is that it maps *directly* to what the user
has configured.
I guess I don't understand why we need branch.*.push when we already
have push refspecs that do the same thing (and are more powerful, as
they can glob).
The behavior you describe is not useful to me, as it would mean having
to manage branch.*.push as a duplicate of the information that is
already found in remote.$(git config remote.pushdefault).push. I do
not mind if the two co-exist, but please do not take the short @{p} as
your series does (not only because of @{push}, but also because @{pull}
has been mentioned elsewhere as a possible other name for @{upstream}).
-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 6/9] branch: display publish branch
On Fri, Apr 11, 2014 at 12:24:35PM -0700, Junio C Hamano wrote:
But the branch.master.push setting does not do
anything to git push.
I am not sure I understand this. I thought that the desire behind
the branch.*.push is to allow something like:
... other things in the config ...
[remote]
pushdefault = foo
[remote foo]
url = ...
push = +refs/heads/*:refs/remotes/satellite/*
fetch = +refs/heads/*:refs/remotes/foo/*
[branch master]
; pushremote = foo
push = refs/heads/bar
so that git push on 'master' will override the more generic all
local branches here will go to their remote-tracking hierarchy for
this satellite refspec. And in that sense branch.master.push would
do something to git push.
Ah, I see. If I set push.default to upstream, then the config I
showed before _does_ affect git push. But I do not usually do that. I
have push.default set to current, and sometimes override it using push
refspecs on certain repositories.
And that is why I find branch.*.push and Felipe's @{publish} useless for
my workflow. Pushes already go where I want them to, and I just want a
way to ask git to perform that config resolution for me. Whereas
Felipe's workflow is (I think) something like:
# make a new branch...
git checkout -b topic origin/master
# now publish our branch, and remember our publishing point
git push -p my-repo topic
# and now further pushes automatically go to my-repo/topic
git push
I can see there is some value in that override if you do things like:
git push -p my-repo topic:some-other-name
because the -p means remember this other name I gave.
I would think in such a workflow that most of your branches would end up
with publish config, though. And therefore @{publish} would become
equivalent to where you would push. But Felipe indicated that he would
not want branch -vv to match where all branches would be pushed, but
rather only those that were specifically configured. So maybe I do not
understand his workflow after all.
-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 6/9] branch: display publish branch
Jeff King wrote:
On Fri, Apr 11, 2014 at 08:48:01AM -0500, Felipe Contreras wrote:
I think of @{publish} as the branch the user has configured to push
to; it overrides all other configurations (push.default and push
refspecs). I wouldn't mind having a @{push} *in addition* to @{publish}
that would have the behavior you mention, but for @{publish} I'm pretty
certain the behavior I want is that it maps *directly* to what the user
has configured.
I guess I don't understand why we need branch.*.push when we already
have push refspecs that do the same thing (and are more powerful, as
they can glob).
Really? I think it's pretty simple.
I have a configuration similar to the following
[remote gh]
url = g...@github.com:felipec/git.git
[branch master]
pushremote = gh
push = refs/heads/master
[branch fc/master]
pushremote = gh
push = refs/heads/fc/master
[branch up/publish]
pushremote = gh
push = refs/heads/fc/publish
Now, if I didn't, I could create it easily with something like this:
% git push -p gh master
% git push -p gh fc/master
% git push -p gh up/publish:fc/publish
How would that translate to push refspecs?
[remote gh]
url = g...@github.com:felipec/git.git
push = refs/heads/master:refs/heads/master
push = refs/heads/fc/master:refs/heads/fc/master
push = refs/heads/up/master:refs/heads/fc/publish
[branch master]
pushremote = gh
[branch fc/master]
pushremote = gh
[branch up/publish]
pushremote = gh
So in theory it could be possible to make it work without branch.x.push.
If I run `git branch -v`, it would show the publish branch correctly.
master cee0c27 [origin/master, gh/master] Git 1.9.1
However, if I have a configuration like this:
[remote gh]
url = g...@github.com:felipec/git.git
push = refs/heads/*:refs/heads/*
Git would still show the same publish branch, even though the user never
explicitely told it do to so (e.g. with `git push -p`). To me this is not OK;
if I haven't specifically set a publish branch, it shouldn't be shown.
And then, what happens when I do:
% git branch --unset-upstream up/publish
Or:
% git branch -d up/publish
Should Git remove the appropriate push refspec? What if that refspec was
manually added by the user before the concept of the publish branch even
existed?
To me using the refspec just adds more complications, and it's not symetric
with @{upstream}. With branch.x.push, the symetry is very much there; the code
is similar to @{upstream}, the configuration as well, and what the user expects
too; it's much simpler. Also, the user can clearly see what are his manually
configured refspecs, as opposed to the ones added by `git push -p`.
It's just neat.
--
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 6/9] branch: display publish branch
Jeff King wrote:
On Fri, Apr 11, 2014 at 12:24:35PM -0700, Junio C Hamano wrote:
But the branch.master.push setting does not do
anything to git push.
I am not sure I understand this. I thought that the desire behind
the branch.*.push is to allow something like:
... other things in the config ...
[remote]
pushdefault = foo
[remote foo]
url = ...
push = +refs/heads/*:refs/remotes/satellite/*
fetch = +refs/heads/*:refs/remotes/foo/*
[branch master]
; pushremote = foo
push = refs/heads/bar
so that git push on 'master' will override the more generic all
local branches here will go to their remote-tracking hierarchy for
this satellite refspec. And in that sense branch.master.push would
do something to git push.
Ah, I see. If I set push.default to upstream, then the config I
showed before _does_ affect git push. But I do not usually do that. I
have push.default set to current, and sometimes override it using push
refspecs on certain repositories.
And that is why I find branch.*.push and Felipe's @{publish} useless for
my workflow. Pushes already go where I want them to, and I just want a
way to ask git to perform that config resolution for me. Whereas
Felipe's workflow is (I think) something like:
# make a new branch...
git checkout -b topic origin/master
# now publish our branch, and remember our publishing point
git push -p my-repo topic
# and now further pushes automatically go to my-repo/topic
git push
I can see there is some value in that override if you do things like:
git push -p my-repo topic:some-other-name
because the -p means remember this other name I gave.
I would think in such a workflow that most of your branches would end up with
publish config, though. And therefore @{publish} would become equivalent to
where you would push.
But Felipe indicated that he would not want branch -vv to match where all
branches would be pushed, but rather only those that were specifically
configured. So maybe I do not understand his workflow after all.
It's a pretty typical triangular workflow, with a touch of fork maintainership.
Here are some types of branches I have:
* master [origin/master, gh/master] Git 1.9.1
My main master branch, I use it as a base point for many other branches. I
don't use origin/master because that's a moving target.
* dev/remote/hg-extra [master] remote-hg: store extra hg information in notes
A development branch. I don't publish those, therefore no @{publish}.
* fc/publish [fc/branch/nice-verbose, gh/fc/publish] sha1_name: add support for
@{publish} marks
A branch that is all good. I publish those, and use them for git-fc (my fork).
I think they should be in Git's core, but haven't been merged for some reason
or another.
Notice that the upstream branch is another local branch, not master. Strictly
speaking it's not an upstream branch, but I want 'git rebase' to use that as
the base point. Another @{base} concept might be more appropriate, but those
patches are a different story.
* up/publish [master] sha1_name: add support for @{publish} marks
A branch that should be sent upstream. I don't publish those.
Notice up/publish is different from fc/publish because the later depends on
another fc/* branch, which wasn't accepted upstream.
* fc/master [gh/fc/master] prompt: fix missing file errors in zsh
My main branch, used for git-fc. I merge Git's master, and cherry-pick various
fixes, so it has always the latest and greatest stuff.
Notice that 'gh/fc/master' is the publish branch, there is no upstream.
* pu [] Merge branch 'travis-ci' into pu
Similar to Junio's pu, I use `git reintegrate` to generate this branch using
'master' as the baseline, and merging all the fc/* branches. The result should
be identical to fc/master, if not, we are missing something from upstream, or
there's something missing in the fc/* branches.
It's not published, and has no upstream.
As you can see; some branches are published, others are not. The ones that are
not published don't have a @{publish}, and `git branch -v` doesn't show them.
Why is that hard to understand?
--
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 6/9] branch: display publish branch
On Thu, Apr 10, 2014 at 05:36:59PM -0500, Felipe Contreras wrote:
I noticed that this only picks up a publish-branch if
branch.*.pushremote is configured. What happened to the case when
remote.pushdefault is configured?
What happens when branch.*.remote is not configured for @{upstream}? The same
thing.
I don't know if that is a good comparison.
In other threads, the discussed meaning of @{publish} was something like
the tracking branch of the ref you would push to if you ran 'git push'
without arguments.
That is consistent with @{upstream} being the tracking branch of the
ref you would pull from with 'git pull'. But git pull without a
branch.*.remote will do nothing, so what pull would do is the same as
what you have configured in your branch.*.remote.
Whereas git push does not depend on having branch.*.pushremote
configured. Its behavior is based on push.default and push refspecs, so
what push would do must take that into account.
It might be useful to visualize what would be the name of the branch when
pushing it (without a refspec) even if the publish branch hasn't been
configured, but I think the code would be much more coplicated, and it would
break symetry with @{upstream}, besides, the user can just do 'git push -p
branch', and from that moment on it will be visible.
It is more complicated (see the patches that Junio had at
jk/branch-at-publish), but I think it is more likely to do what the user
expects.
For instance, it looks like your @{publish} requires config like:
[branch master]
pushremote = foo
push = refs/heads/bar
to operate. Setting pushremote affects what git push does; it will
go to the foo remote. But the branch.master.push setting does not do
anything to git push. Only a push refspec (or push.default setting)
will change that. So the branch.*.push must be kept in sync manually
(perhaps by running git push -p).
Whereas if @{publish} means where you would push to, then
branch.*.push does not need to exist at all. The values can be taken
automatically from the other push settings.
-Peff
PS I first tried just setting branch.master.pushremote without setting
branch.master.push. This results in a segfault, as branch_get()
assumes that push_name is always set and tries to xstrdup() it.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 6/9] branch: display publish branch
Jeff King wrote:
On Thu, Apr 10, 2014 at 05:36:59PM -0500, Felipe Contreras wrote:
I noticed that this only picks up a publish-branch if
branch.*.pushremote is configured. What happened to the case when
remote.pushdefault is configured?
What happens when branch.*.remote is not configured for @{upstream}? The
same
thing.
I don't know if that is a good comparison.
I think it is. @{publish} is like @{upstream}. Period.
In other threads, the discussed meaning of @{publish} was something like
the tracking branch of the ref you would push to if you ran 'git push'
without arguments.
And I disagree.
That is consistent with @{upstream} being the tracking branch of the
ref you would pull from with 'git pull'. But git pull without a
branch.*.remote will do nothing, so what pull would do is the same as
what you have configured in your branch.*.remote.
Whereas git push does not depend on having branch.*.pushremote
configured. Its behavior is based on push.default and push refspecs, so
what push would do must take that into account.
Yes, but we are not talking about 'git push', we are talking about
@{publish}.
I think of @{publish} as the branch the user has configured to push
to; it overrides all other configurations (push.default and push
refspecs). I wouldn't mind having a @{push} *in addition* to @{publish}
that would have the behavior you mention, but for @{publish} I'm pretty
certain the behavior I want is that it maps *directly* to what the user
has configured.
Similarly, I don't want 'git branch -vv' to show @{push}; it would be a
mess to show something on all the branches, probably origin/$branch, and
probably all ahead/behind. I want it to show @{publish}, so only the
branches the user has *explicitly* configured.
It might be useful to visualize what would be the name of the branch when
pushing it (without a refspec) even if the publish branch hasn't been
configured, but I think the code would be much more coplicated, and it would
break symetry with @{upstream}, besides, the user can just do 'git push -p
branch', and from that moment on it will be visible.
It is more complicated (see the patches that Junio had at
jk/branch-at-publish), but I think it is more likely to do what the user
expects.
For instance, it looks like your @{publish} requires config like:
[branch master]
pushremote = foo
push = refs/heads/bar
to operate. Setting pushremote affects what git push does; it will
go to the foo remote. But the branch.master.push setting does not do
anything to git push. Only a push refspec (or push.default setting)
will change that. So the branch.*.push must be kept in sync manually
(perhaps by running git push -p).
Whereas if @{publish} means where you would push to
It doesn't mean that to me.
For the record, I've been thinking about this for a long long time, and
I argued for @{push} and @{publish} long before you discussed this in
January (which apparently you forgot). I implemented this more than half
a year ago, and have been using it since; it works great. The problem of
triangular workflows is pretty much solved for me.
--
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 6/9] branch: display publish branch
Jeff King p...@peff.net writes:
For instance, it looks like your @{publish} requires config like:
[branch master]
pushremote = foo
push = refs/heads/bar
to operate. Setting pushremote affects what git push does; it will
go to the foo remote.
OK, and the same thing would happen if branch.*.pushremote is not
set for any branch, but remote.pushdefault is set to 'foo', right?
But the branch.master.push setting does not do
anything to git push.
I am not sure I understand this. I thought that the desire behind
the branch.*.push is to allow something like:
... other things in the config ...
[remote]
pushdefault = foo
[remote foo]
url = ...
push = +refs/heads/*:refs/remotes/satellite/*
fetch = +refs/heads/*:refs/remotes/foo/*
[branch master]
; pushremote = foo
push = refs/heads/bar
so that git push on 'master' will override the more generic all
local branches here will go to their remote-tracking hierarchy for
this satellite refspec. And in that sense branch.master.push would
do something to git push.
I personally think that kind of override adds any more values than
it causes confusion, so I think it is OK not to support such uses of
branch.*.push at all. A configuration without branch.master.push
may cause git push on 'master' to update refs/heads/master at the
remote, and if we fetched from 'foo' immediately after pushing
there, it would come back as refs/remotes/foo/master, and it would
be natural for users to expect that master@{publish} would be
refs/remotes/foo/master in such a case.
If we supported setting branch.master.push to refs/heads/bar, then
master would be pushed as refs/heads/bar over there and it would
come back as refs/remotes/foo/bar here, so I would expect that to be
the value of master@{publish}.
Only a push refspec (or push.default setting)
will change that. So the branch.*.push must be kept in sync manually
(perhaps by running git push -p).
Whereas if @{publish} means where you would push to, then
branch.*.push does not need to exist at all. The values can be taken
automatically from the other push settings.
-Peff
PS I first tried just setting branch.master.pushremote without setting
branch.master.push. This results in a segfault, as branch_get()
assumes that push_name is always set and tries to xstrdup() it.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 6/9] branch: display publish branch
Junio C Hamano wrote:
Jeff King p...@peff.net writes:
For instance, it looks like your @{publish} requires config like:
[branch master]
pushremote = foo
push = refs/heads/bar
to operate. Setting pushremote affects what git push does; it will
go to the foo remote.
OK, and the same thing would happen if branch.*.pushremote is not
set for any branch, but remote.pushdefault is set to 'foo', right?
But the branch.master.push setting does not do
anything to git push.
I am not sure I understand this. I thought that the desire behind
the branch.*.push is to allow something like:
... other things in the config ...
[remote]
pushdefault = foo
[remote foo]
url = ...
push = +refs/heads/*:refs/remotes/satellite/*
fetch = +refs/heads/*:refs/remotes/foo/*
[branch master]
; pushremote = foo
push = refs/heads/bar
so that git push on 'master' will override the more generic all
local branches here will go to their remote-tracking hierarchy for
this satellite refspec. And in that sense branch.master.push would
do something to git push.
In my patches the above doesn't work; branch.master.push doesn't do anything if
.pushremote isn't there.
I'm always thinking from the common user's point of view, and the common user
doesn't know what branch.master.push is, but he knows he did
`git branch -p foo/bar master` (or something like that), and
`git branch -v` would corroborate that.
So you would have something like this:
[remote foo]
url = ...
push = +refs/heads/*:refs/remotes/satellite/*
fetch = +refs/heads/*:refs/remotes/foo/*
[branch master]
pushremote = foo
push = refs/heads/bar
I personally think that kind of override adds any more values than
it causes confusion, so I think it is OK not to support such uses of
branch.*.push at all. A configuration without branch.master.push
may cause git push on 'master' to update refs/heads/master at the
remote,
How? If branch.master.push is not configured, then git push would push
'master' to refs/remotes/satellite/master on the remote.
--
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 6/9] branch: display publish branch
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
builtin/branch.c | 17 -
t/t6040-tracking-info.sh | 5 +++--
2 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index 17773d7..e0a8d0a 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -42,6 +42,7 @@ static char branch_colors[][COLOR_MAXLEN] = {
GIT_COLOR_NORMAL, /* LOCAL */
GIT_COLOR_GREEN,/* CURRENT */
GIT_COLOR_BLUE, /* UPSTREAM */
+ GIT_COLOR_YELLOW, /* PUBLISH */
};
enum color_branch {
BRANCH_COLOR_RESET = 0,
@@ -49,7 +50,8 @@ enum color_branch {
BRANCH_COLOR_REMOTE = 2,
BRANCH_COLOR_LOCAL = 3,
BRANCH_COLOR_CURRENT = 4,
- BRANCH_COLOR_UPSTREAM = 5
+ BRANCH_COLOR_UPSTREAM = 5,
+ BRANCH_COLOR_PUBLISH = 6
};
static enum merge_filter {
@@ -76,6 +78,8 @@ static int parse_branch_color_slot(const char *var, int ofs)
return BRANCH_COLOR_CURRENT;
if (!strcasecmp(var+ofs, upstream))
return BRANCH_COLOR_UPSTREAM;
+ if (!strcasecmp(var+ofs, publish))
+ return BRANCH_COLOR_PUBLISH;
return -1;
}
@@ -448,6 +452,17 @@ static void fill_tracking_info(struct strbuf *stat, const
char *branch_name,
else
strbuf_addstr(fancy, ref);
}
+ if (branch-push.dst) {
+ ref = shorten_unambiguous_ref(branch-push.dst, 0);
+ if (fancy.len)
+ strbuf_addstr(fancy, , );
+ if (want_color(branch_use_color))
+ strbuf_addf(fancy, %s%s%s,
+ branch_get_color(BRANCH_COLOR_PUBLISH),
+ ref,
branch_get_color(BRANCH_COLOR_RESET));
+ else
+ strbuf_addstr(fancy, ref);
+ }
if (upstream_is_gone) {
if (show_upstream_ref)
diff --git a/t/t6040-tracking-info.sh b/t/t6040-tracking-info.sh
index 7ac8fd0..8b9ef63 100755
--- a/t/t6040-tracking-info.sh
+++ b/t/t6040-tracking-info.sh
@@ -33,7 +33,8 @@ test_expect_success setup '
git checkout -b b5 --track brokenbase
advance g
git branch -d brokenbase
- git checkout -b b6 origin
+ git checkout -b b6 origin
+ git branch --set-publish origin/master b6
)
git checkout -b follower --track master
advance h
@@ -64,7 +65,7 @@ b2 [origin/master: ahead 1, behind 1] d
b3 [origin/master: behind 1] b
b4 [origin/master: ahead 2] f
b5 [brokenbase: gone] g
-b6 [origin/master] c
+b6 [origin/master, origin/master] c
EOF
test_expect_success 'branch -vv' '
--
1.9.1+fc1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 6/9] branch: display publish branch
Felipe Contreras wrote: Signed-off-by: Felipe Contreras felipe.contre...@gmail.com Please write a commit message, preferably showing the new git-branch output. I noticed that this only picks up a publish-branch if branch.*.pushremote is configured. What happened to the case when remote.pushdefault is configured? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 6/9] branch: display publish branch
Ramkumar Ramachandra wrote:
Felipe Contreras wrote:
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
Please write a commit message, preferably showing the new git-branch output.
Yeah... this has been sitting in git-fc for quite a while, I wasn't expecting
to send this patch series again given that nobody commented on v1.
I noticed that this only picks up a publish-branch if
branch.*.pushremote is configured. What happened to the case when
remote.pushdefault is configured?
What happens when branch.*.remote is not configured for @{upstream}? The same
thing.
It might be useful to visualize what would be the name of the branch when
pushing it (without a refspec) even if the publish branch hasn't been
configured, but I think the code would be much more coplicated, and it would
break symetry with @{upstream}, besides, the user can just do 'git push -p
branch', and from that moment on it will be visible.
--
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
