From: Bill Lear <hidden> Date: 2016-06-15 22:45:32
We have had a few "crossed stream" problems when developers are
working on a local branch and they do an unguarded git push/pull,
when they really intended to do git push/pull origin branchname.
We use git in a way that makes it desirable for us to only push/pull
to the same remote branch. So, if I'm in branch X, I want 'git push'
to push to origin/X, and 'git pull' to fetch into origin/X and then
merge into X from origin/X.
In other words, we want git push/pull to behave in branches other than
master the same way it does when in master.
I have discovered the '--track' option when creating a local branch,
and this appears to me to be the thing that gives us the desired
behavior.
Before I tell the rest of the team that this is the correct way
to do things, I need to be sure I am correct, so if anyone here
can confirm or deny this, I'd appreciate it.
Also, once a branch has been created, how can we add a '--track' option
after the fact?
Finally, is there a 'global' config setting that would set this behavior
for all repos (new or existing)?
We are using git 1.6.* versions here, mostly.
Thanks.
Bill
On Wed, Oct 29, 2008 at 4:23 PM, Bill Lear [off-list ref] wrote:
We have had a few "crossed stream" problems when developers are
working on a local branch and they do an unguarded git push/pull,
when they really intended to do git push/pull origin branchname.
We use git in a way that makes it desirable for us to only push/pull
to the same remote branch. So, if I'm in branch X, I want 'git push'
to push to origin/X, and 'git pull' to fetch into origin/X and then
merge into X from origin/X.
In other words, we want git push/pull to behave in branches other than
master the same way it does when in master.
I have discovered the '--track' option when creating a local branch,
and this appears to me to be the thing that gives us the desired
behavior.
branch.autosetupmerge controls if --track is used by default (it is
true by default since a long time)
(See "git help config" for details)
Before I tell the rest of the team that this is the correct way
to do things, I need to be sure I am correct, so if anyone here
can confirm or deny this, I'd appreciate it.
It should just work (at least in the lastest releases) when creating a
branch from a remote branch.
$ git checkout -b X origin/X
or
$ git branch X origin/X
Branch X set up to track remote branch refs/remotes/origin/X
Also, once a branch has been created, how can we add a '--track' option
after the fact?
It it just two configs (apart from the remote repository). A help
message should appear when using "git pull" without arguments and it
cannot figure out the branch to merge:
$ # currently in branch next
$ git pull
You asked me to pull without telling me which branch you
want to merge with, and 'branch.next.merge' in
your configuration file does not tell me either. Please
name which branch you want to merge on the command line and
try again (e.g. 'git pull <repository> <refspec>').
See git-pull(1) for details on the refspec.
If you often merge with the same branch, you may want to
configure the following variables in your configuration
file:
branch.next.remote = <nickname>
branch.next.merge = <remote-ref>
remote.<nickname>.url = <url>
remote.<nickname>.fetch = <refspec>
See git-config(1) for details.
[end]
so to add it after the fact you should execute:
$ git config branch.next.remote origin
$ git config branch.next.merge refs/heads/next
Finally, is there a 'global' config setting that would set this behavior
for all repos (new or existing)?
From: Bill Lear <hidden> Date: 2016-06-15 22:45:33
On Wednesday, October 29, 2008 at 17:25:37 (+0100) Santi Béjar writes:
On Wed, Oct 29, 2008 at 4:23 PM, Bill Lear [off-list ref] wrote:
quoted
We have had a few "crossed stream" problems when developers are
working on a local branch and they do an unguarded git push/pull,
when they really intended to do git push/pull origin branchname.
We use git in a way that makes it desirable for us to only push/pull
to the same remote branch. So, if I'm in branch X, I want 'git push'
to push to origin/X, and 'git pull' to fetch into origin/X and then
merge into X from origin/X.
In other words, we want git push/pull to behave in branches other than
master the same way it does when in master.
I have discovered the '--track' option when creating a local branch,
and this appears to me to be the thing that gives us the desired
behavior.
branch.autosetupmerge controls if --track is used by default (it is
true by default since a long time)
(See "git help config" for details)
Ah, problem solved then. I'll just have everyone upgrade to the
latest git. Thanks very much, Santi.
Bill
From: Sam Vilain <hidden> Date: 2016-06-15 22:45:33
On Wed, 2008-10-29 at 09:23 -0600, Bill Lear wrote:
We use git in a way that makes it desirable for us to only push/pull
to the same remote branch. So, if I'm in branch X, I want 'git push'
to push to origin/X, and 'git pull' to fetch into origin/X and then
merge into X from origin/X.
In other words, we want git push/pull to behave in branches other than
master the same way it does when in master.
I have discovered the '--track' option when creating a local branch,
and this appears to me to be the thing that gives us the desired
behavior.
As things currently stand this is not achievable behaviour. The
behaviour of 'git push' is to push all matching refs. If you are lucky
this is what you intended, but it also pushes any changes to *other*
branches that you have made.
I have tabled a change proposal to make it work as you suggest in a
separate thread.
Sam
From: Bill Lear <hidden> Date: 2016-06-15 22:45:33
On Wednesday, October 29, 2008 at 22:12:18 (-0700) Sam Vilain writes:
On Wed, 2008-10-29 at 09:23 -0600, Bill Lear wrote:
quoted
We use git in a way that makes it desirable for us to only push/pull
to the same remote branch. So, if I'm in branch X, I want 'git push'
to push to origin/X, and 'git pull' to fetch into origin/X and then
merge into X from origin/X.
In other words, we want git push/pull to behave in branches other than
master the same way it does when in master.
I have discovered the '--track' option when creating a local branch,
and this appears to me to be the thing that gives us the desired
behavior.
As things currently stand this is not achievable behaviour. The
behaviour of 'git push' is to push all matching refs. If you are lucky
this is what you intended, but it also pushes any changes to *other*
branches that you have made.
I have tabled a change proposal to make it work as you suggest in a
separate thread.
Ok, now I'm confused. The ONLY thing I want to prevent is the
"crossing of streams" issue. If I am on branch X and issue 'git
push', I want X, and ONLY X, to be pushed to the remote repository's X
branch --- I don't care if other branches are pushed to their
respective remote branches, as long as they don't get merged to X.
So, are you saying that Santi was incorrect, and that in fact
the push will result in a merge of the branches?
Bill
From: Bill Lear <hidden> Date: 2016-06-15 22:45:33
On Thursday, October 30, 2008 at 06:04:54 (-0600) Bill Lear writes:
On Wednesday, October 29, 2008 at 22:12:18 (-0700) Sam Vilain writes:
quoted
On Wed, 2008-10-29 at 09:23 -0600, Bill Lear wrote:
quoted
We use git in a way that makes it desirable for us to only push/pull
to the same remote branch. So, if I'm in branch X, I want 'git push'
to push to origin/X, and 'git pull' to fetch into origin/X and then
merge into X from origin/X.
In other words, we want git push/pull to behave in branches other than
master the same way it does when in master.
I have discovered the '--track' option when creating a local branch,
and this appears to me to be the thing that gives us the desired
behavior.
As things currently stand this is not achievable behaviour. The
behaviour of 'git push' is to push all matching refs. If you are lucky
this is what you intended, but it also pushes any changes to *other*
branches that you have made.
I have tabled a change proposal to make it work as you suggest in a
separate thread.
Ok, now I'm confused. The ONLY thing I want to prevent is the
"crossing of streams" issue. If I am on branch X and issue 'git
push', I want X, and ONLY X, to be pushed to the remote repository's X
branch --- I don't care if other branches are pushed to their
respective remote branches, as long as they don't get merged to X.
Oh, and also the same thing for 'git pull' --- sorry to leave that out.
Bill
From: Andreas Ericsson <hidden> Date: 2016-06-15 22:45:33
Bill Lear wrote:
On Thursday, October 30, 2008 at 06:04:54 (-0600) Bill Lear writes:
quoted
On Wednesday, October 29, 2008 at 22:12:18 (-0700) Sam Vilain writes:
quoted
On Wed, 2008-10-29 at 09:23 -0600, Bill Lear wrote:
quoted
We use git in a way that makes it desirable for us to only push/pull
to the same remote branch. So, if I'm in branch X, I want 'git push'
to push to origin/X, and 'git pull' to fetch into origin/X and then
merge into X from origin/X.
In other words, we want git push/pull to behave in branches other than
master the same way it does when in master.
I have discovered the '--track' option when creating a local branch,
and this appears to me to be the thing that gives us the desired
behavior.
As things currently stand this is not achievable behaviour. The
behaviour of 'git push' is to push all matching refs. If you are lucky
this is what you intended, but it also pushes any changes to *other*
branches that you have made.
I have tabled a change proposal to make it work as you suggest in a
separate thread.
Ok, now I'm confused. The ONLY thing I want to prevent is the
"crossing of streams" issue. If I am on branch X and issue 'git
push', I want X, and ONLY X, to be pushed to the remote repository's X
branch --- I don't care if other branches are pushed to their
respective remote branches, as long as they don't get merged to X.
Oh, and also the same thing for 'git pull' --- sorry to leave that out.
This particular bikeshed was painted a long time ago, with the consensus
going in favour of "git push" pushing all *matching* refspecs.
To convince people, I think you need to either come up with arguments
nullifying all the arguments *for* pushing all matching refspecs along
with patches to make the default configurable, with your preferred way
as a default, and a nifty enough shorthand for pushing/fetching all
matching refspecs. For preference, they should be at least 3 separate
patches.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
On Thu, Oct 30, 2008 at 1:04 PM, Bill Lear [off-list ref] wrote:
On Wednesday, October 29, 2008 at 22:12:18 (-0700) Sam Vilain writes:
quoted
On Wed, 2008-10-29 at 09:23 -0600, Bill Lear wrote:
quoted
We use git in a way that makes it desirable for us to only push/pull
to the same remote branch. So, if I'm in branch X, I want 'git push'
to push to origin/X, and 'git pull' to fetch into origin/X and then
merge into X from origin/X.
In other words, we want git push/pull to behave in branches other than
master the same way it does when in master.
I have discovered the '--track' option when creating a local branch,
and this appears to me to be the thing that gives us the desired
behavior.
As things currently stand this is not achievable behaviour. The
behaviour of 'git push' is to push all matching refs. If you are lucky
this is what you intended, but it also pushes any changes to *other*
branches that you have made.
I have tabled a change proposal to make it work as you suggest in a
separate thread.
Ok, now I'm confused. The ONLY thing I want to prevent is the
"crossing of streams" issue. If I am on branch X and issue 'git
push', I want X, and ONLY X, to be pushed to the remote repository's X
branch --- I don't care if other branches are pushed to their
respective remote branches, as long as they don't get merged to X.
No branches will get merged in a push.
So, are you saying that Santi was incorrect, and that in fact
the push will result in a merge of the branches?
Sorry, I was (partly) incorrect because I was only talking about pull.
For push you can add a "push = HEAD" config to the remote and then the
"git push" will only push the current branch (with the corresponding
matching remote branch).
$ git config remote.origin.push HEAD
Strictly speaking when you push (with the default config or with the
above trick) you push matching branches (it doesn't matter what is the
branch.<remote>.merge). Currently there is no way to say "push to the
corresponding tracking branch"
Still I think this will work as you want (as long as your local and
remote branch have the same name):
$ git clone $url
$ cd path
$ git config remote.origin.push HEAD
$ git checkout -b branch origin/branch
$ work, commit,...
$ git push
HTH,
Santi
From: Sam Vilain <hidden> Date: 2016-06-15 22:45:33
On Thu, 2008-10-30 at 13:25 +0100, Andreas Ericsson wrote:
quoted
quoted
Ok, now I'm confused. The ONLY thing I want to prevent is the
"crossing of streams" issue. If I am on branch X and issue 'git
push', I want X, and ONLY X, to be pushed to the remote repository's X
branch --- I don't care if other branches are pushed to their
respective remote branches, as long as they don't get merged to X.
This particular bikeshed was painted a long time ago, with the consensus
going in favour of "git push" pushing all *matching* refspecs.
I realise that - I just found it interesting that there was a user who
explicitly expected this not to be the case.
Which I think is reasonable, because it's what 'git pull' does. I
myself have encountered many people who did not like the current default
behaviour. I think far from "bikeshedding" this is quite an important
part of the ui experience.
Sam.