From: Thomas Rast <hidden> Date: 2016-06-15 22:53:15
Jeremy Morton [off-list ref] writes:
I've noticed that the default behaviour of 'git push' is to push to
*all* branches that have a remote branch set up.
[...]
Wouldn't it be better for git's default push behaviour (at least with
the '--force' option) to be just to push to the current branch in the
current repo? To push to all branches you could have an
'--allbranches' option.
See push.default in git-config(1).
--
Thomas Rast
trast@{inf,student}.ethz.ch
From: Jeremy Morton <hidden> Date: 2016-06-15 22:53:15
Right, so I guess I'm saying that the default value for push.default
should be upstream instead of matching...
Best regards,
Jeremy Morton (Jez)
On Thu, Mar 8, 2012 at 10:11 AM, Thomas Rast [off-list ref] wrote:
Jeremy Morton [off-list ref] writes:
quoted
I've noticed that the default behaviour of 'git push' is to push to
*all* branches that have a remote branch set up.
[...]
quoted
Wouldn't it be better for git's default push behaviour (at least with
the '--force' option) to be just to push to the current branch in the
current repo? To push to all branches you could have an
'--allbranches' option.
See push.default in git-config(1).
--
Thomas Rast
trast@{inf,student}.ethz.ch
From: Carlos Martín Nieto <hidden> Date: 2016-06-15 22:53:15
On Thu, 2012-03-08 at 10:13 +0000, Jeremy Morton wrote:
Right, so I guess I'm saying that the default value for push.default
should be upstream instead of matching...
Any default is going to leave some people unhappy. If upstream is the
right thing for you, then that's what you should use. Most questions I
see about push not doing what the users expect would actually benefit
from 'current'. 'matching' is a fairly safe default, as it won't try to
push private branches or changes in private branches that track
something upstream.
cmn
From: Jeremy Morton <hidden> Date: 2016-06-15 22:53:15
But 'push --force' WILL try to push your (probably outdated) master
upstream, killing any changes there made since you last updated. That
alone is so dangerous it seems like reason enough to avoid it by
default.
Best regards,
Jeremy Morton (Jez)
On Thu, Mar 8, 2012 at 10:28 AM, Carlos Martín Nieto [off-list ref] wrote:
On Thu, 2012-03-08 at 10:13 +0000, Jeremy Morton wrote:
quoted
Right, so I guess I'm saying that the default value for push.default
should be upstream instead of matching...
Any default is going to leave some people unhappy. If upstream is the
right thing for you, then that's what you should use. Most questions I
see about push not doing what the users expect would actually benefit
from 'current'. 'matching' is a fairly safe default, as it won't try to
push private branches or changes in private branches that track
something upstream.
cmn
From: Carlos Martín Nieto <hidden> Date: 2016-06-15 22:53:15
On Thu, 2012-03-08 at 10:38 +0000, Jeremy Morton wrote:
But 'push --force' WILL try to push your (probably outdated) master
upstream, killing any changes there made since you last updated. That
alone is so dangerous it seems like reason enough to avoid it by
default.
Then don't use --force without specifying exactly what you want.
Anything with that option needs to be used carefully.
cmn
From: Jeremy Morton <hidden> Date: 2016-06-15 22:53:15
Obviously - but my point is that it needn't be so dangerous by
default. It tries to push all matching branches - is that really a
more common requirement than pushing the current branch?
Best regards,
Jeremy Morton (Jez)
On Thu, Mar 8, 2012 at 10:42 AM, Carlos Martín Nieto [off-list ref] wrote:
On Thu, 2012-03-08 at 10:38 +0000, Jeremy Morton wrote:
quoted
But 'push --force' WILL try to push your (probably outdated) master
upstream, killing any changes there made since you last updated. That
alone is so dangerous it seems like reason enough to avoid it by
default.
Then don't use --force without specifying exactly what you want.
Anything with that option needs to be used carefully.
cmn
From: Jakub Narebski <hidden> Date: 2016-06-15 22:53:15
Jeremy Morton [off-list ref] writes:
On Thu, Mar 8, 2012 at 10:28 AM, Carlos Martín Nieto [off-list ref] wrote:
quoted
On Thu, 2012-03-08 at 10:13 +0000, Jeremy Morton wrote:
quoted
quoted
Right, so I guess I'm saying that the default value for push.default
should be upstream instead of matching...
Any default is going to leave some people unhappy. If upstream is the
right thing for you, then that's what you should use. Most questions I
see about push not doing what the users expect would actually benefit
from 'current'. 'matching' is a fairly safe default, as it won't try to
push private branches or changes in private branches that track
something upstream.
But 'push --force' WILL try to push your (probably outdated) master
upstream, killing any changes there made since you last updated. That
alone is so dangerous it seems like reason enough to avoid it by
default.
You can always configure server to refuse forced pushes.
--
Jakub Narebski
From: Marc Branchaud <hidden> Date: 2016-06-15 22:53:15
On 12-03-08 05:42 AM, Carlos Martín Nieto wrote:
On Thu, 2012-03-08 at 10:38 +0000, Jeremy Morton wrote:
quoted
But 'push --force' WILL try to push your (probably outdated) master
upstream, killing any changes there made since you last updated. That
alone is so dangerous it seems like reason enough to avoid it by
default.
Then don't use --force without specifying exactly what you want.
Anything with that option needs to be used carefully.
I agree with Jeremy that the default is dangerous, or at the very least
surprising.
Perhaps --force should be changed to require an explicit ref if
push.default = matching (and the code finds that it needs to use
push.default's value)?
By itself that change would make it impossible to use --force to
force-change all matching refs (i.e. the current default behaviour would
disappear completely). I'm OK with that, personally.
M.
On Thu, Mar 8, 2012 at 7:00 PM, Marc Branchaud [off-list ref] wrote:
Perhaps --force should be changed to require an explicit ref if push.default
= matching (and the code finds that it needs to use push.default's value)?
No, it will workflow for some people. In general, --force should not be
used, but when it is used, it is used for a reason. If you need another
behavior like forcing only the current branch then you probably should add
--force-current or something like that, but not to break what works now.
Dmitry
From: Jakub Narebski <hidden> Date: 2016-06-15 22:53:17
On Thu, 8 Mar 2012, Jeremy Morton wrote:
On Thu, Mar 8, 2012 at 11:33 AM, Jakub Narebski [off-list ref] wrote:
quoted
You can always configure server to refuse forced pushes.
We're using github, and as far as I'm aware, there's no way to
configure github to do that.
It would be nice if GitHub supported setting receive.denyNonFastForward
and receive.denyDeletes (the receive.*current* do not matter for GitHub).
Though I am not sure if it would not require changes to the custom Git
implementation they use...
--
Jakub Narebski
Poland
From: Jeremy Morton <hidden> Date: 2016-06-15 22:53:18
Would that deny non fast-forwards for all branches, though, or just
selected ones? We'd like to just to it for 2 of our branches. We'd
also like to explitly ALLOW fast-forwards to master, when we want to
merge in from develop to master.
A better description of what we want is to prevent 'rewriting of
history' for some of our branches.
Best regards,
Jeremy Morton (Jez)
On Tue, Mar 13, 2012 at 4:27 PM, Jakub Narebski [off-list ref] wrote:
On Thu, 8 Mar 2012, Jeremy Morton wrote:
quoted
On Thu, Mar 8, 2012 at 11:33 AM, Jakub Narebski [off-list ref] wrote:
quoted
quoted
You can always configure server to refuse forced pushes.
We're using github, and as far as I'm aware, there's no way to
configure github to do that.
It would be nice if GitHub supported setting receive.denyNonFastForward
and receive.denyDeletes (the receive.*current* do not matter for GitHub).
Though I am not sure if it would not require changes to the custom Git
implementation they use...
--
Jakub Narebski
Poland
From: Jakub Narebski <hidden> Date: 2016-06-15 22:53:18
Could you please do not top-post? TIA.
Jeremy Morton wrote:
On Tue, Mar 13, 2012 at 4:27 PM, Jakub Narebski [off-list ref] wrote:
quoted
On Thu, 8 Mar 2012, Jeremy Morton wrote:
quoted
On Thu, Mar 8, 2012 at 11:33 AM, Jakub Narebski [off-list ref] wrote:
quoted
quoted
You can always configure server to refuse forced pushes.
We're using github, and as far as I'm aware, there's no way to
configure github to do that.
It would be nice if GitHub supported setting receive.denyNonFastForward
and receive.denyDeletes (the receive.*current* do not matter for GitHub).
Though I am not sure if it would not require changes to the custom Git
implementation they use...
Would that deny non fast-forwards for all branches, though, or just
selected ones? We'd like to just to it for 2 of our branches. We'd
also like to explitly ALLOW fast-forwards to master, when we want to
merge in from develop to master.
No, receive.denyNonFastForward is for all branches only. If you want
per-branch access control, try gitolite... again not available on GitHub
(unless GitHub allows custom hooks).
A better description of what we want is to prevent 'rewriting of
history' for some of our branches.
From: Miles Bader <hidden> Date: 2016-06-15 22:53:20
Jeremy Morton [off-list ref] writes:
Obviously - but my point is that it needn't be so dangerous by
default. It tries to push all matching branches - is that really a
more common requirement than pushing the current branch?
It isn't "so dangerous" by default -- you have to specify --force to
enter "danger" territory, and --force is very clearly a dangerous
option that needs to be approached carefully (someone who uses --force
blindly is going to quickly screw themselves regardless of the
defaults).
-miles
--
Zeal, n. A certain nervous disorder afflicting the young and inexperienced.
From: Philippe Vaucher <hidden> Date: 2016-06-15 22:53:20
FWIW I also think we'd change the default to "upstream". The problem
with this default is that most repos only have one branch (master) and
thus they never run into this problem, so most people don't get the
habit to modify push.default AND they get the (bad) habit of typing
"git push". Then they work with multiple branches and get unexpected
pushes (with or without --force, especially when sausage making).
I know it's "their" fault for not learning more about git push's
defaults, but the current default is clearly against the principle of
least surprise IMHO.
Philippe