From: Samuel Tardieu <hidden> Date: 2016-06-15 22:45:33
quoted
quoted
quoted
quoted
"Andreas" == Andreas Ericsson [off-list ref] 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/
From: Andreas Ericsson <hidden> Date: 2016-06-15 22:45:33
Samuel Tardieu wrote:
quoted
quoted
quoted
quoted
quoted
"Andreas" == Andreas Ericsson [off-list ref] 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
From: Samuel Tardieu <hidden> Date: 2016-06-15 22:45:33
* Andreas Ericsson [off-list ref] [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".
quoted
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.
From: Pierre Habouzit <hidden> Date: 2016-06-15 22:45:33
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
From: Andreas Ericsson <hidden> Date: 2016-06-15 22:45:33
Samuel Tardieu wrote:
* Andreas Ericsson [off-list ref] [2008-10-30 15:06:16 +0100]
quoted
--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".
quoted
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
From: Samuel Tardieu <hidden> Date: 2016-06-15 22:45:33
* Pierre Habouzit [off-list ref] [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
From: Samuel Tardieu <hidden> Date: 2016-06-15 22:45:33
* Andreas Ericsson [off-list ref] [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.
From: Andreas Ericsson <hidden> Date: 2016-06-15 22:45:33
Samuel Tardieu wrote:
* Andreas Ericsson [off-list ref] [2008-10-30 15:54:53 +0100]
quoted
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.
quoted
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)
quoted
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
From: Bill Lear <hidden> Date: 2016-06-15 22:45:33
On Thursday, October 30, 2008 at 16:25:50 (+0100) Andreas Ericsson writes:
Samuel Tardieu wrote:
quoted
* Andreas Ericsson [off-list ref] [2008-10-30 15:54:53 +0100]
quoted
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:
...
quoted
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
From: Sam Vilain <hidden> Date: 2016-06-15 22:45:33
On Thu, 2008-10-30 at 15:54 +0100, Andreas Ericsson wrote:
quoted
I am curious of what other people workflows are. Do you often push
multiple branches at the same time?
Quite often, yes.
quoted
More often than one at a time?
No.
quoted
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.
From: Sam Vilain <hidden> Date: 2016-06-15 22:45:33
On Thu, 2008-10-30 at 15:56 +0100, Samuel Tardieu wrote:
* Pierre Habouzit [off-list ref] [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)
From: Marc Branchaud <hidden> Date: 2016-06-15 22:45:33
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
From: Jakub Narebski <hidden> Date: 2016-06-15 22:45:33
[Cc: Samuel Tardieu [off-list ref], Andreas Ericsson [off-list ref],
git@vger.kernel.org]
Samuel Tardieu wrote:
* Andreas Ericsson [off-list ref] [2008-10-30 15:06:16 +0100]
quoted
--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".
quoted
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
From: Jeff King <hidden> Date: 2016-06-15 22:45:34
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