Using the --track option when creating a branch

Using the --track option when creating a branch

[Bill Lear]

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

Re: Using the --track option when creating a branch

[Santi Béjar]

On Wed, Oct 29, 2008 at 4:23 PM, Bill Lear <rael@zopyra.com> 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)?

See above.

>
> We are using git 1.6.* versions here, mostly.
>

Santi

Re: Using the --track option when creating a branch

[Bill Lear]

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 <rael@zopyra.com> 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)

Ah, problem solved then.  I'll just have everyone upgrade to the
latest git.  Thanks very much, Santi.


Bill

Re: Using the --track option when creating a branch

[Sam Vilain]

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

Re: Using the --track option when creating a branch

[Bill Lear]

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:
>> 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

Re: Using the --track option when creating a branch

[Bill Lear]

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:
>>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.
>
>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

Re: Using the --track option when creating a branch

[Andreas Ericsson]

Bill Lear wrote:
> 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:
>>> 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.
>> 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

Re: Using the --track option when creating a branch

[Santi Béjar]

On Thu, Oct 30, 2008 at 1:04 PM, Bill Lear <rael@zopyra.com> wrote:
> 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:
>>> 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

Re: Using the --track option when creating a branch

[Samuel Tardieu]

>>>>> "Andreas" == Andreas Ericsson <ae@op5.se> writes:

Andreas> This particular bikeshed was painted a long time ago, with
Andreas> the consensus going in favour of "git push" pushing all
Andreas> *matching* refspecs.

I still don't understand why this is useful, especially when git push
already has a "--all" option.

I know that I've never had the intent to push all the refs without
thinking about it first. Most of the time, I intend to push only
the current branch I am in.

The current behaviour made me remove the branches I was not actively
on locally, because I would get errors from "git push" all the time
saying that I was not up-to-date in those branches.

Note that the "git pull" issue is completely different, as it merges
or fast forwards the current branch only.

  Sam
-- 
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/

Re: Using the --track option when creating a branch

[Andreas Ericsson]

Samuel Tardieu wrote:
>>>>>> "Andreas" == Andreas Ericsson <ae@op5.se> writes:
> 
> Andreas> This particular bikeshed was painted a long time ago, with
> Andreas> the consensus going in favour of "git push" pushing all
> Andreas> *matching* refspecs.
> 
> I still don't understand why this is useful, especially when git push
> already has a "--all" option.
> 

--all pushes all refs, even the non-matching ones, which is very
rarely desirable and only accidentally sometimes the same as "push all
matching refs".

> I know that I've never had the intent to push all the refs without
> thinking about it first. Most of the time, I intend to push only
> the current branch I am in.
> 

Then say so. There's a very simple command syntax for it:
"git push <remote> <current-branch>"

> The current behaviour made me remove the branches I was not actively
> on locally, because I would get errors from "git push" all the time
> saying that I was not up-to-date in those branches.
> 

That's an orthogonal issue, and one that really could be fixed without
anyone complaining. Send a patch that checks if foo is a strict subset
of <remote>/foo before trying to send it, and abort if it is so. This
means that we'll try to push "foo" if upstream rewrote their "foo", but
perhaps that's just as well.

Note though that the patch mustn't try to apply any smarts if a ref is
given explicitly.

> Note that the "git pull" issue is completely different, as it merges
> or fast forwards the current branch only.
> 

"git pull" is actually only vaguely connected with "git push". The
opposite of "push" is "fetch" in git lingo.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: Using the --track option when creating a branch

[Samuel Tardieu]

* Andreas Ericsson <ae@op5.se> [2008-10-30 15:06:16 +0100]

> --all pushes all refs, even the non-matching ones, which is very
> rarely desirable and only accidentally sometimes the same as "push all
> matching refs".
>
>> I know that I've never had the intent to push all the refs without
>> thinking about it first. Most of the time, I intend to push only
>> the current branch I am in.
>
> Then say so. There's a very simple command syntax for it:
> "git push <remote> <current-branch>"

I update the branches I'm working in maybe 20 times a day, sometimes
more. When I make a change and all the tests pass, I prefer to call

  git push

rather than

  git push origin 2.0-beta1

(and "2.0-beta1" is a short name here, some branches have much longer
names)

I think it would be better to have :

  git push                <= push the current branch
  git push --all          <= push all matching refs
  git push --all --create <= push all matching refs, create if needed

The latest command is probably used so rarely (compared to the others)
that it wouldn't be a problem to make it longer. Of course, if a
refspec is given explicitely, it should be honored and remote refs
created if needed.

I am curious of what other people workflows are. Do you often push
multiple branches at the same time? More often than one at a time?
Many times a day?

> "git pull" is actually only vaguely connected with "git push". The
> opposite of "push" is "fetch" in git lingo.

I know, but "git fetch" only updates remote tracking branches, and I
think that in the majority of the cases you want to advance all the
remote references. And even if you screw up, the problem will only
happen in your local copy, not in an upstream or shared repository.
I assume that most people "push" to public repositories and not
many of them "pull" into public repositories directly.

Re: Using the --track option when creating a branch

[Pierre Habouzit]

[-- Attachment #1: Type: text/plain, Size: 961 bytes --]

On Thu, Oct 30, 2008 at 02:23:16PM +0000, Samuel Tardieu wrote:
> I think it would be better to have :
> 
>   git push                <= push the current branch
>   git push --all          <= push all matching refs
>   git push --all --create <= push all matching refs, create if needed
> 
> The latest command is probably used so rarely (compared to the others)
> that it wouldn't be a problem to make it longer. Of course, if a
> refspec is given explicitely, it should be honored and remote refs
> created if needed.

Fwiw I'm in favor of that, and it was what I advocated at the time.

Though I think than as soon as you add an explicit remote name, like:
git push origin, pushing all matched references makes sense. Which is
also what I advocated at the time.

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: Using the --track option when creating a branch

[Andreas Ericsson]

Samuel Tardieu wrote:
> * Andreas Ericsson <ae@op5.se> [2008-10-30 15:06:16 +0100]
> 
>> --all pushes all refs, even the non-matching ones, which is very
>> rarely desirable and only accidentally sometimes the same as "push all
>> matching refs".
>>
>>> I know that I've never had the intent to push all the refs without
>>> thinking about it first. Most of the time, I intend to push only
>>> the current branch I am in.
>> Then say so. There's a very simple command syntax for it:
>> "git push <remote> <current-branch>"
> 
> I update the branches I'm working in maybe 20 times a day, sometimes
> more. When I make a change and all the tests pass, I prefer to call
> 
>   git push
> 
> rather than
> 
>   git push origin 2.0-beta1
> 

So why don't you? Unless you also make lots of changes on other branches,
the two commands will result in exactly the same thing.

> (and "2.0-beta1" is a short name here, some branches have much longer
> names)
> 
> I think it would be better to have :
> 
>   git push                <= push the current branch
>   git push --all          <= push all matching refs
>   git push --all --create <= push all matching refs, create if needed
> 

Correct me if I'm wrong, but wouldn't my suggestion of not trying to
push (even matching) branches that haven't been updated since we last
fetched from the remote do exactly the same thing for your particular
use-case, but without syntax change and all the annoying minor parts
that it entails?


> The latest command is probably used so rarely (compared to the others)
> that it wouldn't be a problem to make it longer. Of course, if a
> refspec is given explicitely, it should be honored and remote refs
> created if needed.
> 
> I am curious of what other people workflows are. Do you often push
> multiple branches at the same time?

Quite often, yes.

> More often than one at a time?

No.

> Many times a day?
> 

Define "many". Perhaps as often as 2-3 times per day. Not very often,
but frequent enough that I definitely want some short sweet way of
doing it. OTOH, I also find the "rejected" messages annoying, and I
definitely feel one could do something about them. However, it's my
birthday today and I plan on being far too drunk/hungover the entire
weekend for me to take any actions in that direction.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: Using the --track option when creating a branch

[Samuel Tardieu]

* Pierre Habouzit <madcoder@debian.org> [2008-10-30 15:41:07 +0100]

| On Thu, Oct 30, 2008 at 02:23:16PM +0000, Samuel Tardieu wrote:
| > I think it would be better to have :
| > 
| >   git push                <= push the current branch
| >   git push --all          <= push all matching refs
| >   git push --all --create <= push all matching refs, create if needed
| > 
| > The latest command is probably used so rarely (compared to the others)
| > that it wouldn't be a problem to make it longer. Of course, if a
| > refspec is given explicitely, it should be honored and remote refs
| > created if needed.
| 
| Fwiw I'm in favor of that, and it was what I advocated at the time.
| 
| Though I think than as soon as you add an explicit remote name, like:
| git push origin, pushing all matched references makes sense. Which is
| also what I advocated at the time.

Indeed, it makes sense. We could then have:

  git push                 <= push the current branch on default remote
                              (which is, at least in my case, the most
                               frequent use I want to make of "git push",
                               on all the projects [work or volunteer]
                               I work on)
  git push remote          <= push all matching refs on named remote
  git push --all [remote]  <= push and create all refs on remote (or default)

 Sam

Re: Using the --track option when creating a branch

[Samuel Tardieu]

* Andreas Ericsson <ae@op5.se> [2008-10-30 15:54:53 +0100]

> Correct me if I'm wrong, but wouldn't my suggestion of not trying to
> push (even matching) branches that haven't been updated since we last
> fetched from the remote do exactly the same thing for your particular
> use-case, but without syntax change and all the annoying minor parts
> that it entails?

Not exactly. I often do some work on a branch which does not mandate
a topic branch and have to switch branches to fix a bug for example.
This would continue to push unterminated changes as well.

Typical use case, which happens (to me) quite frequently:

  % git checkout master
  [start new feature, estimated implementation time 15 minutes]
  % git commit -m "Reorganize foobar in previous of xyzzy."
    (note that I'm not sure that I will keep it, I'll know that later
    when my next commit is ready, maybe in 10 minutes, no need for
    a topic branch)
  [mail from a customer, "I noticed some strange behaviour here" --
   let's fix it]
  % git checkout 2.0-beta1-release-candidate
  [fix strange behaviour and add new test]
  [test locally]
  % git commit -m "Fix strange behaviour baz."
  % git push
    (so that it goes to the buildfarm for QA testing)

Argh, "master" has been pushed as well. Ok, I could have done

  % git branch
    (because I know I am on the right branch but do not necessarily
     remember its full name all the time)
  % git push origin 2.0-beta1-release-candidate

or I could have started a topic branch, but I often push 2 or 3
commits at a time instead, the first one being a refactoring of
existing code to ease the subsequent one.

>From what I have seen, people I am working with often have the
same workflow (do not systematically start a topic branch when
in active development mode)

> Define "many". Perhaps as often as 2-3 times per day. Not very often,
> but frequent enough that I definitely want some short sweet way of
> doing it. OTOH, I also find the "rejected" messages annoying, and I
> definitely feel one could do something about them. However, it's my
> birthday today and I plan on being far too drunk/hungover the entire
> weekend for me to take any actions in that direction.

Happy birthday :)

Re: Using the --track option when creating a branch

[Andreas Ericsson]

Samuel Tardieu wrote:
> * Andreas Ericsson <ae@op5.se> [2008-10-30 15:54:53 +0100]
> 
>> Correct me if I'm wrong, but wouldn't my suggestion of not trying to
>> push (even matching) branches that haven't been updated since we last
>> fetched from the remote do exactly the same thing for your particular
>> use-case, but without syntax change and all the annoying minor parts
>> that it entails?
> 
> Not exactly. I often do some work on a branch which does not mandate
> a topic branch and have to switch branches to fix a bug for example.
> This would continue to push unterminated changes as well.
> 
> Typical use case, which happens (to me) quite frequently:
> 

...

>
> Argh, "master" has been pushed as well. Ok, I could have done
> 

Ah, I see. I sympathize, although I really do think you'd be
better off by learning to explicitly push things.

>   % git branch
>     (because I know I am on the right branch but do not necessarily
>      remember its full name all the time)

offtopic: Use shell-completion and set your PS1 to include the __git_ps1
output.

>   % git push origin 2.0-beta1-release-candidate
> 
> or I could have started a topic branch, but I often push 2 or 3
> commits at a time instead, the first one being a refactoring of
> existing code to ease the subsequent one.
> 

I fail to see why this would prevent you from starting a topic-branch.
In fact, I would have thought it was a reason *for* starting a topic.

>>From what I have seen, people I am working with often have the
> same workflow (do not systematically start a topic branch when
> in active development mode)
> 
>> Define "many". Perhaps as often as 2-3 times per day. Not very often,
>> but frequent enough that I definitely want some short sweet way of
>> doing it. OTOH, I also find the "rejected" messages annoying, and I
>> definitely feel one could do something about them. However, it's my
>> birthday today and I plan on being far too drunk/hungover the entire
>> weekend for me to take any actions in that direction.
> 
> Happy birthday :)
> 

Thank you :-)

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: Using the --track option when creating a branch

[Bill Lear]

On Thursday, October 30, 2008 at 16:25:50 (+0100) Andreas Ericsson writes:
>Samuel Tardieu wrote:
>> * Andreas Ericsson <ae@op5.se> [2008-10-30 15:54:53 +0100]
>> 
>>> Correct me if I'm wrong, but wouldn't my suggestion of not trying to
>>> push (even matching) branches that haven't been updated since we last
>>> fetched from the remote do exactly the same thing for your particular
>>> use-case, but without syntax change and all the annoying minor parts
>>> that it entails?
>> 
>> Not exactly. I often do some work on a branch which does not mandate
>> a topic branch and have to switch branches to fix a bug for example.
>> This would continue to push unterminated changes as well.
>> 
>> Typical use case, which happens (to me) quite frequently:
>> 
>
>...
>
>>
>> Argh, "master" has been pushed as well. Ok, I could have done
>> 
>
>Ah, I see. I sympathize, although I really do think you'd be
>better off by learning to explicitly push things.

Exactly my concerns when I raised this issue originally.  It's hard to
teach people to do this:

% git push origin master

or:

% git pull origin master

so that when they intend and MUST do this (lest chaos ensue):

% git push origin ReleaseBranch

or this:

% git pull origin ReleaseBranch

they don't mistakenly do this:

% git push

or:

% git pull

the reason being that every manual our users read says "use git push",
use "git pull", the examples being written for 'master' branch usage,
and people just assume that 'git push'/'git pull' are smart enough to
know which branch you are on and do the same logical thing as a bare
'git push'/'git pull' does when on master.

Several times this has happened to us: people make this mistake and
push or pull stuff into a branch they do not want.  The pull is not so
bad, but the push messes up our central repo.  This has happened both
here at my current company, and my previous one, and the persons
making the mistakes are neither sloppy nor inexperienced.


Bill

Re: Using the --track option when creating a branch

[Sam Vilain]

On Thu, 2008-10-30 at 13:25 +0100, Andreas Ericsson wrote:
> >> 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.

Re: Using the --track option when creating a branch

[Sam Vilain]

On Thu, 2008-10-30 at 15:54 +0100, Andreas Ericsson wrote:
> > I am curious of what other people workflows are. Do you often push
> > multiple branches at the same time?
> 
> Quite often, yes.
> 
> > More often than one at a time?
> 
> No.
> 
> > Many times a day?
> > 
> 
> Define "many". Perhaps as often as 2-3 times per day. Not very often,
> but frequent enough that I definitely want some short sweet way of
> doing it.

I think your use case is the unusual one, not the common one.  Most
users will want the moral equivalent of "push = HEAD" by default, and
those who prefer the existing behaviour can configure it.

Sam.

Re: Using the --track option when creating a branch

[Sam Vilain]

On Thu, 2008-10-30 at 15:56 +0100, Samuel Tardieu wrote:
> * Pierre Habouzit <madcoder@debian.org> [2008-10-30 15:41:07 +0100]
> 
> | On Thu, Oct 30, 2008 at 02:23:16PM +0000, Samuel Tardieu wrote:
> | > I think it would be better to have :
> | > 
> | >   git push                <= push the current branch
> | >   git push --all          <= push all matching refs
> | >   git push --all --create <= push all matching refs, create if needed
> | > 
> | > The latest command is probably used so rarely (compared to the others)
> | > that it wouldn't be a problem to make it longer. Of course, if a
> | > refspec is given explicitely, it should be honored and remote refs
> | > created if needed.
> | 
> | Fwiw I'm in favor of that, and it was what I advocated at the time.
> | 
> | Though I think than as soon as you add an explicit remote name, like:
> | git push origin, pushing all matched references makes sense. Which is
> | also what I advocated at the time.
> 
> Indeed, it makes sense. We could then have:
> 
>   git push                 <= push the current branch on default remote
>                               (which is, at least in my case, the most
>                                frequent use I want to make of "git push",
>                                on all the projects [work or volunteer]
>                                I work on)


>   git push remote          <= push all matching refs on named remote

I think that 'git push origin' should be the same as 'git push'; so,
'git push remote' would then just push the current head to the tracking
branch of that remote.  This exposes another issue with the current
method of configuring the tracking branch, which is that only one remote
and branch may be configured for each local branch.  In reality, someone
might be pushing and pulling from multiple remotes; expecting them to
keep naming the current branch all the time seems arduous. 

I think if you want matching refs to be pushed, say so:

  git push remote --matching

>   git push --all [remote]  <= push and create all refs on remote (or default)

Re: Using the --track option when creating a branch

[Marc Branchaud]

Bill Lear wrote:
> 
> the reason being that every manual our users read says "use git push",
> use "git pull", the examples being written for 'master' branch usage,
> and people just assume that 'git push'/'git pull' are smart enough to
> know which branch you are on and do the same logical thing as a bare
> 'git push'/'git pull' does when on master.

I agree that this is a 'gotcha' for git-push.  I'm a new git user, and 
I've been experimenting with git and reading the documentation for the 
last few weeks.  But I would not have known about this behavior if it 
weren't for this thread.

Yes, push's man page is clear about what happens if you push with no 
refspec, and the fetch & pull man pages both have an obscure note to 
"never do your own development on branches that appear
on the right hand side of a <refspec> colon on 'Pull:' lines".  But 
still the behavior is not what I expected.  Before I read this thread, I 
missed the implications of what those parts of the man pages were saying.

One could call this a failure of the documentation (man pages and 
beyond).  Personally, though, I tend to expect minimal commands to do 
minimal things.  So a plain "git push" would do the minimum amount of 
pushing, and if I want it to do more I'd add extra parameters to the 
command.

The current behavior seems fairly harmless if you always follow the 
pattern of creating topic branches for all your work.  But git (rightly) 
doesn't enforce that pattern, and so I think push shouldn't default to 
doing something potentially harmful just because you forgot to create a 
topic branch one day.  (Or maybe you decided to be clever and give one 
of your local branches the same name as a remote's branch...)

		Marc

Re: Using the --track option when creating a branch

[Jakub Narebski]

[Cc: Samuel Tardieu <sam@rfc1149.net>, Andreas Ericsson <ae@op5.se>,
     git@vger.kernel.org]

Samuel Tardieu wrote:
> * Andreas Ericsson <ae@op5.se> [2008-10-30 15:06:16 +0100]
> 
>> --all pushes all refs, even the non-matching ones, which is very
>> rarely desirable and only accidentally sometimes the same as "push all
>> matching refs".
>>
>>> I know that I've never had the intent to push all the refs without
>>> thinking about it first. Most of the time, I intend to push only
>>> the current branch I am in.
>>
>> Then say so. There's a very simple command syntax for it:
>> "git push <remote> <current-branch>"
> 
> I update the branches I'm working in maybe 20 times a day, sometimes
> more. When I make a change and all the tests pass, I prefer to call
> 
>   git push
> 
> rather than
> 
>   git push origin 2.0-beta1
> 
> (and "2.0-beta1" is a short name here, some branches have much longer
> names)

You can use

  $ git push origin HEAD

and I think (but I am not sure) that there is DWIM-mery allowing
to simply say

  $ git push HEAD

and it would use configured branch.$(git symbolic-ref HEAD).remote


And if it is not as I said, the patches would better made it so, instead of
changing default behavior from push matching refspecs to push current
branch only.
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: Using the --track option when creating a branch

[Jeff King]

On Thu, Oct 30, 2008 at 02:52:52PM +0100, Samuel Tardieu wrote:

> The current behaviour made me remove the branches I was not actively
> on locally, because I would get errors from "git push" all the time
> saying that I was not up-to-date in those branches.

Not triggering an error on these branches has been discussed a few times
before, but I'm not sure we ever reached a conclusion of what the ideal
behavior would be.

Try this thread:

  http://thread.gmane.org/gmane.comp.version-control.git/85469

which points to a few others. Comments welcome.

-Peff