John Tapsell [off-list ref] writes:
2009/2/25 Junio C Hamano [off-list ref]:
quoted
Having an easy way to ask to push only one branch (typically the currently
checked-out one) is a good thing. You can obviously say "git push origin
master" (or whatever branch you are on). We also added "git push origin
HEAD". I thought we even added "git push HEAD" or "git push --current",
but I may be mistaken.
But if you are talking about changing the default when "git push" is run
without any parameter, I have to say it is a terrible idea, for two
reasons, and one is too obvious to state so I wouldn't repeat it and talk
only about the other one.
Presumably the obvious is that it might be confusing to existing
users? Perhaps, but it doesn't cause any damage. It's moving to a
'safer' default.
No, it is not merely confusing but is outright dangerous to people who
expect the "matching refs" behaviour. It is not safer at all.
For example, I almost always have some topic branch checked out and
working on changes that are still not in any of my integration branches.
The workflow is to first finish topics to satisfaction, merge the ones
that are ready into their respective integration branches, and in other
work trees (created by contrib/workdir/git-new-workdir) run the whole
build and test cycle for them in the background. While waiting for them
to build and verified, the repository I primarily work in will have a
checkout of some other uncooked topic branch that I have no intention to
push out yet because I am still working on it. After a while, the
background build and test will complete and all integration branches prove
themselves to be ready to be pushed out, and I can say "git push", fully
expecting that the "matching refs" behaviour will push out the integration
branches and nothing else, because they are the only ones I have on the
public side for people (either git or day-job) to look at. I would never
want "push current branch" to send the uncooked topic branch, which I
would never want to have on the other side even if it is fully cooked.
Even when I am on 'master', when I push things out, I do not want to hear
from people that I have been forgetting to push out integration branches
other than 'master' only because you suddenly changed the default under
me after a few days.
Please don't talk about changing the default without thinking the
ramifications through.
quoted
I've noticed that people who ask for such a default tend to push too often
and worse they tend to push before they have their act together. Surely
their other branches may not be ready, but it is likely their current
branch isn't either ;-)
You're against making push affect only the current branch in order to
punish people who push too often? Okaaay..
"Too often" is not a problem by itself per-se, but "still broken"
certainly is, and "not thought through" also is to a certain degree. You
often see people commit and push out an early part of a series, and then
later regret that they realize the approach in these initial segment does
not pan out and another avenue was much better, but it is too late to take
them back and rebase.
And there unfortunately is a correlation between "too often" and the other
two. Not very strong correlation with "still broken", but moderately
strong correlation with "not thought through".
And this is not about punishing. It is about getting into a different
mindset. Unlike CVS/SVN, committing and publishing can be made into
different phases with git, and not pushing too early allows you produce a
lot better results. "I want to push only this branch" is often (not
always, but "often" stands with strong correlation) a sign that other
things are not ready, and by definition you couldn't have thought through
interactions between what you _think_ is ready (i.e. the current branch)
and the other ones that are not ready. In other words, it is about
encouraging people to think things through before publishing.
quoted
If you shoot for the least damage for such people, the sanest default for
"git push" would be to do nothing. You *always* say what to push where,
then there is no risk of pushing something you did not intend to. Perhaps
"push.default = never" configuration may not be such a bad idea?
That wouldn't be a terrible idea, although perhaps a bit strange.
I would say that is the sanest default, and I often wish people in the git
training industry never teach "git push" without $remote and $refs
parameter to new people until they understand what they are doing.
You can add words other than 'never' to the repertoire, such as 'current',
or 'matching'. I think the configuration actually should be
"remote.<name>.push", not "push.default", though.
Oh, and the value 'current' can be spelled as 'HEAD' already there.
On Tue, Feb 24, 2009 at 11:44:44PM -0800, Junio C Hamano wrote:
quoted
Presumably the obvious is that it might be confusing to existing
users? Perhaps, but it doesn't cause any damage. It's moving to a
'safer' default.
No, it is not merely confusing but is outright dangerous to people who
expect the "matching refs" behaviour. It is not safer at all.
I think this is a very good reason not to change the default "push"
behavior.
And this is not about punishing. It is about getting into a different
mindset. Unlike CVS/SVN, committing and publishing can be made into
different phases with git, and not pushing too early allows you produce a
lot better results. "I want to push only this branch" is often (not
always, but "often" stands with strong correlation) a sign that other
things are not ready, and by definition you couldn't have thought through
interactions between what you _think_ is ready (i.e. the current branch)
and the other ones that are not ready. In other words, it is about
encouraging people to think things through before publishing.
But I don't buy this at all. It is totally dependent on workflow and how
you use branches. That is, the "readiness" of two branches may be
totally unrelated. One may be a short-term branch for today's work, and
the other may be a long-running branch that you have made a WIP commit
on. You may even have that WIP commit sitting there for days.
When you think about "is my current branch ready to push?" there is no
reason for you to think of that other long-running branch that you
haven't seen for days.
-Peff
2009/2/25 Junio C Hamano [off-list ref]:
John Tapsell [off-list ref] writes:
quoted
2009/2/25 Junio C Hamano [off-list ref]:
quoted
Having an easy way to ask to push only one branch (typically the currently
checked-out one) is a good thing. You can obviously say "git push origin
master" (or whatever branch you are on). We also added "git push origin
HEAD". I thought we even added "git push HEAD" or "git push --current",
but I may be mistaken.
But if you are talking about changing the default when "git push" is run
without any parameter, I have to say it is a terrible idea, for two
reasons, and one is too obvious to state so I wouldn't repeat it and talk
only about the other one.
Presumably the obvious is that it might be confusing to existing
users? Perhaps, but it doesn't cause any damage. It's moving to a
'safer' default.
No, it is not merely confusing but is outright dangerous to people who
expect the "matching refs" behaviour. It is not safer at all.
I see your point - perhaps "git push" should push the current branch
if the branch name matches the remote name (so if the current 'git
push' would have pushed it). Otherwise tell the user how to force it
to push.
Please don't talk about changing the default without thinking the
ramifications through.
Talking about doesn't harm anything. I don't really get why you're a
bit hostile.
quoted
quoted
I've noticed that people who ask for such a default tend to push too often
and worse they tend to push before they have their act together. Surely
their other branches may not be ready, but it is likely their current
branch isn't either ;-)
You're against making push affect only the current branch in order to
punish people who push too often? Okaaay..
"Too often" is not a problem by itself per-se, but "still broken"
certainly is, and "not thought through" also is to a certain degree. You
often see people commit and push out an early part of a series, and then
later regret that they realize the approach in these initial segment does
not pan out and another avenue was much better, but it is too late to take
them back and rebase.
And there unfortunately is a correlation between "too often" and the other
two. Not very strong correlation with "still broken", but moderately
strong correlation with "not thought through".
And this is not about punishing. It is about getting into a different
mindset. Unlike CVS/SVN, committing and publishing can be made into
different phases with git, and not pushing too early allows you produce a
lot better results. "I want to push only this branch" is often (not
always, but "often" stands with strong correlation) a sign that other
things are not ready, and by definition you couldn't have thought through
interactions between what you _think_ is ready (i.e. the current branch)
and the other ones that are not ready. In other words, it is about
encouraging people to think things through before publishing.
I'm a bit surprised that you always push all your branches at once. I
often have several branches checked out at different stages of
development. Perhaps working on a branch, then I find a serious bug,
so I switch to master and fix the bug there. I have never wanted to
push multiple branches at once.
quoted
quoted
If you shoot for the least damage for such people, the sanest default for
"git push" would be to do nothing. You *always* say what to push where,
then there is no risk of pushing something you did not intend to. Perhaps
"push.default = never" configuration may not be such a bad idea?
That wouldn't be a terrible idea, although perhaps a bit strange.
I would say that is the sanest default, and I often wish people in the git
training industry never teach "git push" without $remote and $refs
parameter to new people until they understand what they are doing.
You can add words other than 'never' to the repertoire, such as 'current',
or 'matching'. I think the configuration actually should be
"remote.<name>.push", not "push.default", though.
Oh, and the value 'current' can be spelled as 'HEAD' already there.
On Wed, Feb 25, 2009 at 2:44 AM, Junio C Hamano [off-list ref] wrote:
Oh, and the value 'current' can be spelled as 'HEAD' already there.
John - in case you missed this, the behavior you desire is already available:
(next)$ git config remote.origin.push HEAD
(next)$ git remote show origin
[...]
Local ref configured for 'git push':
HEAD pushes to next (fast forwardable)
(next)$ git checkout master
(master)$ git remote show origin
[...]
Local ref configured for 'git push':
HEAD pushes to master (fast forwardable)
j.