* git push default behaviour? @ 2012-03-08 10:01 Jeremy Morton 2012-03-08 10:11 ` Thomas Rast 2012-03-17 9:36 ` Sebastien Douche 0 siblings, 2 replies; 116+ messages in thread From: Jeremy Morton @ 2012-03-08 10:01 UTC (permalink / raw) To: git Hi everyone, I've noticed that the default behaviour of 'git push' is to push to *all* branches that have a remote branch set up. In order to push just to one branch, you must specify 'git push repo branchname'. This seems rather unintuative to me, and in the case of a '--force', almost certainly not what you want. You're usually working on one branch and just want to push that one, and it's usually the branch you're currently on. And in the case of a '--force', in addition by pushing all branches to remote, you are going to undo any changes on other branches made since you updated them on your local repo. 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. Best regards, Jeremy Morton (Jez) ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: git push default behaviour? 2012-03-08 10:01 git push default behaviour? Jeremy Morton @ 2012-03-08 10:11 ` Thomas Rast 2012-03-08 10:13 ` Jeremy Morton 2012-03-17 9:36 ` Sebastien Douche 1 sibling, 1 reply; 116+ messages in thread From: Thomas Rast @ 2012-03-08 10:11 UTC (permalink / raw) To: Jeremy Morton; +Cc: git Jeremy Morton <jeremy@configit.com> 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 ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: git push default behaviour? 2012-03-08 10:11 ` Thomas Rast @ 2012-03-08 10:13 ` Jeremy Morton 2012-03-08 10:28 ` Carlos Martín Nieto 0 siblings, 1 reply; 116+ messages in thread From: Jeremy Morton @ 2012-03-08 10:13 UTC (permalink / raw) To: Thomas Rast; +Cc: git 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 <trast@inf.ethz.ch> wrote: > Jeremy Morton <jeremy@configit.com> 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 ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: git push default behaviour? 2012-03-08 10:13 ` Jeremy Morton @ 2012-03-08 10:28 ` Carlos Martín Nieto 2012-03-08 10:38 ` Jeremy Morton 2012-03-08 11:54 ` Matthieu Moy 0 siblings, 2 replies; 116+ messages in thread From: Carlos Martín Nieto @ 2012-03-08 10:28 UTC (permalink / raw) To: Jeremy Morton; +Cc: Thomas Rast, git [-- Attachment #1: Type: text/plain, Size: 563 bytes --] 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 [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 490 bytes --] ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: git push default behaviour? 2012-03-08 10:28 ` Carlos Martín Nieto @ 2012-03-08 10:38 ` Jeremy Morton 2012-03-08 10:42 ` Carlos Martín Nieto 2012-03-08 11:33 ` Jakub Narebski 2012-03-08 11:54 ` Matthieu Moy 1 sibling, 2 replies; 116+ messages in thread From: Jeremy Morton @ 2012-03-08 10:38 UTC (permalink / raw) To: Carlos Martín Nieto; +Cc: Thomas Rast, git 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 <cmn@elego.de> wrote: > 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 > > ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: git push default behaviour? 2012-03-08 10:38 ` Jeremy Morton @ 2012-03-08 10:42 ` Carlos Martín Nieto 2012-03-08 10:43 ` Jeremy Morton 2012-03-08 15:00 ` Marc Branchaud 2012-03-08 11:33 ` Jakub Narebski 1 sibling, 2 replies; 116+ messages in thread From: Carlos Martín Nieto @ 2012-03-08 10:42 UTC (permalink / raw) To: Jeremy Morton; +Cc: Thomas Rast, git 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 ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: git push default behaviour? 2012-03-08 10:42 ` Carlos Martín Nieto @ 2012-03-08 10:43 ` Jeremy Morton 2012-03-08 18:22 ` Junio C Hamano 2012-03-19 6:02 ` Miles Bader 2012-03-08 15:00 ` Marc Branchaud 1 sibling, 2 replies; 116+ messages in thread From: Jeremy Morton @ 2012-03-08 10:43 UTC (permalink / raw) To: Carlos Martín Nieto; +Cc: Thomas Rast, git 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 <cmn@elego.de> wrote: > 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 > > ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: git push default behaviour? 2012-03-08 10:43 ` Jeremy Morton @ 2012-03-08 18:22 ` Junio C Hamano 2012-03-08 18:35 ` Matthieu Moy 2012-03-19 6:02 ` Miles Bader 1 sibling, 1 reply; 116+ messages in thread From: Junio C Hamano @ 2012-03-08 18:22 UTC (permalink / raw) To: Jeremy Morton; +Cc: Carlos Martín Nieto, Thomas Rast, git Jeremy Morton <jeremy@configit.com> 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? Depends on the way you work. If you publish to your own repository and let others pull, the behaviour is not dangerous at all with or without --force (well, --force brings its own danger but that does not have anything to do with which branches are pushed). If you default to 'current' in such a workflow, you risk forgetting to push, which is the more dangerous option between the two. When using a single shared central repository to work with others, current may be more appropriate, and that is why the behaviour is configurable. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: git push default behaviour? 2012-03-08 18:22 ` Junio C Hamano @ 2012-03-08 18:35 ` Matthieu Moy 2012-03-08 19:03 ` Andreas Krey 2012-03-08 19:29 ` Junio C Hamano 0 siblings, 2 replies; 116+ messages in thread From: Matthieu Moy @ 2012-03-08 18:35 UTC (permalink / raw) To: Junio C Hamano; +Cc: Jeremy Morton, Carlos Martín Nieto, Thomas Rast, git Junio C Hamano <gitster@pobox.com> writes: > If you publish to your own repository > and let others pull, the behaviour is not dangerous at all with or > without --force (well, --force brings its own danger but that does > not have anything to do with which branches are pushed). If you > default to 'current' in such a workflow, you risk forgetting to > push, which is the more dangerous option between the two. Forgetting to push a branch is a danger, but far less dangerous than what "push --force" can do in a shared repository. In a shared repository, there's actually a race condition that you cannot avoid AFAICT: $ git push # get an error about non-fast-forward on branch A, but no other. # thing "it's OK, I do want to do a forced update on A". $ git push --force If someone else did a push between my first push and the "push --force", then the other user's push is discarded. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: git push default behaviour? 2012-03-08 18:35 ` Matthieu Moy @ 2012-03-08 19:03 ` Andreas Krey 2012-03-08 19:29 ` Junio C Hamano 1 sibling, 0 replies; 116+ messages in thread From: Andreas Krey @ 2012-03-08 19:03 UTC (permalink / raw) To: Matthieu Moy Cc: Junio C Hamano, Jeremy Morton, Carlos Martín Nieto, Thomas Rast, git On Thu, 08 Mar 2012 19:35:51 +0000, Matthieu Moy wrote: ... > If someone else did a push between my first push and the "push --force", > then the other user's push is discarded. A push --semiforce would help here: Should check whether the remote branch is at the same commit as origin/master locally, and only then set to new local master. (Would probably require protocol change to actuall be atomic.) Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds <torvalds@*.org> Date: Fri, 22 Jan 2010 07:29:21 -0800 ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: git push default behaviour? 2012-03-08 18:35 ` Matthieu Moy 2012-03-08 19:03 ` Andreas Krey @ 2012-03-08 19:29 ` Junio C Hamano 2012-03-09 8:05 ` Matthieu Moy 1 sibling, 1 reply; 116+ messages in thread From: Junio C Hamano @ 2012-03-08 19:29 UTC (permalink / raw) To: Matthieu Moy; +Cc: Jeremy Morton, Carlos Martín Nieto, Thomas Rast, git Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes: > Junio C Hamano <gitster@pobox.com> writes: > >> If you publish to your own repository >> and let others pull, the behaviour is not dangerous at all with or >> without --force (well, --force brings its own danger but that does >> not have anything to do with which branches are pushed). If you >> default to 'current' in such a workflow, you risk forgetting to >> push, which is the more dangerous option between the two. > > Forgetting to push a branch is a danger, but far less dangerous than > what "push --force" can do in a shared repository. > > In a shared repository, there's actually a race condition that you > cannot avoid AFAICT: > ... > If someone else did a push between my first push and the "push --force", > then the other user's push is discarded. That is exactly what I said in the parentheses above, isn't it? The danger of "--force" does not have anything to do with which branches are pushed. It comes primarily from the use of shared repository. The first advice Carlos gave us in this thread, which was perfectly sane, applies to your observation: before you "push --force", think twice. That does not change the conclusion that current is more suitable for shared repository workflow and matching is more (not "equally to current") suitable for publishing repository workflow, and we have a way for user to tell Git which one is being used in a particular project exactly for that purpose. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: git push default behaviour? 2012-03-08 19:29 ` Junio C Hamano @ 2012-03-09 8:05 ` Matthieu Moy 2012-03-09 9:50 ` Junio C Hamano 0 siblings, 1 reply; 116+ messages in thread From: Matthieu Moy @ 2012-03-09 8:05 UTC (permalink / raw) To: Junio C Hamano; +Cc: Jeremy Morton, Carlos Martín Nieto, Thomas Rast, git Junio C Hamano <gitster@pobox.com> writes: > That is exactly what I said in the parentheses above, isn't it? The > danger of "--force" does not have anything to do with which branches > are pushed. I disagree. A user may use --force because he has good reason to think that a branch hasn't been been touched by others, but it's much harder to guarantee that all branches haven't been touched. > That does not change the conclusion that current is more suitable > for shared repository workflow and matching is more (not "equally to > current") suitable for publishing repository workflow, and we have a > way for user to tell Git which one is being used in a particular > project exactly for that purpose. We're not talking about the same thing. You're talking about how _appropriate_ a value is, and I'm mentionning how _dangerous_ it can be. And regardless of the danger, if I look around me, I see almost only people working with shared archives, and a few projects (including Git, obviously) using the "one commiter per repository" workflow (I teach Git to 200 students and several colleagues every year, I've tried teaching the "one public repository per developer" and it was a complete disaster). I really think the default should help these people. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: git push default behaviour? 2012-03-09 8:05 ` Matthieu Moy @ 2012-03-09 9:50 ` Junio C Hamano 2012-03-09 11:28 ` Jeremy Morton ` (2 more replies) 0 siblings, 3 replies; 116+ messages in thread From: Junio C Hamano @ 2012-03-09 9:50 UTC (permalink / raw) To: Matthieu Moy; +Cc: Jeremy Morton, Carlos Martín Nieto, Thomas Rast, git Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes: > And regardless of the danger, if I look around me, I see almost only > people working with shared archives, and a few projects (including Git, > obviously) using the "one commiter per repository" workflow (I teach Git These days, you do not have to even go to kernel.org to find people and projects that use "publish to be pulled" model. I hear that there is a popular site called GitHub where people create their own fork, publish their work there and ask the project they forked from to pull their work. By the way, don't we ask the workflow used by the users in the annual user survey? > to 200 students and several colleagues every year, I've tried teaching > the "one public repository per developer" and it was a complete disaster). Interesting. I have a couple of questions. Who are these 200 people and what do they do with Git? If the answer is "They work on a class assignment project, 20 teams of 10 members each", I would count that as a datapoint that represents one project among thousands of projects that use Git. I am also curious to learn a bit more about "a complete disaster", even though this question (and its answer) would not be directly relevant to this topic, as nobody is trying to convert projects to use the "publish to be pulled" model when the "push to the shared central repository" model is more appropriate for them. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: git push default behaviour? 2012-03-09 9:50 ` Junio C Hamano @ 2012-03-09 11:28 ` Jeremy Morton 2012-03-09 11:54 ` Matthieu Moy 2012-03-09 14:42 ` Jakub Narebski 2 siblings, 0 replies; 116+ messages in thread From: Jeremy Morton @ 2012-03-09 11:28 UTC (permalink / raw) To: Junio C Hamano; +Cc: Matthieu Moy, Carlos Martín Nieto, Thomas Rast, git On Fri, Mar 9, 2012 at 9:50 AM, Junio C Hamano <gitster@pobox.com> wrote: > Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes: > >> And regardless of the danger, if I look around me, I see almost only >> people working with shared archives, and a few projects (including Git, >> obviously) using the "one commiter per repository" workflow (I teach Git > > These days, you do not have to even go to kernel.org to find people > and projects that use "publish to be pulled" model. I hear that > there is a popular site called GitHub where people create their own > fork, publish their work there and ask the project they forked from > to pull their work. Github also offer a paid service where you can host private repositories, which you're probably going to work on as part of a team in a business. FWIW, I discovered the problem with this default behaviour because someone accidentally did a 'git push --force' to our github repo. There is currently no hook mechanism with github that allows you to abort a push, either, so you can't stop the problem that way. Best regards, Jeremy Morton (Jez) ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: git push default behaviour? 2012-03-09 9:50 ` Junio C Hamano 2012-03-09 11:28 ` Jeremy Morton @ 2012-03-09 11:54 ` Matthieu Moy 2012-03-09 14:42 ` Jakub Narebski 2 siblings, 0 replies; 116+ messages in thread From: Matthieu Moy @ 2012-03-09 11:54 UTC (permalink / raw) To: Junio C Hamano; +Cc: Jeremy Morton, Carlos Martín Nieto, Thomas Rast, git Junio C Hamano <gitster@pobox.com> writes: >> to 200 students and several colleagues every year, I've tried teaching >> the "one public repository per developer" and it was a complete disaster). > > Interesting. I have a couple of questions. > > Who are these 200 people and what do they do with Git? If the > answer is "They work on a class assignment project, 20 teams of 10 > members each", Teams are smaller, but that's essentially that, yes. I'm not saying it's representative, my point just that I do have experience teaching Git to new users. > I am also curious to learn a bit more about "a complete disaster", There are several points: * It is often the case that one of the member of a team is more knowledgeable than others. Then, this user can set up a shared archive, and other users do not have to. When your project is open-source, it's rather easy to click GitHub's web interface and create a fork, but when it's a private project (and you don't want to pay), you have to do some kind of magic with ACLs or so to create a new repository. Doing this magic just once saves a lot of trouble. In practice, when working with colleagues (all being computer scientists), if I don't set up a shared repository, they just send me their files (yes, their files, not their patches :-( ) by email and ask me to do merges if needed. * Users like to know where "the latest version" is. They are already confused by the fact that the last local revision may not be the same as the last remote one, and having multiple public repositories adds to the confusion. > even though this question (and its answer) would not be directly > relevant to this topic, as nobody is trying to convert projects to > use the "publish to be pulled" model when the "push to the shared > central repository" model is more appropriate for them. Sure. I'm not saying in any way that the "shared repository" is superior. Just that it's easier to grab for newbies. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: git push default behaviour? 2012-03-09 9:50 ` Junio C Hamano 2012-03-09 11:28 ` Jeremy Morton 2012-03-09 11:54 ` Matthieu Moy @ 2012-03-09 14:42 ` Jakub Narebski 2 siblings, 0 replies; 116+ messages in thread From: Jakub Narebski @ 2012-03-09 14:42 UTC (permalink / raw) To: Junio C Hamano Cc: Matthieu Moy, Jeremy Morton, Carlos Martín Nieto, Thomas Rast, git [I'm sorry if you received duplicate] Nb. instead of using `--force` to force push of all relevant branches, you can always force push of single branch with `+branch`... Junio C Hamano <gitster@pobox.com> writes: > Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes: > > > And regardless of the danger, if I look around me, I see almost only > > people working with shared archives, and a few projects (including Git, > > obviously) using the "one commiter per repository" workflow (I teach Git > > These days, you do not have to even go to kernel.org to find people > and projects that use "publish to be pulled" model. I hear that > there is a popular site called GitHub where people create their own > fork, publish their work there and ask the project they forked from > to pull their work. > > By the way, don't we ask the workflow used by the users in the > annual user survey? There is "23) How do you publish/propagate your changes?"[1] but it doesn't tell if responder was using shared repository approach, or one fork per person approach. This would be a good question to ask in this year, I think... [1]: https://www.survs.com/results/Q5CA9SKQ/P7DE07F0PL -- Jakub Narebski ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: git push default behaviour? 2012-03-08 10:43 ` Jeremy Morton 2012-03-08 18:22 ` Junio C Hamano @ 2012-03-19 6:02 ` Miles Bader 2012-03-19 16:12 ` Philippe Vaucher 1 sibling, 1 reply; 116+ messages in thread From: Miles Bader @ 2012-03-19 6:02 UTC (permalink / raw) To: Jeremy Morton; +Cc: Carlos Martín Nieto, Thomas Rast, git Jeremy Morton <jeremy@configit.com> 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. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: git push default behaviour? 2012-03-19 6:02 ` Miles Bader @ 2012-03-19 16:12 ` Philippe Vaucher 0 siblings, 0 replies; 116+ messages in thread From: Philippe Vaucher @ 2012-03-19 16:12 UTC (permalink / raw) To: Miles Bader; +Cc: Jeremy Morton, Carlos Martín Nieto, Thomas Rast, git 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 ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: git push default behaviour? 2012-03-08 10:42 ` Carlos Martín Nieto 2012-03-08 10:43 ` Jeremy Morton @ 2012-03-08 15:00 ` Marc Branchaud 2012-03-08 15:26 ` Matthieu Moy 2012-03-08 17:37 ` Dmitry Potapov 1 sibling, 2 replies; 116+ messages in thread From: Marc Branchaud @ 2012-03-08 15:00 UTC (permalink / raw) To: Carlos Martín Nieto; +Cc: Jeremy Morton, Thomas Rast, git On 12-03-08 05:42 AM, Carlos Martín Nieto wrote: > 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. 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. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: git push default behaviour? 2012-03-08 15:00 ` Marc Branchaud @ 2012-03-08 15:26 ` Matthieu Moy 2012-03-08 17:49 ` Dmitry Potapov 2012-03-08 17:37 ` Dmitry Potapov 1 sibling, 1 reply; 116+ messages in thread From: Matthieu Moy @ 2012-03-08 15:26 UTC (permalink / raw) To: Marc Branchaud; +Cc: Carlos Martín Nieto, Jeremy Morton, Thomas Rast, git Marc Branchaud <marcnarc@xiplink.com> writes: > I agree with Jeremy that the default is dangerous, or at the very > least surprising. Yes, --force is not the only problem. Getting constant non-fast forward errors just because you have out-of-date local ref is annoying, and really, really confusing. 'push.default = matching' is never a good idea if you use shared repository actually. It makes sense for people like Junio pushing a local repository to a public one, which is read-only for the rest of the world. But my experience is that people using such workflow are advanced users, and would know how to configure Git, so it wouldn't really harm them to change the default. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: git push default behaviour? 2012-03-08 15:26 ` Matthieu Moy @ 2012-03-08 17:49 ` Dmitry Potapov 2012-03-08 18:04 ` Matthieu Moy 0 siblings, 1 reply; 116+ messages in thread From: Dmitry Potapov @ 2012-03-08 17:49 UTC (permalink / raw) To: Matthieu Moy Cc: Marc Branchaud, Carlos Martín Nieto, Jeremy Morton, Thomas Rast, git On Thu, Mar 8, 2012 at 7:26 PM, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote: > > 'push.default = matching' is never a good idea if you use shared > repository actually. It makes sense for people like Junio pushing a > local repository to a public one, which is read-only for the rest of the > world. But my experience is that people using such workflow are advanced > users, and would know how to configure Git, so it wouldn't really harm > them to change the default. There are more people that you think who rely on the current behavior of git push. For instance, pushing changes between different computers for testing purposes before publishing them. When you silently change the default value of push, you silently break their workflow. It is not difficult to add 'push.default = matching' but you need to know that the default value has changed, so you have to add this line to preserve the old behavior. Dmitry ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: git push default behaviour? 2012-03-08 17:49 ` Dmitry Potapov @ 2012-03-08 18:04 ` Matthieu Moy 2012-03-09 3:38 ` Jeff King 0 siblings, 1 reply; 116+ messages in thread From: Matthieu Moy @ 2012-03-08 18:04 UTC (permalink / raw) To: Dmitry Potapov Cc: Marc Branchaud, Carlos Martín Nieto, Jeremy Morton, Thomas Rast, git Dmitry Potapov <dpotapov@gmail.com> writes: > When you silently change > the default value of push, you silently break their workflow. No one talked about changing it silently. Quoting myself: | it needs to be done with a sane migration path, however There is already a configuration variable, so it's easy to fix a default value change if you rely on it, but the first thing to do is to encourage people to explicitely set push.default, so that they are not affected by a potential future default change. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: git push default behaviour? 2012-03-08 18:04 ` Matthieu Moy @ 2012-03-09 3:38 ` Jeff King 2012-03-09 5:23 ` Junio C Hamano 0 siblings, 1 reply; 116+ messages in thread From: Jeff King @ 2012-03-09 3:38 UTC (permalink / raw) To: Matthieu Moy Cc: Dmitry Potapov, Marc Branchaud, Carlos Martín Nieto, Jeremy Morton, Thomas Rast, git On Thu, Mar 08, 2012 at 07:04:25PM +0100, Matthieu Moy wrote: > Dmitry Potapov <dpotapov@gmail.com> writes: > > > When you silently change > > the default value of push, you silently break their workflow. > > No one talked about changing it silently. Quoting myself: > > | it needs to be done with a sane migration path, however > > There is already a configuration variable, so it's easy to fix a default > value change if you rely on it, but the first thing to do is to > encourage people to explicitely set push.default, so that they are not > affected by a potential future default change. This is all sounding eerily familiar. Indeed: $ git log --oneline -Swarn_unconfigured_push -- builtin-push.c bba0fd2 push: do not give big warning when no preference is configured 665d3e8 Display warning for default git push with no push.default config I don't remember the mailing list conversations that surrounded those patches, but if we are going to have the same conversation again, maybe it is worth looking them up. -Peff ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: git push default behaviour? 2012-03-09 3:38 ` Jeff King @ 2012-03-09 5:23 ` Junio C Hamano 2012-03-09 5:38 ` Junio C Hamano 2012-03-09 8:25 ` Matthieu Moy 0 siblings, 2 replies; 116+ messages in thread From: Junio C Hamano @ 2012-03-09 5:23 UTC (permalink / raw) To: Jeff King Cc: Matthieu Moy, Dmitry Potapov, Marc Branchaud, Carlos Martín Nieto, Jeremy Morton, Thomas Rast, git Jeff King <peff@peff.net> writes: > This is all sounding eerily familiar. Indeed: > > $ git log --oneline -Swarn_unconfigured_push -- builtin-push.c > bba0fd2 push: do not give big warning when no preference is configured > 665d3e8 Display warning for default git push with no push.default config > > I don't remember the mailing list conversations that surrounded those > patches, but if we are going to have the same conversation again, maybe > it is worth looking them up. I just dug it up; start from here: http://thread.gmane.org/gmane.comp.version-control.git/123350/focus=123541 read on a few messages downthread, and then jump to the other thread Nana points at in the above message. In short, we started warning that we _might_ change the default someday, without having a clear concensus or plan, that ended up confusing and annoying users without giving them anything good, other than awareness that such a feature is _available_. So no, the conversation did not decide if changing the default was warranted or not. It just confirmed that we weren't anywhere close to deciding back then. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: git push default behaviour? 2012-03-09 5:23 ` Junio C Hamano @ 2012-03-09 5:38 ` Junio C Hamano 2012-03-09 8:06 ` demerphq 2012-03-09 8:25 ` Matthieu Moy 1 sibling, 1 reply; 116+ messages in thread From: Junio C Hamano @ 2012-03-09 5:38 UTC (permalink / raw) To: Jeff King Cc: Matthieu Moy, Dmitry Potapov, Marc Branchaud, Carlos Martín Nieto, Jeremy Morton, Thomas Rast, git Junio C Hamano <gitster@pobox.com> writes: > I just dug it up; start from here: > > http://thread.gmane.org/gmane.comp.version-control.git/123350/focus=123541 > > read on a few messages downthread, and then jump to the other thread > Nana points at in the above message. > > In short, we started warning that we _might_ change the default > someday, without having a clear concensus or plan, that ended up > confusing and annoying users without giving them anything good, > other than awareness that such a feature is _available_. > > So no, the conversation did not decide if changing the default was > warranted or not. It just confirmed that we weren't anywhere close > to deciding back then. I think MJG's message (the second on in the "git push origin error" thread) is probably what we would need to repeat, and this time more strongly to squelch the opposition from old timers, if somebody wants to resurrect the "warn until you set the default explicitly, intending to change the default in the future" patch. And this time around, the plan to change the default should be more concrete with specific date, e.g. "Starting from April 1st, 2013". I was in the "keep the default to matching, so that nobody among existing 47 million users would be annoyed" camp (back then we probably didn't have 47 million users, but that is besides the point) and I still am, but notice that I was defending the argument by the "let's be ( (new user) friendly )" camp in that thread. And without much fire-support from those who were vocal about it. Re-reading the thread made me sick. I wish I had enough energy remaining to say "Let's try one more time, and hope that people from the 'let's change the default' camp will behave much better than the last time", but I do not have high hopes, after having been burned once already with exactly the same issue. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: git push default behaviour? 2012-03-09 5:38 ` Junio C Hamano @ 2012-03-09 8:06 ` demerphq 2012-03-09 8:48 ` Thomas Rast 0 siblings, 1 reply; 116+ messages in thread From: demerphq @ 2012-03-09 8:06 UTC (permalink / raw) To: Junio C Hamano Cc: Jeff King, Matthieu Moy, Dmitry Potapov, Marc Branchaud, Carlos Martín Nieto, Jeremy Morton, Thomas Rast, git On 9 March 2012 06:38, Junio C Hamano <gitster@pobox.com> wrote: > Junio C Hamano <gitster@pobox.com> writes: > >> I just dug it up; start from here: >> >> http://thread.gmane.org/gmane.comp.version-control.git/123350/focus=123541 >> >> read on a few messages downthread, and then jump to the other thread >> Nana points at in the above message. >> >> In short, we started warning that we _might_ change the default >> someday, without having a clear concensus or plan, that ended up >> confusing and annoying users without giving them anything good, >> other than awareness that such a feature is _available_. >> >> So no, the conversation did not decide if changing the default was >> warranted or not. It just confirmed that we weren't anywhere close >> to deciding back then. > > I think MJG's message (the second on in the "git push origin error" > thread) is probably what we would need to repeat, and this time more > strongly to squelch the opposition from old timers, if somebody > wants to resurrect the "warn until you set the default explicitly, > intending to change the default in the future" patch. And this time > around, the plan to change the default should be more concrete with > specific date, e.g. "Starting from April 1st, 2013". > > I was in the "keep the default to matching, so that nobody among > existing 47 million users would be annoyed" camp (back then we > probably didn't have 47 million users, but that is besides the > point) and I still am, but notice that I was defending the argument > by the "let's be ( (new user) friendly )" camp in that thread. And > without much fire-support from those who were vocal about it. > > Re-reading the thread made me sick. > > I wish I had enough energy remaining to say "Let's try one more > time, and hope that people from the 'let's change the default' camp > will behave much better than the last time", but I do not have high > hopes, after having been burned once already with exactly the same > issue. I think I read all the relevant mails, and I have a thought concerning what I see to be the class of the problem here: the general question of "how do you change default behavior if it turns out that the original choice was inappropriate". It seems to me you can think of solutions to that problem in general without considering the subject of this thread. A possible solution might be to give config files a "format version" of their own. They already contain a repository format version number, so add a new variable "ConfigVersionLevel". Alongside that you might introduce a policy of having new git "fill in" the defaults missing from the config file whenever it operates, so that people can explicitly view then all at once. Then if the defaults change in the future an old repo will continue to work as it did before. This alone would allow you to change the defaults for existing configurable behavior, but you need the version number to handle new options. Once you have that you can change the default behavior based on the version level so that older users operating in older repositories get the old behavior, and new repositories get the new behavior. And you have more flexibility in how your approach these problems when they come up, and it seems to me that they are inevitable. Cheers, Yves -- perl -Mre=debug -e "/just|another|perl|hacker/" ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: git push default behaviour? 2012-03-09 8:06 ` demerphq @ 2012-03-09 8:48 ` Thomas Rast 2012-03-09 9:50 ` Junio C Hamano 2012-03-16 9:38 ` Gelonida N 0 siblings, 2 replies; 116+ messages in thread From: Thomas Rast @ 2012-03-09 8:48 UTC (permalink / raw) To: demerphq Cc: Junio C Hamano, Jeff King, Matthieu Moy, Dmitry Potapov, Marc Branchaud, Carlos Martín Nieto, Jeremy Morton, git demerphq <demerphq@gmail.com> writes: > A possible solution might be to give config files a "format version" > of their own. They already contain a repository format version number, > so add a new variable "ConfigVersionLevel". Alongside that you might > introduce a policy of having new git "fill in" the defaults missing > from the config file whenever it operates, so that people can > explicitly view then all at once. Then if the defaults change in the > future an old repo will continue to work as it did before. This alone > would allow you to change the defaults for existing configurable > behavior, but you need the version number to handle new options. > > Once you have that you can change the default behavior based on the > version level so that older users operating in older repositories get > the old behavior, and new repositories get the new behavior. And you > have more flexibility in how your approach these problems when they > come up, and it seems to me that they are inevitable. This would be a brilliant way to confuse the hell out of existing users: suddenly the apparent "defaults"[1] now change *between repositories* depending on when they were created. In short, oh please god no. [1] using the word loosely here, for anything that the user has not configured manually with git-config, git-remote, git branch --set-upstream etc. -- Thomas Rast trast@{inf,student}.ethz.ch ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: git push default behaviour? 2012-03-09 8:48 ` Thomas Rast @ 2012-03-09 9:50 ` Junio C Hamano 2012-03-16 9:38 ` Gelonida N 1 sibling, 0 replies; 116+ messages in thread From: Junio C Hamano @ 2012-03-09 9:50 UTC (permalink / raw) To: Thomas Rast Cc: demerphq, Jeff King, Matthieu Moy, Dmitry Potapov, Marc Branchaud, Carlos Martín Nieto, Jeremy Morton, git Thomas Rast <trast@inf.ethz.ch> writes: > This would be a brilliant way to confuse the hell out of existing users: > suddenly the apparent "defaults"[1] now change *between repositories* > depending on when they were created. > > In short, oh please god no. Amen ;-) ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: git push default behaviour? 2012-03-09 8:48 ` Thomas Rast 2012-03-09 9:50 ` Junio C Hamano @ 2012-03-16 9:38 ` Gelonida N 1 sibling, 0 replies; 116+ messages in thread From: Gelonida N @ 2012-03-16 9:38 UTC (permalink / raw) To: git On 03/09/2012 09:48 AM, Thomas Rast wrote: > demerphq <demerphq@gmail.com> writes: > >> A possible solution might be to give config files a "format version" >> of their own. They already contain a repository format version number, >> so add a new variable "ConfigVersionLevel". Alongside that you might >> introduce a policy of having new git "fill in" the defaults missing >> from the config file whenever it operates, so that people can >> explicitly view then all at once. Then if the defaults change in the >> future an old repo will continue to work as it did before. This alone >> would allow you to change the defaults for existing configurable >> behavior, but you need the version number to handle new options. >> >> Once you have that you can change the default behavior based on the >> version level so that older users operating in older repositories get >> the old behavior, and new repositories get the new behavior. And you >> have more flexibility in how your approach these problems when they >> come up, and it seems to me that they are inevitable. > > This would be a brilliant way to confuse the hell out of existing users: > suddenly the apparent "defaults"[1] now change *between repositories* > depending on when they were created. > > In short, oh please god no. If config file version changes would occur rarely, then this idea dsoesn't sound that bad to me. git could even ask whether it should upgrade (explicitely insert the old default value if not existing and if different in the new release) the config file version whenver it encounters an old version. By this means old projects wouldn't be broken whenever a default value would be changed and all rconfig files would upgrade to the same version. Even older versions of git would still work with these upgraded config files ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: git push default behaviour? 2012-03-09 5:23 ` Junio C Hamano 2012-03-09 5:38 ` Junio C Hamano @ 2012-03-09 8:25 ` Matthieu Moy 2012-03-09 8:31 ` [RFC PATCH] push: start warning upcoming default change for push.default Matthieu Moy 2012-03-09 9:57 ` git push default behaviour? Junio C Hamano 1 sibling, 2 replies; 116+ messages in thread From: Matthieu Moy @ 2012-03-09 8:25 UTC (permalink / raw) To: Junio C Hamano Cc: Jeff King, Dmitry Potapov, Marc Branchaud, Carlos Martín Nieto, Jeremy Morton, Thomas Rast, git Junio C Hamano <gitster@pobox.com> writes: > I just dug it up; start from here: > > http://thread.gmane.org/gmane.comp.version-control.git/123350/focus=123541 That's an old discussion. A more recent one is here: http://thread.gmane.org/gmane.comp.version-control.git/166743 (interleaved with a discussion about tag namespace, but the end of the message is about push.default) In this discussion, you (Junio) proposed a patch and argued exactly in the direction I do right now. I think the discussion stopped here: http://thread.gmane.org/gmane.comp.version-control.git/166743 (i.e. "Care to roll an appliable patch?", which I guess everyone has been too lazy to do) Patch follows. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ ^ permalink raw reply [flat|nested] 116+ messages in thread
* [RFC PATCH] push: start warning upcoming default change for push.default 2012-03-09 8:25 ` Matthieu Moy @ 2012-03-09 8:31 ` Matthieu Moy 2012-03-09 10:01 ` Junio C Hamano ` (4 more replies) 2012-03-09 9:57 ` git push default behaviour? Junio C Hamano 1 sibling, 5 replies; 116+ messages in thread From: Matthieu Moy @ 2012-03-09 8:31 UTC (permalink / raw) To: git, gitster; +Cc: Matthieu Moy More inexperienced users will often push right after committing, and at that time they're still very much in the "working-on-one-branch" state of mind. "upstream" would be a safer default mode of operation for 'git push' for them even when they have their personal publishing repository (also in a shared public repository settings, "matching" is rarely the right default mode). In preparation for flipping the default to the "upstream" mode from the "matching" mode that is the upstream default, start warning users when they rely on unconfigured "git push" to default to the "matching" mode. Original patch and commit message by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> --- This patch prepares a transition to 'upstream', unlike the previous version which was advertizing 'current'. In most case, this would be the same, but 'upstream' is probably more sensible in case it points to a branch other than 'current'. I don't care much either way. I've kept the wording from the original patch, which commits to a future change. We may instead relax this commitment and just say "the default is likely to change in a future version", or so. builtin/push.c | 22 ++++++++++++++++++++++ cache.h | 1 + environment.c | 2 +- 3 files changed, 24 insertions(+), 1 deletion(-) diff --git a/builtin/push.c b/builtin/push.c index d315475..03545c0 100644 --- a/builtin/push.c +++ b/builtin/push.c @@ -91,10 +91,32 @@ static void setup_push_upstream(struct remote *remote) add_refspec(refspec.buf); } +static void warn_unspecified_push_default_configuration(void) +{ + static int warn_once; + + if (warn_once++) + return; + warning(_("push.default is unset; its implicit value is changing in 1.8.0 from\n" + "'matching' to 'upstream'. To squelch this message and maintain the current\n" + "behavior post-1.8.0, use:\n" + "\n" + " git config --global push.default matching\n" + "\n" + "To squelch this message and adopt the 1.8.0 behavior now, use:\n" + "\n" + " git config --global push.default upstream\n" + "\n" + "See 'git help config' and search for 'push.default' for further information.\n")); +} + static void setup_default_push_refspecs(struct remote *remote) { switch (push_default) { default: + case PUSH_DEFAULT_UNSPECIFIED: + warn_unspecified_push_default_configuration(); + /* fallthru */ case PUSH_DEFAULT_MATCHING: add_refspec(":"); break; diff --git a/cache.h b/cache.h index e12b15f..e5c3f26 100644 --- a/cache.h +++ b/cache.h @@ -622,6 +622,7 @@ enum rebase_setup_type { }; enum push_default_type { + PUSH_DEFAULT_UNSPECIFIED = -1, PUSH_DEFAULT_NOTHING = 0, PUSH_DEFAULT_MATCHING, PUSH_DEFAULT_UPSTREAM, diff --git a/environment.c b/environment.c index c93b8f4..d7e6c65 100644 --- a/environment.c +++ b/environment.c @@ -52,7 +52,7 @@ enum safe_crlf safe_crlf = SAFE_CRLF_WARN; unsigned whitespace_rule_cfg = WS_DEFAULT_RULE; enum branch_track git_branch_track = BRANCH_TRACK_REMOTE; enum rebase_setup_type autorebase = AUTOREBASE_NEVER; -enum push_default_type push_default = PUSH_DEFAULT_MATCHING; +enum push_default_type push_default = PUSH_DEFAULT_UNSPECIFIED; #ifndef OBJECT_CREATION_MODE #define OBJECT_CREATION_MODE OBJECT_CREATION_USES_HARDLINKS #endif -- 1.7.9.3.330.g598662 ^ permalink raw reply related [flat|nested] 116+ messages in thread
* Re: [RFC PATCH] push: start warning upcoming default change for push.default 2012-03-09 8:31 ` [RFC PATCH] push: start warning upcoming default change for push.default Matthieu Moy @ 2012-03-09 10:01 ` Junio C Hamano 2012-03-09 20:21 ` Junio C Hamano 2012-03-09 10:25 ` Carlos Martín Nieto ` (3 subsequent siblings) 4 siblings, 1 reply; 116+ messages in thread From: Junio C Hamano @ 2012-03-09 10:01 UTC (permalink / raw) To: Matthieu Moy; +Cc: git Matthieu Moy <Matthieu.Moy@imag.fr> writes: > This patch prepares a transition to 'upstream', unlike the previous > version which was advertizing 'current'. In most case, this would be > the same, but 'upstream' is probably more sensible in case it points > to a branch other than 'current'. I don't care much either way. I would agree with that choice (provided that we were to do this change). > I've kept the wording from the original patch, which commits to a > future change. We may instead relax this commitment and just say "the > default is likely to change in a future version", or so. Please no. Keep it _very_ firmly committed. Otherwise we didn't learn a thing from 1.6.3 era. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [RFC PATCH] push: start warning upcoming default change for push.default 2012-03-09 10:01 ` Junio C Hamano @ 2012-03-09 20:21 ` Junio C Hamano 0 siblings, 0 replies; 116+ messages in thread From: Junio C Hamano @ 2012-03-09 20:21 UTC (permalink / raw) To: Matthieu Moy Cc: git, Jeff King, Dmitry Potapov, Marc Branchaud, Carlos Martín Nieto, Jeremy Morton, Thomas Rast Junio C Hamano <gitster@pobox.com> writes: > Matthieu Moy <Matthieu.Moy@imag.fr> writes: > >> This patch prepares a transition to 'upstream', unlike the previous >> version which was advertizing 'current'. In most case, this would be >> the same, but 'upstream' is probably more sensible in case it points >> to a branch other than 'current'. I don't care much either way. > > I would agree with that choice (provided that we were to do this > change). > >> I've kept the wording from the original patch, which commits to a >> future change. We may instead relax this commitment and just say "the >> default is likely to change in a future version", or so. > > Please no. Keep it _very_ firmly committed. Otherwise we didn't > learn a thing from 1.6.3 era. The need for awareness building outside this mailing list remains, but the ball is in the court of "let's change the default" folks and I cannot do anything further on that front, so I'll focus on the patch itself in this message. The code seems quite competently done, except that the message text would want to live in a separate static array, if only to keep the lines in the patch not overly long. Also, The message taken from Jeff's $gmane/166787 may need to be tweaked further, waiting the conclusion of the discussion in the other subthread. Oh, another thing is that the "1.8.0" in Jeff's original was written back in 1.7.5 era. We would want to bump it to say "1.8" (or even "2.0"). Thanks. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [RFC PATCH] push: start warning upcoming default change for push.default 2012-03-09 8:31 ` [RFC PATCH] push: start warning upcoming default change for push.default Matthieu Moy 2012-03-09 10:01 ` Junio C Hamano @ 2012-03-09 10:25 ` Carlos Martín Nieto 2012-03-09 18:30 ` Marc Branchaud 2012-03-09 11:26 ` Ævar Arnfjörð Bjarmason ` (2 subsequent siblings) 4 siblings, 1 reply; 116+ messages in thread From: Carlos Martín Nieto @ 2012-03-09 10:25 UTC (permalink / raw) To: Matthieu Moy; +Cc: git, gitster [-- Attachment #1: Type: text/plain, Size: 4687 bytes --] On Fri, 2012-03-09 at 09:31 +0100, Matthieu Moy wrote: > More inexperienced users will often push right after committing, and at > that time they're still very much in the "working-on-one-branch" state of > mind. "upstream" would be a safer default mode of operation for 'git push' > for them even when they have their personal publishing repository (also in > a shared public repository settings, "matching" is rarely the right > default mode). > > In preparation for flipping the default to the "upstream" mode from the > "matching" mode that is the upstream default, start warning users when they > rely on unconfigured "git push" to default to the "matching" mode. > > Original patch and commit message by: Junio C Hamano <gitster@pobox.com> > > Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> > --- > > This patch prepares a transition to 'upstream', unlike the previous > version which was advertizing 'current'. In most case, this would be > the same, but 'upstream' is probably more sensible in case it points > to a branch other than 'current'. I don't care much either way. > For people using git as VCS that happens to have local history rather than taking full advantage of the distributed nature (or who aren't aware of it or don't get it), 'matching' is bound to be confusing. However, IMO 'current' makes more sense. Consider git clone ../foo; cd foo; git checkout -b topic origin/develop ed main.c git push With upstream I've just updated origin's dev branch, even though I might have meant to create a new 'topic' branch. Alternatively, I might have run git checkout -b topic in which case I certainly want 'current'. I don't see that workflow where the upstream branch is named differently from the local one should be that big a consideration when trying to determine a default to help people unfamiliar as they'd be certainly more likely to consider branch names to be binding. Maybe you have seen this differently in your students, but that's the impression I get from #git. They also seem to expect 'git pull' to be magic, but that's a different story. > I've kept the wording from the original patch, which commits to a > future change. We may instead relax this commitment and just say "the > default is likely to change in a future version", or so. > > builtin/push.c | 22 ++++++++++++++++++++++ > cache.h | 1 + > environment.c | 2 +- > 3 files changed, 24 insertions(+), 1 deletion(-) > > diff --git a/builtin/push.c b/builtin/push.c > index d315475..03545c0 100644 > --- a/builtin/push.c > +++ b/builtin/push.c > @@ -91,10 +91,32 @@ static void setup_push_upstream(struct remote *remote) > add_refspec(refspec.buf); > } > > +static void warn_unspecified_push_default_configuration(void) > +{ > + static int warn_once; > + > + if (warn_once++) > + return; > + warning(_("push.default is unset; its implicit value is changing in 1.8.0 from\n" > + "'matching' to 'upstream'. To squelch this message and maintain the current\n" > + "behavior post-1.8.0, use:\n" > + "\n" > + " git config --global push.default matching\n" > + "\n" > + "To squelch this message and adopt the 1.8.0 behavior now, use:\n" > + "\n" > + " git config --global push.default upstream\n" > + "\n" > + "See 'git help config' and search for 'push.default' for further information.\n")); > +} > + > static void setup_default_push_refspecs(struct remote *remote) > { > switch (push_default) { > default: > + case PUSH_DEFAULT_UNSPECIFIED: > + warn_unspecified_push_default_configuration(); > + /* fallthru */ > case PUSH_DEFAULT_MATCHING: > add_refspec(":"); > break; > diff --git a/cache.h b/cache.h > index e12b15f..e5c3f26 100644 > --- a/cache.h > +++ b/cache.h > @@ -622,6 +622,7 @@ enum rebase_setup_type { > }; > > enum push_default_type { > + PUSH_DEFAULT_UNSPECIFIED = -1, > PUSH_DEFAULT_NOTHING = 0, > PUSH_DEFAULT_MATCHING, > PUSH_DEFAULT_UPSTREAM, > diff --git a/environment.c b/environment.c > index c93b8f4..d7e6c65 100644 > --- a/environment.c > +++ b/environment.c > @@ -52,7 +52,7 @@ enum safe_crlf safe_crlf = SAFE_CRLF_WARN; > unsigned whitespace_rule_cfg = WS_DEFAULT_RULE; > enum branch_track git_branch_track = BRANCH_TRACK_REMOTE; > enum rebase_setup_type autorebase = AUTOREBASE_NEVER; > -enum push_default_type push_default = PUSH_DEFAULT_MATCHING; > +enum push_default_type push_default = PUSH_DEFAULT_UNSPECIFIED; > #ifndef OBJECT_CREATION_MODE > #define OBJECT_CREATION_MODE OBJECT_CREATION_USES_HARDLINKS > #endif [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 490 bytes --] ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [RFC PATCH] push: start warning upcoming default change for push.default 2012-03-09 10:25 ` Carlos Martín Nieto @ 2012-03-09 18:30 ` Marc Branchaud 2012-03-09 21:08 ` Stefan Haller 2012-03-10 6:16 ` Michael Haggerty 0 siblings, 2 replies; 116+ messages in thread From: Marc Branchaud @ 2012-03-09 18:30 UTC (permalink / raw) To: Carlos Martín Nieto; +Cc: Matthieu Moy, git, gitster On 12-03-09 05:25 AM, Carlos Martín Nieto wrote: > On Fri, 2012-03-09 at 09:31 +0100, Matthieu Moy wrote: >> More inexperienced users will often push right after committing, and at >> that time they're still very much in the "working-on-one-branch" state of >> mind. "upstream" would be a safer default mode of operation for 'git push' >> for them even when they have their personal publishing repository (also in >> a shared public repository settings, "matching" is rarely the right >> default mode). >> >> In preparation for flipping the default to the "upstream" mode from the >> "matching" mode that is the upstream default, start warning users when they >> rely on unconfigured "git push" to default to the "matching" mode. >> >> Original patch and commit message by: Junio C Hamano<gitster@pobox.com> >> >> Signed-off-by: Matthieu Moy<Matthieu.Moy@imag.fr> >> --- >> >> This patch prepares a transition to 'upstream', unlike the previous >> version which was advertizing 'current'. In most case, this would be >> the same, but 'upstream' is probably more sensible in case it points >> to a branch other than 'current'. I don't care much either way. >> > > For people using git as VCS that happens to have local history rather > than taking full advantage of the distributed nature (or who aren't > aware of it or don't get it), 'matching' is bound to be confusing. > However, IMO 'current' makes more sense. Consider > > git clone ../foo; cd foo; > git checkout -b topic origin/develop > ed main.c > git push > > With upstream I've just updated origin's dev branch, even though I might > have meant to create a new 'topic' branch. Alternatively, I might have > run > > git checkout -b topic > > in which case I certainly want 'current'. I don't see that workflow > where the upstream branch is named differently from the local one should > be that big a consideration when trying to determine a default to help > people unfamiliar as they'd be certainly more likely to consider branch > names to be binding. Maybe you have seen this differently in your > students, but that's the impression I get from #git. I disagree and consider "upstream" to be the more reasonable default. I think that an incantation like git checkout -b topic origin/master makes it pretty clear that topic is meant to be merged into origin's master branch. And so a simple "git push" as you describe I think *should* update origin's master branch. OTOH, with a default of "current" I believe the simple "git push" will create a new branch named topic in the origin repo. To me that's implying too much from the simple "git push" command. If the user really wants a branch named topic in the origin repo, I think it's reasonable for git's default behaviour to require the user to say so explicitly ("git push origin topic"). I also disagree that an incantation like git checkout -b topic means that the user wants "current" when they "git push". There's no indication here that the user is at all interested in remote branches with this topic, and I think it would be presumptuous for git to make such a link by default. (Besides, what if the user has more than one remote? Which should be used?) In this case the "upstream" default would mean that git couldn't identify a remote for the topic branch and so the "git push" would fail. I think that's appropriate, because the user never told git how the topic branch relates to any remote branches. M. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [RFC PATCH] push: start warning upcoming default change for push.default 2012-03-09 18:30 ` Marc Branchaud @ 2012-03-09 21:08 ` Stefan Haller 2012-03-10 21:05 ` Junio C Hamano 2012-03-12 15:10 ` Marc Branchaud 2012-03-10 6:16 ` Michael Haggerty 1 sibling, 2 replies; 116+ messages in thread From: Stefan Haller @ 2012-03-09 21:08 UTC (permalink / raw) To: Marc Branchaud, Carlos Martín Nieto; +Cc: Matthieu Moy, git, gitster Marc Branchaud <marcnarc@xiplink.com> wrote: > I think that an incantation like > > git checkout -b topic origin/master > > makes it pretty clear that topic is meant to be merged into origin's > master branch. And so a simple "git push" as you describe I think > *should* update origin's master branch. Not for us, no. (But this is maybe a different topic.) In our workflow (centralized repository), we never ever have a local branch with a different name than its upstream branch. Never. When we say git checkout -b topic origin/master then it's always a mistake, and what we really meant was git checkout -b --no-track topic origin/master This has bitten us a few times in the past (people accidentally pushing their topic branches to master this way), and it's very annoying. But coming back to the subject of push.default: in our environment, "upstream" is the only default that is useful with the current behaviour of git. (I could dream of a git mode where it's not necessary to explicitly set an upstream branch, and all git operations such as status, pull, or even saying "@{u}" would automatically use "remotes/origin/samename" as the upstream branch. In that case, "current" would be a more convenient default value for push.default; but I guess that hypothetical mode would imply this anyway.) -- Stefan Haller Berlin, Germany http://www.haller-berlin.de/ ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [RFC PATCH] push: start warning upcoming default change for push.default 2012-03-09 21:08 ` Stefan Haller @ 2012-03-10 21:05 ` Junio C Hamano 2012-03-11 20:26 ` Stefan Haller 2012-03-12 15:10 ` Marc Branchaud 1 sibling, 1 reply; 116+ messages in thread From: Junio C Hamano @ 2012-03-10 21:05 UTC (permalink / raw) To: Stefan Haller; +Cc: Marc Branchaud, Carlos Martín Nieto, Matthieu Moy, git lists@haller-berlin.de (Stefan Haller) writes: > Marc Branchaud <marcnarc@xiplink.com> wrote: > >> I think that an incantation like >> >> git checkout -b topic origin/master >> >> makes it pretty clear that topic is meant to be merged into origin's >> master branch. And so a simple "git push" as you describe I think >> *should* update origin's master branch. > > Not for us, no. (But this is maybe a different topic.) > > In our workflow (centralized repository), we never ever have a local > branch with a different name than its upstream branch. Never. > > When we say > > git checkout -b topic origin/master > > then it's always a mistake, and what we really meant was > > git checkout -b --no-track topic origin/master It would have been nice if you explained larger picture of your workflow, as almost anything else in life, a blanket statement like the above is not a universal truth. It is clear you were aware of that from your "Not for *us*", there is not enough clue for others to tell if their workflow is similar to yours to decide if the above rule of thumb of yours is a good one to follow for them. Let's illustrate what I mean by "explain larger picture of workflow" with a few examples. An example of where "checkout -b topic origin/master" would not be a mistake is when it is the norm for your project for contributors to integrate their work with "pull --rebase", it is perfectly sensible for a contributor to git checkout -b frotz origin/master to start working on his feature "frotz", and way before the feature becomes ready, starting to work on unrelated feature "nitfol" with git checout -b nitfol origin/master and keep building these in parallel, running "git pull --rebase" to float yet-to-be-published his own work on updated the shared history before continuing to work on a topic until the feature is done. As the contributor may not know upfront which of these independent features will become ready when he starts working, it is sensible to be on the latter "nitfol" topic and "git push" it to update the shared history with the finished work on the branch. In this case, you would want "git push" a branch to its @{upstream}. Another example that "checkout -b topic origin/master" would not be a mistake is when you fork your favorite project at GitHub, work on two independent topics. You work the same way as the above (you may not "pull --rebase", though), and then push both of them out and ask them to be pulled "Please pull my 'frotz' and 'nitfol' branches". In this case, you would want "git push" a branch to update the branch with the same name (i.e. either 'current' or 'matching'). ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [RFC PATCH] push: start warning upcoming default change for push.default 2012-03-10 21:05 ` Junio C Hamano @ 2012-03-11 20:26 ` Stefan Haller 2012-03-12 8:47 ` Matthieu Moy 0 siblings, 1 reply; 116+ messages in thread From: Stefan Haller @ 2012-03-11 20:26 UTC (permalink / raw) To: Junio C Hamano Cc: Marc Branchaud, Carlos Martín Nieto, Matthieu Moy, git Junio C Hamano <gitster@pobox.com> wrote: > lists@haller-berlin.de (Stefan Haller) writes: > > > When we say > > > > git checkout -b topic origin/master > > > > then it's always a mistake, and what we really meant was > > > > git checkout -b --no-track topic origin/master > > It would have been nice if you explained larger picture of your > workflow, as almost anything else in life, a blanket statement like > the above is not a universal truth. I wasn't saying that "checkout -b topic origin/master" isn't useful for *anybody*; it's just not useful for us. But you are right, I should have explained who "us" is, and what our workflow is, sorry. We're a closed-source company that uses git more or less like an old-style, non-distributed VCS. (This is not because "we don't get it", as someone phrased it elsewhere in this thread, but because it's what makes most sense for us.) The central repository has special significance, because it sends an email for every commit, and it is hooked up to the CI system. For these reasons, everything that people work on is pushed to the central repository, on a topic branch with the same name as the local branch. Also, it is very common for two or more developers to collaborate on a topic branch, and the central repository is the hub for this (developers pull topics with "pull --rebase"). There's no direct exchange between developer's clones, because others on the team wouldn't see a commit mail. Topics are never pushed to master; we have a "merge --no-ff" policy for integration. Sometimes, we need to branch a topic (let's call it B) off another topic (say A), because B needs some of A's code before it's integrated (we'll rebase B onto master once A is merged back, to keep the history clean). Same thing here: we say "checkout -b B origin/A", but we don't want to have B's upstream to be set to origin/A. Again, we forgot to say --no-track. To sum it up, push.default=current is almost perfect for this kind of workflow; except that you still need to configure your upstream branches so that pull works, and status (and the shell prompt) displays the right information. -- Stefan Haller Berlin, Germany http://www.haller-berlin.de/ ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [RFC PATCH] push: start warning upcoming default change for push.default 2012-03-11 20:26 ` Stefan Haller @ 2012-03-12 8:47 ` Matthieu Moy 2012-03-12 11:22 ` Stefan Haller 0 siblings, 1 reply; 116+ messages in thread From: Matthieu Moy @ 2012-03-12 8:47 UTC (permalink / raw) To: Stefan Haller Cc: Junio C Hamano, Marc Branchaud, Carlos Martín Nieto, git lists@haller-berlin.de (Stefan Haller) writes: > We're a closed-source company that uses git more or less like an > old-style, non-distributed VCS. > [...] > Also, it is very common for two or more developers to collaborate on a > topic branch, > [...] > Topics are never pushed to master; we have a "merge --no-ff" policy for > integration. > [...] > To sum it up, push.default=current is almost perfect for this kind of > workflow; except that you still need to configure your upstream branches > so that pull works, and status (and the shell prompt) displays the right > information. What do you set "upstream" to in your flow? I agree that push.default=current is the best setting for you. But I think 'tracking' would not be a silly choice either: if you collaborate on topic branches, it makes sense to set the upstream to the remote topic branch, so that "git pull" gets changes in the same branch (and you may need to "git pull origin master" to sync with the master branch from time to time). If you create a new branch with, say git checkout -b new-branch then the new branch has no upstream configured, and the next push without argument will fail, pointing you to the right command for your case: $ git push fatal: The current branch new-branch has no upstream branch. To push the current branch and set the remote as upstream, use git push --set-upstream origin new-branch If you do a "git checkout new-branch" when "origin/new-branch" exists and "new-branch" doesn't, the upstream is configured to point to the remote "new-branch". In both cases, the upstream is configured so that push.default=current do the same thing as push.default=upstream, so you don't really care which value is taken. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [RFC PATCH] push: start warning upcoming default change for push.default 2012-03-12 8:47 ` Matthieu Moy @ 2012-03-12 11:22 ` Stefan Haller 2012-03-12 12:46 ` Matthieu Moy 0 siblings, 1 reply; 116+ messages in thread From: Stefan Haller @ 2012-03-12 11:22 UTC (permalink / raw) To: Matthieu Moy Cc: Junio C Hamano, Marc Branchaud, Carlos Martín Nieto, git Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote: > lists@haller-berlin.de (Stefan Haller) writes: > > > We're a closed-source company that uses git more or less like an > > old-style, non-distributed VCS. > > [...] > > Also, it is very common for two or more developers to collaborate on a > > topic branch, > > [...] > > Topics are never pushed to master; we have a "merge --no-ff" policy for > > integration. > > [...] > > To sum it up, push.default=current is almost perfect for this kind of > > workflow; except that you still need to configure your upstream branches > > so that pull works, and status (and the shell prompt) displays the right > > information. > > What do you set "upstream" to in your flow? The remote topic branch with the same name. > I agree that push.default=current is the best setting for you. But I > think 'tracking' would not be a silly choice either: if you collaborate > on topic branches, it makes sense to set the upstream to the remote > topic branch, so that "git pull" gets changes in the same branch (and > you may need to "git pull origin master" to sync with the master branch > from time to time). If you create a new branch with, say > > git checkout -b new-branch > > then the new branch has no upstream configured, and the next push > without argument will fail, pointing you to the right command for your > case: > > $ git push > fatal: The current branch new-branch has no upstream branch. > To push the current branch and set the remote as upstream, use > > git push --set-upstream origin new-branch > > If you do a "git checkout new-branch" when "origin/new-branch" exists > and "new-branch" doesn't, the upstream is configured to point to the > remote "new-branch". Yes, you describe exactly what we are doing. I am having two problems with this way of working: 1) After creating a new local topic branch, I must remember to use "push -u origin new-branch" the first time I push it. I don't want to have to remember whether this is the first time I push; it would be nice to be able to say "git push" the first time as well. (push.default=current does this, but it's not good enough because I still need the upstream branch configured so that pull works.) 2) I get bitten by commands that configure the "wrong" upstream branch without me realizing it, like "checkout -b topic origin/master". Again, push.default=current helps somewhat because it avoids accidentally pushing to the wrong branch; but it will still let me pull from the wrong branch; and it will confuse me because my shell prompt tells me I'm ahead of upstream even though I just pushed. -- Stefan Haller Berlin, Germany http://www.haller-berlin.de/ ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [RFC PATCH] push: start warning upcoming default change for push.default 2012-03-12 11:22 ` Stefan Haller @ 2012-03-12 12:46 ` Matthieu Moy 2012-03-12 16:11 ` Junio C Hamano 0 siblings, 1 reply; 116+ messages in thread From: Matthieu Moy @ 2012-03-12 12:46 UTC (permalink / raw) To: Stefan Haller Cc: Junio C Hamano, Marc Branchaud, Carlos Martín Nieto, git lists@haller-berlin.de (Stefan Haller) writes: > Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote: > >> What do you set "upstream" to in your flow? > > The remote topic branch with the same name. OK, so once it is configured, 'current' and 'upstream' do the same thing. The difference is how the upstream is configured, and what happens if you forget to do it. > 1) After creating a new local topic branch, I must remember to use > "push -u origin new-branch" the first time I push it. For this case, I'd say 'upstream' is superior to 'current', because it will remind you to set the upstream on the first push, while 'current' will let you silently continue with the upstream unconfigured (which you need for 'pull' and 'status'). > I don't want to have to remember whether this is the first time I > push; it would be nice to be able to say "git push" the first time as > well. (If you're going to work colaboratively, I'd say it makes sense to push an empty branch, just to let other people know that the branch is created, but that's not the point here) Probably the ideal command for you would be to allow something like git checkout -b topic origin/master --set-upstream=origin/topic > 2) I get bitten by commands that configure the "wrong" upstream branch > without me realizing it, like "checkout -b topic origin/master". You may want to set branch.autosetupmerge to false, then. It will disable the "set upstream" magic (but unfortunately, it will also disable it for a plain "git checkout new-branch" which would create new-branch automagically if origin/new-branch already exists). Just to be clear: I'm not saying that your workflow is wrong, but my feeling is that you wouldn't be hurt by 'push.default=upstream'. The area of potential improvement for your case would be at branch creation time more than at push time. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [RFC PATCH] push: start warning upcoming default change for push.default 2012-03-12 12:46 ` Matthieu Moy @ 2012-03-12 16:11 ` Junio C Hamano 0 siblings, 0 replies; 116+ messages in thread From: Junio C Hamano @ 2012-03-12 16:11 UTC (permalink / raw) To: Matthieu Moy; +Cc: Stefan Haller, Marc Branchaud, Carlos Martín Nieto, git Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes: > Just to be clear: I'm not saying that your workflow is wrong, but my > feeling is that you wouldn't be hurt by 'push.default=upstream'. The > area of potential improvement for your case would be at branch creation > time more than at push time. Your analysis of Stefan's pain points sounds very sensible. The autoSetupMerge mechanism may want to learn new tricks, but that is a separate issue and it shouldn't affect the search for a sane default for push. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [RFC PATCH] push: start warning upcoming default change for push.default 2012-03-09 21:08 ` Stefan Haller 2012-03-10 21:05 ` Junio C Hamano @ 2012-03-12 15:10 ` Marc Branchaud 1 sibling, 0 replies; 116+ messages in thread From: Marc Branchaud @ 2012-03-12 15:10 UTC (permalink / raw) To: Stefan Haller; +Cc: Carlos Martín Nieto, Matthieu Moy, git, gitster On 12-03-09 04:08 PM, Stefan Haller wrote: > > But coming back to the subject of push.default: in our environment, > "upstream" is the only default that is useful with the current behaviour > of git. I'm not at all surprised -- everyone works differently. This is why the default is configurable in the first place. When it comes to what git should do by default, I think it's a bit pointless to have environment-vs-environment discussions. No matter how many people join such a discussion on this list, it can only give us hints to which default would best serve git's users. Maybe the git survey can tell us what workflows are most popular, but even that may not indicate the best default behaviour. The point I was trying to make in my previous message is that "upstream" seems like the least dangerous default behaviour. Yes, it does not match everyone's workflow. But it seems the least likely to shoot the feet off of people who have yet to figure out their workflow at all. M. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [RFC PATCH] push: start warning upcoming default change for push.default 2012-03-09 18:30 ` Marc Branchaud 2012-03-09 21:08 ` Stefan Haller @ 2012-03-10 6:16 ` Michael Haggerty 2012-03-12 15:13 ` Marc Branchaud 1 sibling, 1 reply; 116+ messages in thread From: Michael Haggerty @ 2012-03-10 6:16 UTC (permalink / raw) To: Marc Branchaud; +Cc: Carlos Martín Nieto, Matthieu Moy, git, gitster On 03/09/2012 07:30 PM, Marc Branchaud wrote: > On 12-03-09 05:25 AM, Carlos Martín Nieto wrote: >> On Fri, 2012-03-09 at 09:31 +0100, Matthieu Moy wrote: >>> This patch prepares a transition to 'upstream', unlike the previous >>> version which was advertizing 'current'. In most case, this would be >>> the same, but 'upstream' is probably more sensible in case it points >>> to a branch other than 'current'. I don't care much either way. >>> >> >> For people using git as VCS that happens to have local history rather >> than taking full advantage of the distributed nature (or who aren't >> aware of it or don't get it), 'matching' is bound to be confusing. >> However, IMO 'current' makes more sense. Consider >> [...] > > I disagree and consider "upstream" to be the more reasonable default. > [...] I think that either "current" or "upstream" would be an improvement on the current behavior, but each of them is inappropriate in certain workflows (even among centralized workflows). I propose that the default should be even stricter: like "current", it would push to an branch with the same name as the current local branch, *but only if that branch already exists on the remote*. It would only be possible to create a new branch on the remote by calling "git push" with an explicit branch argument. I believe that such a policy would do the right thing in the cases where the "right thing" is pretty unambiguous, and would require a user decision in other cases. Of course, users who have a strong preference for what is the "right thing" in the ambiguous case can fine-tune their local preference to "current" or "upstream"; this would amount to a relaxation of the strict default policy. Michael -- Michael Haggerty mhagger@alum.mit.edu http://softwareswirl.blogspot.com/ ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [RFC PATCH] push: start warning upcoming default change for push.default 2012-03-10 6:16 ` Michael Haggerty @ 2012-03-12 15:13 ` Marc Branchaud 2012-03-12 16:37 ` Matthieu Moy 0 siblings, 1 reply; 116+ messages in thread From: Marc Branchaud @ 2012-03-12 15:13 UTC (permalink / raw) To: Michael Haggerty; +Cc: Carlos Martín Nieto, Matthieu Moy, git, gitster On 12-03-10 01:16 AM, Michael Haggerty wrote: > > I propose that the default should be even stricter: like "current", it > would push to an branch with the same name as the current local branch, > *but only if that branch already exists on the remote*. It would only > be possible to create a new branch on the remote by calling "git push" > with an explicit branch argument. I believe that such a policy would do > the right thing in the cases where the "right thing" is pretty > unambiguous, and would require a user decision in other cases. I haven't thought it through very deeply, but at first glance this seems like reasonable default behaviour to me. M. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [RFC PATCH] push: start warning upcoming default change for push.default 2012-03-12 15:13 ` Marc Branchaud @ 2012-03-12 16:37 ` Matthieu Moy 2012-03-12 17:53 ` Junio C Hamano 2012-03-12 18:37 ` Jeff King 0 siblings, 2 replies; 116+ messages in thread From: Matthieu Moy @ 2012-03-12 16:37 UTC (permalink / raw) To: Marc Branchaud; +Cc: Michael Haggerty, Carlos Martín Nieto, git, gitster Marc Branchaud <marcnarc@xiplink.com> writes: > On 12-03-10 01:16 AM, Michael Haggerty wrote: >> >> I propose that the default should be even stricter: like "current", it >> would push to an branch with the same name as the current local branch, >> *but only if that branch already exists on the remote*. It would only >> be possible to create a new branch on the remote by calling "git push" >> with an explicit branch argument. I believe that such a policy would do >> the right thing in the cases where the "right thing" is pretty >> unambiguous, and would require a user decision in other cases. > > I haven't thought it through very deeply, but at first glance this seems like > reasonable default behaviour to me. I do find it reasonable, but I think 'upstream' has several advantages over it. * 'upstream' makes "git push" and "git pull" symmetrical. While there are workflows where it is usefull to have "push" and "pull" point to different branches, I think it is far more intuitive to have this symmetry by default. * For newbies, the sequence "create an empty repository, clone it, commit and push" works like a charm with either 'upstream' or 'current'. Today, the first push to an empty repository requires either saying "git push origin master" or "git push --all", both of which sound like black magic to the poor user who did not yet learn what 'origin' is and what a branch is. * 'upstream' makes it easy to create a local topic branch, and let 'push' send it to the master branch (i.e. have local 'topic-branch' pull and push to 'origin/master'). In general, 'upstream' allows workflows where you push to branches with either a different name or with the same name (by setting the upstream appropriately), but the opposite is not true. That being said, I think the mode you Michael described at least deserves to exist, even if I disagree that it would be the best default. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [RFC PATCH] push: start warning upcoming default change for push.default 2012-03-12 16:37 ` Matthieu Moy @ 2012-03-12 17:53 ` Junio C Hamano 2012-03-12 18:37 ` Jeff King 1 sibling, 0 replies; 116+ messages in thread From: Junio C Hamano @ 2012-03-12 17:53 UTC (permalink / raw) To: Matthieu Moy Cc: Marc Branchaud, Michael Haggerty, Carlos Martín Nieto, git, gitster Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes: > * 'upstream' makes "git push" and "git pull" symmetrical. While there > are workflows where it is usefull to have "push" and "pull" point to > different branches, I think it is far more intuitive to have this > symmetry by default. Yes, "by default" is really the key word in this discussion, and I find the above a sound reasoning. > ... > That being said, I think the mode you Michael described at least > deserves to exist, even if I disagree that it would be the best default. While I agree with that, I think the "if and only if the destination already exists" falls into the same "modifier" category as "force" that changes the behaviour of updating _one_ ref from the default "only if it fast-forwards" to "even if it does not fast-forward". I would prefer this new modifier not to be tied too tightly to the Michael's magic mode, so that it can also be used when the refspecs are explicitly given. In other words, with "force": git push $there +pu updates branch 'pu' over there even if it is not an ancestor of our 'pu'. Similarly, may want to be able to say (I am *not* suggesting to use '?' as the motifier): git push $there ?next to update next only if it exists over there and it is an ancestor of our 'next'. Maybe these modifiers can be combined, so that I can say for there in k.org repo github sf.net do git push $there maint master ?next ?+pu done Because the publishing point I have at sourceforge lack next and pu, this will only update maint and master following the usual rules over there, but next and pu will be updated at other places. Hmm? ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [RFC PATCH] push: start warning upcoming default change for push.default 2012-03-12 16:37 ` Matthieu Moy 2012-03-12 17:53 ` Junio C Hamano @ 2012-03-12 18:37 ` Jeff King 2012-03-12 19:06 ` Junio C Hamano ` (2 more replies) 1 sibling, 3 replies; 116+ messages in thread From: Jeff King @ 2012-03-12 18:37 UTC (permalink / raw) To: Matthieu Moy Cc: Marc Branchaud, Michael Haggerty, Carlos Martín Nieto, git, gitster On Mon, Mar 12, 2012 at 05:37:32PM +0100, Matthieu Moy wrote: > I do find it reasonable, but I think 'upstream' has several advantages > over it. > > * 'upstream' makes "git push" and "git pull" symmetrical. While there > are workflows where it is usefull to have "push" and "pull" point to > different branches, I think it is far more intuitive to have this > symmetry by default. This is one of the things I really hate about 'upstream'. If you share a central repo with other people, it makes sense. You push and pull from the same place. But in the classic kernel-style workflow, you'd pull from an upstream, and then publish your work elsewhere. And I think it's not just kernel people who use this asymmetric workflow. On something like GitHub, you get your own fork repo on the site as a publishing point. But you also want to keep pulling and basing your work on what the main project is doing. You can't just pull from your fork, since it never gets updates from the main project; you pull them into your local repo, and then push them up to your fork. So in a very reasonable common newbie workflow, "upstream" will not at all do what you want, because it will go to the wrong repo[1] That being said, "current" will _also_ go to the wrong repo, because push fundamentally respects "branch.*.remote". Which is definitely not what you want in the asymmetric case. This is not a push.default issue, but I think it is somewhat related, and maybe worth discussing along with the topic of asymmetry. Am I the only one who finds this behavior annoying? I've mostly trained my fingers to type "git push <my-publish-repo>", but I do occasionally forget. Do other people with asymmetric workflows find this annoying? Do they not care? Or are many fewer people doing asymmetric things than I think? While I'm ranting, there's another weirdness I noticed. If I have push.default set to upstream, and config like this: [branch "foo"] remote = origin merge = refs/heads/master then typing "git push" will go to foo's master branch. But if I type "git push other-remote", then it will go to other-remote's master branch. Which makes no sense to me. The upstream is foo's master, and now we are making guesses about how the names on each side are the same. Is this an intentional behavior? [1] One saving grace of going to the wrong repo is that you usually don't have permissions to push to that repo, so you get a harmless error message. > * For newbies, the sequence "create an empty repository, clone it, > commit and push" works like a charm with either 'upstream' or > 'current'. Today, the first push to an empty repository requires > either saying "git push origin master" or "git push --all", both of > which sound like black magic to the poor user who did not yet learn > what 'origin' is and what a branch is. Ending that confusion is one of the best reasons to switch the default, IMHO, but I don't think it argues for "current" versus "upstream", as they both fix it (but Michael's matching-current hybrid would not, so I agree it is less appealing). > * 'upstream' makes it easy to create a local topic branch, and let > 'push' send it to the master branch (i.e. have local 'topic-branch' > pull and push to 'origin/master'). In general, 'upstream' allows > workflows where you push to branches with either a different name or > with the same name (by setting the upstream appropriately), but the > opposite is not true. Actually, this is the thing that scares me the most about "upstream" as a default, because in this case, you are implicitly performing the equivalent of a fast-forward merge. So that's handy if you are a new user who wants to publish your work back to the master branch. But that has two problems: 1. If you are a new user who does like the implicit merge, you may find it convenient not to have to learn about "git checkout; git merge topic ; git push remote master". But it only helps you _sometimes_. If master has had other work built on it, your push will fail, and you will have to do the merge yourself. So it is only helping you by omitting a step some of the time, and you still have to learn why the step is sometimes necessary and sometimes not. Yes, experienced users do not have this learning problem. But remember we are talking about a default targeted at new users, and trying to reduce their confusion. People who know and like what "upstream" does can configure it themselves. 2. If you are a new user who _doesn't_ want to do the merge, but instead wants to publish your work-in-progress topic, then the implicit merge-back-to-master behavior is wrong and dangerous. You are publishing work that probably violates the general rules for what goes on master. Or perhaps somebody else has built on top of master, and your push fails. If you're an astute reader, you will see that the failing push tried to go to master. But if you're not, you may retry with "-f", which is quite dangerous, as now you are not just accidentally publishing a work-in-progress, but you are overwriting somebody else's work. Obviously this is a problem anytime you use "-f", but the fact that your "foo" branch is going to somewhere besides the remote's "foo" branch makes me think it is much more likely a clueless user will get confused and overwrite something on the more "mainstream" branch. So far a lot of the discussion has focused on "what is the most sensible default for the most number of people". But I wonder if a better question is "what is the default that is the least likely to do something dangerous and embarrassing". People who use git enough to say "wow, I don't like this default for my workflow" are probably at the point that they can configure push.default themselves. -Peff ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [RFC PATCH] push: start warning upcoming default change for push.default 2012-03-12 18:37 ` Jeff King @ 2012-03-12 19:06 ` Junio C Hamano 2012-03-12 19:33 ` Junio C Hamano ` (3 more replies) 2012-03-13 9:34 ` Matthieu Moy 2012-03-14 8:59 ` Michael Haggerty 2 siblings, 4 replies; 116+ messages in thread From: Junio C Hamano @ 2012-03-12 19:06 UTC (permalink / raw) To: Jeff King Cc: Matthieu Moy, Marc Branchaud, Michael Haggerty, Carlos Martín Nieto, git Jeff King <peff@peff.net> writes: > ... This is not a push.default issue, > but I think it is somewhat related, and maybe worth discussing along > with the topic of asymmetry. ... > I've mostly trained my fingers to type "git push > <my-publish-repo>", but I do occasionally forget. In an assymmetric set-up, you would typically push into one place but update from one or more places, so it might make sense to make it easier to say "git push" and "git pull $there". But that does not solve the fundamental issue, I would think. > Do other people with > asymmetric workflows find this annoying? Do they not care? Or are many > fewer people doing asymmetric things than I think? I think it is not "they do not care", but "they do not have a good solution". I do not think of anything offhand, either. > While I'm ranting, there's another weirdness I noticed. If I have > push.default set to upstream, and config like this: > > [branch "foo"] > remote = origin > merge = refs/heads/master > > then typing "git push" will go to foo's master branch. But if I type > "git push other-remote", then it will go to other-remote's master > branch. Which makes no sense to me. The upstream is foo's master, and > now we are making guesses about how the names on each side are the same. > Is this an intentional behavior? Because "upstream" is meant to be "For the branch I am on, you know how the branches map between the remote repository, so you already know what the right thing to do---do it" mode, the correct "guess" in your case is to error out and say "Nah, you are not talking with your upstream, so I do not have any clue what branches you want to push out and how. As you said that the push.default is upstream, not matching, I refuse to even do the matching push in your case. This is an error. Be more specific". > Actually, this is the thing that scares me the most about "upstream" as > a default, because in this case, you are implicitly performing the > equivalent of a fast-forward merge. So that's handy if you are a new > user who wants to publish your work back to the master branch. But that > has two problems: > > 1. If you are a new user who does like the implicit merge, you > may find it convenient not to have to learn about ... << and we > shouldn't discourage them from learning as it will be needed > anyway >> > > 2. If you are a new user who _doesn't_ want to do the merge, but > instead wants to publish your work-in-progress topic, then the > implicit merge-back-to-master behavior is wrong and dangerous. > << the newbie may push -f ruining the work of others >> I agree with both points. Also there is a cross-variant issue of the above two: If a new user hears "not fast-forward, first pull and then push again", that will be done on a topic branch, merging 'master' back and then pushing the result to 'master', leaving the 'master' of the user behind. > So far a lot of the discussion has focused on "what is the most sensible > default for the most number of people". But I wonder if a better > question is "what is the default that is the least likely to do > something dangerous and embarrassing". People who use git enough to say > "wow, I don't like this default for my workflow" are probably at the > point that they can configure push.default themselves. I do not think "the most number of people" is a high-priority issue, but "least damage" default may not be necessarily the best. Obviously, "nothing" is the least-damage option, and looking at how even people on this list cannot decide between current and upstream, I actually am very tempted to suggest it as the new default. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [RFC PATCH] push: start warning upcoming default change for push.default 2012-03-12 19:06 ` Junio C Hamano @ 2012-03-12 19:33 ` Junio C Hamano 2012-03-12 20:16 ` Marc Branchaud ` (2 subsequent siblings) 3 siblings, 0 replies; 116+ messages in thread From: Junio C Hamano @ 2012-03-12 19:33 UTC (permalink / raw) To: git Cc: Jeff King, Matthieu Moy, Marc Branchaud, Michael Haggerty, Carlos Martín Nieto Junio C Hamano <gitster@pobox.com> writes: > Jeff King <peff@peff.net> writes: > >> ... This is not a push.default issue, >> but I think it is somewhat related, and maybe worth discussing along >> with the topic of asymmetry. ... >> I've mostly trained my fingers to type "git push >> <my-publish-repo>", but I do occasionally forget. > > In an assymmetric set-up, you would typically push into one place > but update from one or more places, so it might make sense to make > it easier to say "git push" and "git pull $there". But that does > not solve the fundamental issue, I would think. > >> Do other people with >> asymmetric workflows find this annoying? Do they not care? Or are many >> fewer people doing asymmetric things than I think? > > I think it is not "they do not care", but "they do not have a good > solution". I do not think of anything offhand, either. Actually, we could introduce branch.$name.pushRemote that overrides branch.$name.remote only for pushes. Before anybody makes an ill-conceived comment, remote.$name.pushURL is not to be used for this purpose. It is only about how to get to the named remote repository, and git still considers remote.$name to be logically the same remote. "git push" into the named remote will still update the remote tracking branch that we would update if we were to immediately turn around and run "git fetch" from that same remote, and abusing remote.$name.pushURL for triangular setup will not give us a correct behaviour. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [RFC PATCH] push: start warning upcoming default change for push.default 2012-03-12 19:06 ` Junio C Hamano 2012-03-12 19:33 ` Junio C Hamano @ 2012-03-12 20:16 ` Marc Branchaud 2012-03-13 9:40 ` Matthieu Moy 2012-03-13 9:36 ` Matthieu Moy 2012-03-13 21:30 ` Jeff King 3 siblings, 1 reply; 116+ messages in thread From: Marc Branchaud @ 2012-03-12 20:16 UTC (permalink / raw) To: Junio C Hamano Cc: Jeff King, Matthieu Moy, Michael Haggerty, Carlos Martín Nieto, git On 12-03-12 03:06 PM, Junio C Hamano wrote: > Jeff King <peff@peff.net> writes: >> >> So far a lot of the discussion has focused on "what is the most sensible >> default for the most number of people". But I wonder if a better >> question is "what is the default that is the least likely to do >> something dangerous and embarrassing". People who use git enough to say >> "wow, I don't like this default for my workflow" are probably at the >> point that they can configure push.default themselves. > > I do not think "the most number of people" is a high-priority issue, > but "least damage" default may not be necessarily the best. I agree, but I don't think we even have a good idea of what "least damage" even means. It seems to be vaguely related to how much of a hassle it would be to recover from a plain "git push" doing the wrong thing. There's one thing I'd like to ask all the folks who are pointing out how well the candidate defaults match various workflows: How much training do you give (or are assuming for) your workflow's new users? Or, more broadly, what is a "new" git user? Are we talking about someone using git for the first time on a brand-new project that they're setting up themselves? (Has that person even used any other VCS's?) Or is it someone who's joining an already-established team? Even a "new" user hacking the Linux kernel or forking some github project is tying into an established process. And most every established process has either documentation (or a person) to explain how things are set up, and how to best configure git to work in that environment. IMHO git need not worry about "new" users joining an established process, if for no other reason that it seems impossible to make git new-user-friendly in all (or even most) of those environments. Instead the focus should be on new users who are wrestling with git by themselves (well, hopefully with the help whatever online documentation they've found). They're making up their workflows as they go, refining them as they learn more about git. These are the users that git's defaults should cater to. And for those users, I still think "upstream" is the best of the current default candidates. > Obviously, "nothing" is the least-damage option, and looking at how > even people on this list cannot decide between current and upstream, > I actually am very tempted to suggest it as the new default. There's a lot of merit to that. If nothing else, it'd get new users to learn at least a little bit about git. I wouldn't be opposed to pushing nothing by default. M. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [RFC PATCH] push: start warning upcoming default change for push.default 2012-03-12 20:16 ` Marc Branchaud @ 2012-03-13 9:40 ` Matthieu Moy 0 siblings, 0 replies; 116+ messages in thread From: Matthieu Moy @ 2012-03-13 9:40 UTC (permalink / raw) To: Marc Branchaud Cc: Junio C Hamano, Jeff King, Michael Haggerty, Carlos Martín Nieto, git Marc Branchaud <marcnarc@xiplink.com> writes: >> Obviously, "nothing" is the least-damage option, and looking at how >> even people on this list cannot decide between current and upstream, >> I actually am very tempted to suggest it as the new default. > > There's a lot of merit to that. If nothing else, it'd get new users to learn > at least a little bit about git. I wouldn't be opposed to pushing nothing by > default. That would imply teching people what a branch is before teaching them very basic workflows with push and pull. If Git goes this route, I'll have to consider Mercurial instead of Git to teach revision control to my students ;-). -- Matthieu Moy http://www-verimag.imag.fr/~moy/ ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [RFC PATCH] push: start warning upcoming default change for push.default 2012-03-12 19:06 ` Junio C Hamano 2012-03-12 19:33 ` Junio C Hamano 2012-03-12 20:16 ` Marc Branchaud @ 2012-03-13 9:36 ` Matthieu Moy 2012-03-13 21:30 ` Jeff King 3 siblings, 0 replies; 116+ messages in thread From: Matthieu Moy @ 2012-03-13 9:36 UTC (permalink / raw) To: Junio C Hamano Cc: Jeff King, Marc Branchaud, Michael Haggerty, Carlos Martín Nieto, git Junio C Hamano <gitster@pobox.com> writes: > Jeff King <peff@peff.net> writes: > >> ... This is not a push.default issue, >> but I think it is somewhat related, and maybe worth discussing along >> with the topic of asymmetry. ... >> I've mostly trained my fingers to type "git push >> <my-publish-repo>", but I do occasionally forget. > > In an assymmetric set-up, you would typically push into one place > but update from one or more places, so it might make sense to make > it easier to say "git push" and "git pull $there". But that does > not solve the fundamental issue, I would think. It does not solve it completely, but it makes it sensible to have 'upstream' point to the place you are publishing to, and tell "git pull" explicitely where you want to pull from. This is the way I work when I have an asymmetrical setup (not the most common in my case). -- Matthieu Moy http://www-verimag.imag.fr/~moy/ ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [RFC PATCH] push: start warning upcoming default change for push.default 2012-03-12 19:06 ` Junio C Hamano ` (2 preceding siblings ...) 2012-03-13 9:36 ` Matthieu Moy @ 2012-03-13 21:30 ` Jeff King 2012-03-13 22:54 ` Junio C Hamano 3 siblings, 1 reply; 116+ messages in thread From: Jeff King @ 2012-03-13 21:30 UTC (permalink / raw) To: Junio C Hamano Cc: Matthieu Moy, Marc Branchaud, Michael Haggerty, Carlos Martín Nieto, git On Mon, Mar 12, 2012 at 12:06:48PM -0700, Junio C Hamano wrote: > Jeff King <peff@peff.net> writes: > > > ... This is not a push.default issue, > > but I think it is somewhat related, and maybe worth discussing along > > with the topic of asymmetry. ... > > I've mostly trained my fingers to type "git push > > <my-publish-repo>", but I do occasionally forget. > > In an assymmetric set-up, you would typically push into one place > but update from one or more places, so it might make sense to make > it easier to say "git push" and "git pull $there". But that does > not solve the fundamental issue, I would think. I think it can even be a bit more complex than that. For example, I actually _never_ run git-pull. Instead, I fetch, and then use the upstream config for lots of other operations, like seeing what's in a topic branch, rebasing, etc. So to me, it is not just about "symmetry between push and pull", but that the upstream config is fundamentally about "what is this work based off of", which may or may not have anything to do with where you are pushing to. > > Do other people with > > asymmetric workflows find this annoying? Do they not care? Or are many > > fewer people doing asymmetric things than I think? > > I think it is not "they do not care", but "they do not have a good > solution". I do not think of anything offhand, either. The branch.*.pushRemote you mentioned would help with that. But for me, I would much rather have simply push.defaultRemote. Configuring each branch independently would be a pain, and I always want to push to my publishing point (or at least, by default; anything else is a one-off that can get an option on the command line). It is not a per-branch thing at all for me. Speaking of which, I often get annoyed at the per-branch auto-configuration of upstreams. For example, I find myself doing this: [get an idea, read a bug report on the list, etc] $ cd git $ hack hack hack [oh, this is turning into something real. Let's make a branch] $ git checkout -b jk/bug-fix $ git commit -m 'fix bug' but now my bug-fix branch is based off of wherever I was (which is usually some private topic-integration branch I run most of the time). I wish there was some way to say "No, branches should _always_ consider origin/master as their upstream, unless I configure them some other way" (which I do occasionally for building sub-topics on other topics). Which makes me wonder if perhaps people are using "upstream" to mean several different thing. I use it to say "this is the branch that this topic is based off of", which makes "git log @{u}.." helpful, "git rebase -i" just work, and gives some meaning to the ahead/behind message (it shows how my topic relates to the main project). But I think people also use upstream to mean "this is the definitive version of this branch in some central repo". So they would say that "jk/bug-fix" is based on "origin/jk/bug-fix". And the ahead/behind message is about "do I have any local work that needs pushed, or any remote work that needs pulled?" And I wonder if this is where some of the debate for push.default=upstream comes from. Whether that is useful to you or not would depend on how you set up your branches. In the latter model, I would think pushing to the upstream would be the right thing. > Because "upstream" is meant to be "For the branch I am on, you know > how the branches map between the remote repository, so you already > know what the right thing to do---do it" mode, the correct "guess" > in your case is to error out and say "Nah, you are not talking with > your upstream, so I do not have any clue what branches you want to > push out and how. As you said that the push.default is upstream, not > matching, I refuse to even do the matching push in your case. This > is an error. Be more specific". Yeah, I agree that is the only sane thing to do. > I do not think "the most number of people" is a high-priority issue, > but "least damage" default may not be necessarily the best. > > Obviously, "nothing" is the least-damage option, and looking at how > even people on this list cannot decide between current and upstream, > I actually am very tempted to suggest it as the new default. I was tempted to suggest that, but it somehow feels too overboard and unfriendly. I really like "current", as it seems like the simplest and unsurprising thing we can do, short of doing nothing at all. -Peff ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [RFC PATCH] push: start warning upcoming default change for push.default 2012-03-13 21:30 ` Jeff King @ 2012-03-13 22:54 ` Junio C Hamano 2012-03-14 13:50 ` Jeff King 0 siblings, 1 reply; 116+ messages in thread From: Junio C Hamano @ 2012-03-13 22:54 UTC (permalink / raw) To: Jeff King Cc: Matthieu Moy, Marc Branchaud, Michael Haggerty, Carlos Martín Nieto, git Jeff King <peff@peff.net> writes: > The branch.*.pushRemote you mentioned would help with that. But for me, > I would much rather have simply push.defaultRemote. I would think that is a natural way to extend it. Don't we already have something similar that is per repository default that can be overriden with per branch configuration? > Speaking of which, I often get annoyed at the per-branch > auto-configuration of upstreams. For example, I find myself doing this: > > [get an idea, read a bug report on the list, etc] > $ cd git > $ hack hack hack > [oh, this is turning into something real. Let's make a branch] > $ git checkout -b jk/bug-fix > $ git commit -m 'fix bug' > > but now my bug-fix branch is based off of wherever I was (which is > usually some private topic-integration branch I run most of the time). What in "checkout -b jk/bug-fix" makes jk/bug-fix a downstream of origin/master? I admit my brain is not working very well today, but I would have expected the branch to have either your local private topic integration branch as its @{u}, or no @{u} defined for it at all. Perhaps there is a design error of some sort around that code? > Which makes me wonder if perhaps people are using "upstream" to mean > several different thing. I use it to say "this is the branch that this > topic is based off of", which makes "git log @{u}.." helpful, "git > rebase -i" just work, and gives some meaning to the ahead/behind message > (it shows how my topic relates to the main project). > > But I think people also use upstream to mean "this is the definitive > version of this branch in some central repo". So they would say that > "jk/bug-fix" is based on "origin/jk/bug-fix". And the ahead/behind > message is about "do I have any local work that needs pushed, or any > remote work that needs pulled?" I think that is the more common interpretation. Earlier you said ahead/behind gives "some meaning", but compared to this "how many more do I have, how many more do others have while I was looking the other way", I am not sure what kind of cue that "some meaning" would give us. > And I wonder if this is where some of the debate for > push.default=upstream comes from. Whether that is useful to you or not > would depend on how you set up your branches. In the latter model, I > would think pushing to the upstream would be the right thing. No question about the conclusion in the last sentence, but at the same time, I do not think the push.default is about making things work smoothly for people who configure everything right. >> Because "upstream" is meant to be "For the branch I am on, you know >> how the branches map between the remote repository, so you already >> know what the right thing to do---do it" mode, the correct "guess" >> in your case is to error out and say "Nah, you are not talking with >> your upstream, so I do not have any clue what branches you want to >> push out and how. As you said that the push.default is upstream, not >> matching, I refuse to even do the matching push in your case. This >> is an error. Be more specific". > > Yeah, I agree that is the only sane thing to do. Perhaps this can be a good sample entry for the experimental "tracker" thing to keep track of to see how the workflow will evolve around it; unless neither of us would get to work on it immediately, it is very likely to be forgotten, as this is a tangent in the overall discussion, even though the bug is real and solution is clear. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [RFC PATCH] push: start warning upcoming default change for push.default 2012-03-13 22:54 ` Junio C Hamano @ 2012-03-14 13:50 ` Jeff King 2012-03-14 20:59 ` Junio C Hamano 0 siblings, 1 reply; 116+ messages in thread From: Jeff King @ 2012-03-14 13:50 UTC (permalink / raw) To: Junio C Hamano Cc: Matthieu Moy, Marc Branchaud, Michael Haggerty, Carlos Martín Nieto, git On Tue, Mar 13, 2012 at 03:54:26PM -0700, Junio C Hamano wrote: > Jeff King <peff@peff.net> writes: > > > The branch.*.pushRemote you mentioned would help with that. But for me, > > I would much rather have simply push.defaultRemote. > > I would think that is a natural way to extend it. Don't we already have > something similar that is per repository default that can be overriden > with per branch configuration? I think branch.*.rebase / pull.rebase is the only current example. But yeah, having a hierarchy like that makes sense to me. > > Speaking of which, I often get annoyed at the per-branch > > auto-configuration of upstreams. For example, I find myself doing this: > > > > [get an idea, read a bug report on the list, etc] > > $ cd git > > $ hack hack hack > > [oh, this is turning into something real. Let's make a branch] > > $ git checkout -b jk/bug-fix > > $ git commit -m 'fix bug' > > > > but now my bug-fix branch is based off of wherever I was (which is > > usually some private topic-integration branch I run most of the time). > > What in "checkout -b jk/bug-fix" makes jk/bug-fix a downstream of > origin/master? I admit my brain is not working very well today, but I > would have expected the branch to have either your local private topic > integration branch as its @{u}, or no @{u} defined for it at all. Perhaps > there is a design error of some sort around that code? Sorry, reading my example again, I was completely unclear. I was trying to simplify it down to a readable case and ended up omitting the parts that would have it make any sense. So let me try again: I play around with a fix or a feature on top of some random branch. Eventually, I realize that this is a promising direction, and want to make a topic branch. I'm in a state where I have some work-in-progress commits on top of a random point (which yes, means my commits might be totally bogus when ported to origin/master, but in practice, they are close enough). One option would be: $ git checkout -b jk/bug-fix origin/master $ git cherry-pick @{-1}~2..@{-1} which sets up the upstream appropriately. But what I often end up doing is: $ git checkout -b jk/bug-fix $ git rebase -i --onto origin/master HEAD~2 to tweak the patch ordering. Or even: $ git checkout -b jk/bug-fix $ hack hack hack [oops, this should be based on master, not where I was] $ git rebase --onto origin/master HEAD~2 In all three cases, I end up in the same state of history, but only in the first one is my upstream config even remotely useful. There are other variants, too, where I use "stash" and "reset" to end up building on the history I want. Two caveats before I go further: 1. You might argue that the real problem is that I'm building the tentative change somewhere inappropriate. And that is kind of true, and this could all be averted by running "git checkout" in the first place to build on the appropriate spot. Though I do sometimes do that, too: $ git checkout origin/master $ test test test [ok, bug exists] $ fix fix fix [ok, this is worth a topic branch] $ git checkout -b jk/bug-fix and it also does not set up the upstream config. It would if I used a local "master" branch, but I do not have one (and I do not want one, as it would just be a pain to keep in sync with origin/master). 2. I really just want everything based off of origin/master, because that is an implicit part of my workflow for this project. So I am not arguing that what "git checkout -b" does is wrong given the information I have given git, but that there is no place for me to give git that information. So originally, I had a vague notion in my mind that I wanted some way to tell "no, really, I always want to think of origin/master as the upstream unless I explicitly tell you otherwise". Something like: $ git config branch.defaultUpstream refs/remotes/origin/master $ git config branch.autosetupmerge false But having just typed out several examples, I think git _could_ figure this out automatically. My real complaint is that as I use lower-level tools to adjust the basis of my history, the upstream config is not similarly updated. So another option would be: 1. git-rebase could re-adjust the upstream config when using "--onto" with a branch parameter. 2. git-reset could re-adjust the upstream config when moving directly to a branch. 3. When we detach HEAD, remember the original branch name (in .git/ORIGINAL_BRANCH or similar); when a branch is created from the detached HEAD, set up ORIGINAL_BRANCH as the upstream. You'd probably want the "rebase" and "reset" in steps (1) and (2) to update ORIGINAL_BRANCH when you're on a detached HEAD. I think that would perfectly fit my workflow. But I'm not sure if other people would be confused by these operations changing the upstream config (e.g., if you expect "jk/bug-fix" to have an upstream of "origin/jk/bug-fix", when such a change would not be welcome). > > But I think people also use upstream to mean "this is the definitive > > version of this branch in some central repo". So they would say that > > "jk/bug-fix" is based on "origin/jk/bug-fix". And the ahead/behind > > message is about "do I have any local work that needs pushed, or any > > remote work that needs pulled?" > > I think that is the more common interpretation. Earlier you said > ahead/behind gives "some meaning", but compared to this "how many more do > I have, how many more do others have while I was looking the other way", I > am not sure what kind of cue that "some meaning" would give us. If upstream is "here is where my topic is based from", then the ahead/behind tells you how big your topic is (ahead), and whether it might be a candidate for rebasing (behind). If your upstream is "the central repo version of topic", then it tells you what work you have yet to share with others (ahead), and what work others have done on the topic that you could merge (behind). > >> Because "upstream" is meant to be "For the branch I am on, you know > >> how the branches map between the remote repository, so you already > >> know what the right thing to do---do it" mode, the correct "guess" > >> in your case is to error out and say "Nah, you are not talking with > >> your upstream, so I do not have any clue what branches you want to > >> push out and how. As you said that the push.default is upstream, not > >> matching, I refuse to even do the matching push in your case. This > >> is an error. Be more specific". > > > > Yeah, I agree that is the only sane thing to do. > > Perhaps this can be a good sample entry for the experimental "tracker" > thing to keep track of to see how the workflow will evolve around it; > unless neither of us would get to work on it immediately, it is very > likely to be forgotten, as this is a tangent in the overall discussion, > even though the bug is real and solution is clear. I agree this is a candidate for that. But this is where the concept of the tracker breaks down. Who is supposed to update it? You or me? Some volunteer who agrees to migrate email discussion into the tracker? I suspect the latter will not work for a point buried so deeply in a thread. Which leaves you and me. I specifically stayed out of the tracker discussion this time around because all I had to contribute was "please no, web-based tools are an abomination". But now that we see a potential use-case in practice, I am realizing that I would not mind at all making a note in a todo file, or even sending an email. But the thought of filling out a structured problem report to go into a web-based database makes me not want to bother. Perhaps it is just my natural curmudgeonliness, but I think part of it is that I know I am unlikely to actually visit the page to ever retrieve the information. I dunno. -Peff ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [RFC PATCH] push: start warning upcoming default change for push.default 2012-03-14 13:50 ` Jeff King @ 2012-03-14 20:59 ` Junio C Hamano 0 siblings, 0 replies; 116+ messages in thread From: Junio C Hamano @ 2012-03-14 20:59 UTC (permalink / raw) To: Jeff King Cc: Matthieu Moy, Marc Branchaud, Michael Haggerty, Carlos Martín Nieto, git Jeff King <peff@peff.net> writes: > Two caveats before I go further: > > 1. You might argue that the real problem is that I'm building the > tentative change somewhere inappropriate. No, that is completely normal for a developer to start into one direction and then later realize something and change his course. In fact, many parts of Git strive to help you avoid being bound by premature commitments (e.g. "checkout [-m] <branch>" takes local changes with you). I think this discussion is only showing that the @{upstream} part wasn't as carefully designed as other parts of the system. > 2. I really just want everything based off of origin/master, because > that is an implicit part of my workflow for this project. I think this probably shows that "autosetupmerge" mechanism is not polished enough. Perhaps it can take, in addition to "true/false", a ref in refs/remotes namespace, or something. If you have "these branches are to be off of this, this other set of branches are to be off of that", it may need to become more elaborate. > I think that would perfectly fit my workflow. But I'm not sure if other > people would be confused by these operations changing the upstream > config (e.g., if you expect "jk/bug-fix" to have an upstream of > "origin/jk/bug-fix", when such a change would not be welcome). Yeah, the above is starting to sound a bit overengineered black magic. >> Perhaps this can be a good sample entry for the experimental "tracker" >> thing to keep track of to see how the workflow will evolve around it; >> unless neither of us would get to work on it immediately, it is very >> likely to be forgotten, as this is a tangent in the overall discussion, >> even though the bug is real and solution is clear. Heh, I find myself already forgetting what this "clear bug" was and having to look up in your message (the issue is "git push $there" when $there does not match branch.$current.remote, it should error out). > I agree this is a candidate for that. But this is where the concept of > the tracker breaks down. Who is supposed to update it? You or me? Some > volunteer who agrees to migrate email discussion into the tracker? I > suspect the latter will not work for a point buried so deeply in a > thread. Which leaves you and me. That is why I think any demand (I wouldn't call it "proposal" or "suggestion") to this project to use tracker fundamentally is flawed. > I specifically stayed out of the tracker discussion this time around > because all I had to contribute was "please no, web-based tools are an > abomination". But now that we see a potential use-case in practice, I am > realizing that I would not mind at all making a note in a todo file, or > even sending an email. But the thought of filling out a structured > problem report to go into a web-based database makes me not want to > bother. I agree with this 100%. If it takes more than just adding an email address to Cc: line to either a tracker bot or a human project secretary, I cannot be bothered to spend extra 10 minutes to go to an extra web site, log-in and fill the form fields. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [RFC PATCH] push: start warning upcoming default change for push.default 2012-03-12 18:37 ` Jeff King 2012-03-12 19:06 ` Junio C Hamano @ 2012-03-13 9:34 ` Matthieu Moy 2012-03-13 13:17 ` Junio C Hamano 2012-03-13 18:08 ` Dmitry Potapov 2012-03-14 8:59 ` Michael Haggerty 2 siblings, 2 replies; 116+ messages in thread From: Matthieu Moy @ 2012-03-13 9:34 UTC (permalink / raw) To: Jeff King Cc: Marc Branchaud, Michael Haggerty, Carlos Martín Nieto, git, gitster Jeff King <peff@peff.net> writes: > On Mon, Mar 12, 2012 at 05:37:32PM +0100, Matthieu Moy wrote: > >> * For newbies, the sequence "create an empty repository, clone it, >> commit and push" works like a charm with either 'upstream' or >> 'current'. Today, the first push to an empty repository requires >> either saying "git push origin master" or "git push --all", both of >> which sound like black magic to the poor user who did not yet learn >> what 'origin' is and what a branch is. > > Ending that confusion is one of the best reasons to switch the default, > IMHO, but I don't think it argues for "current" versus "upstream", as > they both fix it (but Michael's matching-current hybrid would not, so I > agree it is less appealing). Exactly. It does not change the 'upstream' vs 'current' debate. >> * 'upstream' makes it easy to create a local topic branch, and let >> 'push' send it to the master branch (i.e. have local 'topic-branch' >> pull and push to 'origin/master'). In general, 'upstream' allows >> workflows where you push to branches with either a different name or >> with the same name (by setting the upstream appropriately), but the >> opposite is not true. > > Actually, this is the thing that scares me the most about "upstream" as > a default, because in this case, you are implicitly performing the > equivalent of a fast-forward merge. So that's handy if you are a new > user who wants to publish your work back to the master branch. But that > has two problems: > > 1. If you are a new user who does like the implicit merge, you may > find it convenient not to have to learn about "git checkout; git > merge topic ; git push remote master". But it only helps you > _sometimes_. If master has had other work built on it, your push > will fail, and you will have to do the merge yourself. So it is > only helping you by omitting a step some of the time, and you still > have to learn why the step is sometimes necessary and sometimes > not. There's a rule of thumb which works very well for beginners: when "git push" tells you to pull before, then pull before. This rule of thumb works, but only provided "push" and "pull" are symmetrical. My experience with teaching Git is that this is the number 1 issue with beginners (I'm talking about students who didn't learn CVS/SVN before, so real beginners). They try to push, the push fails, and they come to me saying "Git is broken, we can't work". That's why I introduced the advice about non-fast forward, and later added the mention (e.g. 'git pull') to point users in the right direction when the push fails. It considerably reduced my workload as teacher ;-). Now, if pushing sends commits to a branch other than 'upstream', you can get the following scenario: $ git push To bla ! [rejected] master -> master (non-fast-forward) error: failed to push some refs to 'bla' To prevent you from losing history, non-fast-forward updates were rejected Merge the remote changes (e.g. 'git pull') before pushing again. See the 'Note about fast-forwards' section of 'git push --help' for details. $ git pull Already up-to-date. $ git push <still denied, wtf> One can easily get in this situation even in a kernel-style workflow: work from your desktop, push, work from your laptop, try to push and it fails. Back to my students, most of them will never get in this situation because they won't use branch, so HEAD = master and upstream = origin/master, but the not-so-newbies may get this once they start creating branches ifever they have HEAD = topic-branch and upstream = origin/master for example. > 2. If you are a new user who _doesn't_ want to do the merge, but > instead wants to publish your work-in-progress topic, then the > implicit merge-back-to-master behavior is wrong and dangerous. > You are publishing work that probably violates the general rules > for what goes on master. To me, this is the real argument in favor of 'current'. I think it is less important than others, but that's obviously subjective. In any case, I'm not opposed to 'current', and I think 'current' is a better default than 'matching', but I'm still not convinced it is better than 'upstream'. > Or perhaps somebody else has built on top of master, and your push > fails. If you're an astute reader, you will see that the failing > push tried to go to master. But if you're not, you may retry with > "-f", which is quite dangerous, as now you are not just > accidentally publishing a work-in-progress, but you are > overwriting somebody else's work. Obviously this is a problem > anytime you use "-f", but the fact that your "foo" branch is going > to somewhere besides the remote's "foo" branch makes me think it is > much more likely a clueless user will get confused and overwrite > something on the more "mainstream" branch. I don't think 'current' Vs 'upstream' really changes that. You may get a non-fast forward on your topic branch if you've push to it from another machine for example. > So far a lot of the discussion has focused on "what is the most sensible > default for the most number of people". But I wonder if a better > question is "what is the default that is the least likely to do > something dangerous and embarrassing". I think "what's the most intuitive" is also very important. If we're talking about real, real newbies, the risk of pushing to the wrong branch is marginal compared to the risk of giving up and say "Git doesn't work, I'll send my files by email" (which is real in my experience :'-( ). But your remark does apply to not-totally newbies anymore, but not yet Git gurus. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [RFC PATCH] push: start warning upcoming default change for push.default 2012-03-13 9:34 ` Matthieu Moy @ 2012-03-13 13:17 ` Junio C Hamano 2012-03-13 13:35 ` Matthieu Moy ` (4 more replies) 2012-03-13 18:08 ` Dmitry Potapov 1 sibling, 5 replies; 116+ messages in thread From: Junio C Hamano @ 2012-03-13 13:17 UTC (permalink / raw) To: Matthieu Moy Cc: Jeff King, Marc Branchaud, Michael Haggerty, Carlos Martín Nieto, git Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes: > There's a rule of thumb which works very well for beginners: when "git > push" tells you to pull before, then pull before. This rule of thumb > works, but only provided "push" and "pull" are symmetrical. I actually think the "pull before push again" was written with only CVS style non-branching workflow in mind, in other words, only to help somebody who works on his master against the central master. Obviously "push and pull are symmetrical" holds true for that single branch workflow, but that does not mean a more complex workflow must be symmetrical. Even though I think 'upstream' will be a superset of what 'current' wants to do in an ideal world where the user configures everything right (hence it ought to be the better default between the two), I do not think that the target audience "let's change the default" folks are trying to help is those who set @{upstream} correctly point the destination for a branch they want to push to and leave it unset for a strictly private branch. If we choose the default that would primarily make it efficient for people who can configure everything right, we are missing the point of this discussion. I think the target audience to be helped is the people who do not (yet) do anything complex, and the point of this discussion is to help them avoid getting surprised. And by "surprised", I do not necessarily mean "dangerous". While we should aim to avoid "dangerous", we should avoid "ununderstandable" even more. Pushing 'current' from a branch 'topic' forked from either 'master' or 'origin/master' will create a new branch 'topic' at the central repository. But that is straightforward and understandable. The user will see what happened in the feedback from the command, and there is no need for the user to be experienced enough to know the mapping of @{upstream} to understand why it happened. "I am on 'topic' and I pushed, I created 'topic' there". Very simple explanation exists. On the other hand, the user needs to know not just 'branch' but also understand the concept of @{upstream} in order to use 'upstream' without surprise. When something goes wrong, prerequisite knowledge that is required to understand it is greater. Also the current implementation of 'upstream' has some weird semantics (or undesigned bugs) pointed out by Peff, which would make it even more confusing. That makes me suspect that 'current' might be a more appropriate default between the two. From that simple default, those in the "shared central repository" world can graduate to 'upstream' once they know what an 'upstream' is and how to take advantage of per-branch configuration. Similarly, those in the "publish to be pulled" world would graduate to 'matching'. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [RFC PATCH] push: start warning upcoming default change for push.default 2012-03-13 13:17 ` Junio C Hamano @ 2012-03-13 13:35 ` Matthieu Moy 2012-03-13 20:01 ` Auto-matching upstream branches by name (was: [RFC PATCH] push: start warning upcoming default change for push.default) Stefan Haller 2012-03-13 14:31 ` [RFC PATCH] push: start warning upcoming default change for push.default Marc Branchaud ` (3 subsequent siblings) 4 siblings, 1 reply; 116+ messages in thread From: Matthieu Moy @ 2012-03-13 13:35 UTC (permalink / raw) To: Junio C Hamano Cc: Jeff King, Marc Branchaud, Michael Haggerty, Carlos Martín Nieto, git Junio C Hamano <gitster@pobox.com> writes: > I actually think the "pull before push again" was written with only > CVS style non-branching workflow in mind, in other words, only to > help somebody who works on his master against the central master. It doesn't have much to do with branching/non-branching. You may use branches, and still work collaboratively on them. There was an example above in the same thread: http://thread.gmane.org/gmane.comp.version-control.git/192547/focus=192694 There are also cases like "I pushed from my laptop and I'm back to my desktop", or "the content has been edited from GitHub's web interface". Actually, I hardly see a case where "pull before push again" (with or without --rebase or such) is wrong for a beginner. > Pushing 'current' from a branch 'topic' forked from either 'master' > or 'origin/master' will create a new branch 'topic' at the central > repository. But that is straightforward and understandable. The user > will see what happened in the feedback from the command, and there > is no need for the user to be experienced enough to know the mapping > of @{upstream} to understand why it happened. "I am on 'topic' and > I pushed, I created 'topic' there". Very simple explanation exists. Very simple explanation exist for what "push" does, but not for "the global picture of what push and pull do". And really, the case "Git prevents me from pushing, I don't know what to do" is a problem for people who don't get the whole remote/branch/upstream/... things. Actually, I'm starting to wonder if the whole "upstream" thing should not be deactivated by default, and replaced with a simpler mechanism like "pull.default", similar to what "push.default" does today. Then, users could set "pull.default=current", and "git pull" would pull a branch with the same name remotely. Or users could set "pull.default=upstream" and get what Git does today. But that's a much larger change, then ... -- Matthieu Moy http://www-verimag.imag.fr/~moy/ ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Auto-matching upstream branches by name (was: [RFC PATCH] push: start warning upcoming default change for push.default) 2012-03-13 13:35 ` Matthieu Moy @ 2012-03-13 20:01 ` Stefan Haller 2012-03-14 9:10 ` Auto-matching upstream branches by name Matthieu Moy 0 siblings, 1 reply; 116+ messages in thread From: Stefan Haller @ 2012-03-13 20:01 UTC (permalink / raw) To: Matthieu Moy, Junio C Hamano Cc: Jeff King, Marc Branchaud, Michael Haggerty, Carlos Martín Nieto, git Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote: > Actually, I'm starting to wonder if the whole "upstream" thing should > not be deactivated by default, and replaced with a simpler mechanism > like "pull.default", similar to what "push.default" does today. Then, > users could set "pull.default=current", and "git pull" would pull a > branch with the same name remotely. Or users could set > "pull.default=upstream" and get what Git does today. Yes, this is pretty similar to what I had in mind, in the last paragraph of this message: http://thread.gmane.org/gmane.comp.version-control.git/192547/focus=192694 But it's not just about pull versus push. If you make them both work with same-name branches automatically, you still need to make "status" and "branch -vv" aware of that too, so that they can report whether you are ahead or behind your, well, "upstream". "git log @{u}" would be nice as well in this mode. So I think that "pull.default" is not the best option to use for this; maybe something like "branch.automatchupstreambyname" or some such. (It's really a separate discussion from the push.default question though, so I'm changing the subject.) -- Stefan Haller Berlin, Germany http://www.haller-berlin.de/ ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Auto-matching upstream branches by name 2012-03-13 20:01 ` Auto-matching upstream branches by name (was: [RFC PATCH] push: start warning upcoming default change for push.default) Stefan Haller @ 2012-03-14 9:10 ` Matthieu Moy 0 siblings, 0 replies; 116+ messages in thread From: Matthieu Moy @ 2012-03-14 9:10 UTC (permalink / raw) To: Stefan Haller Cc: Junio C Hamano, Jeff King, Marc Branchaud, Michael Haggerty, Carlos Martín Nieto, git lists@haller-berlin.de (Stefan Haller) writes: > Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote: > >> Actually, I'm starting to wonder if the whole "upstream" thing should >> not be deactivated by default, and replaced with a simpler mechanism >> like "pull.default", similar to what "push.default" does today. Then, >> users could set "pull.default=current", and "git pull" would pull a >> branch with the same name remotely. Or users could set >> "pull.default=upstream" and get what Git does today. > > Yes, this is pretty similar to what I had in mind, in the last paragraph > of this message: > > http://thread.gmane.org/gmane.comp.version-control.git/192547/focus=192694 Indeed, yes. > But it's not just about pull versus push. If you make them both work > with same-name branches automatically, you still need to make "status" > and "branch -vv" aware of that too, so that they can report whether you > are ahead or behind your, well, "upstream". "git log @{u}" would be > nice as well in this mode. > > So I think that "pull.default" is not the best option to use for this; > maybe something like "branch.automatchupstreambyname" or some such. I'd call that 'upstream.default' actually. > (It's really a separate discussion from the push.default question > though, so I'm changing the subject.) Separate, but related. If Git had this behavior as default, I'd recommend 'current' without hesitation. I'm starting to be convinced that the whole 'upstream' stuff is confusing for non-expert, but it is for pull as much as it is for push. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [RFC PATCH] push: start warning upcoming default change for push.default 2012-03-13 13:17 ` Junio C Hamano 2012-03-13 13:35 ` Matthieu Moy @ 2012-03-13 14:31 ` Marc Branchaud 2012-03-13 14:59 ` Holger Hellmuth ` (2 subsequent siblings) 4 siblings, 0 replies; 116+ messages in thread From: Marc Branchaud @ 2012-03-13 14:31 UTC (permalink / raw) To: Junio C Hamano Cc: Matthieu Moy, Jeff King, Michael Haggerty, Carlos Martín Nieto, git On 12-03-13 09:17 AM, Junio C Hamano wrote: > Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes: > >> There's a rule of thumb which works very well for beginners: when "git >> push" tells you to pull before, then pull before. This rule of thumb >> works, but only provided "push" and "pull" are symmetrical. > > I actually think the "pull before push again" was written with only > CVS style non-branching workflow in mind, in other words, only to > help somebody who works on his master against the central master. > Obviously "push and pull are symmetrical" holds true for that single > branch workflow, but that does not mean a more complex workflow must > be symmetrical. > > Even though I think 'upstream' will be a superset of what 'current' > wants to do in an ideal world where the user configures everything > right (hence it ought to be the better default between the two), I > do not think that the target audience "let's change the default" > folks are trying to help is those who set @{upstream} correctly > point the destination for a branch they want to push to and leave it > unset for a strictly private branch. If we choose the default that > would primarily make it efficient for people who can configure > everything right, we are missing the point of this discussion. I > think the target audience to be helped is the people who do not > (yet) do anything complex, and the point of this discussion is to > help them avoid getting surprised. > > And by "surprised", I do not necessarily mean "dangerous". While we > should aim to avoid "dangerous", we should avoid "ununderstandable" > even more. > > Pushing 'current' from a branch 'topic' forked from either 'master' > or 'origin/master' will create a new branch 'topic' at the central > repository. But that is straightforward and understandable. The user > will see what happened in the feedback from the command, and there > is no need for the user to be experienced enough to know the mapping > of @{upstream} to understand why it happened. "I am on 'topic' and > I pushed, I created 'topic' there". Very simple explanation exists. > > On the other hand, the user needs to know not just 'branch' but also > understand the concept of @{upstream} in order to use 'upstream' > without surprise. When something goes wrong, prerequisite knowledge > that is required to understand it is greater. Also the current > implementation of 'upstream' has some weird semantics (or undesigned > bugs) pointed out by Peff, which would make it even more confusing. > > That makes me suspect that 'current' might be a more appropriate > default between the two. From that simple default, those in the > "shared central repository" world can graduate to 'upstream' once > they know what an 'upstream' is and how to take advantage of > per-branch configuration. Similarly, those in the "publish to be > pulled" world would graduate to 'matching'. Good points! I think someone who's figuring out their workflow as they go would appreciate the simplicity offered by "current". You've changed my mind: I now think "current" is the better default. M. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [RFC PATCH] push: start warning upcoming default change for push.default 2012-03-13 13:17 ` Junio C Hamano 2012-03-13 13:35 ` Matthieu Moy 2012-03-13 14:31 ` [RFC PATCH] push: start warning upcoming default change for push.default Marc Branchaud @ 2012-03-13 14:59 ` Holger Hellmuth 2012-03-13 17:41 ` Junio C Hamano 2012-03-13 15:02 ` Andreas Ericsson 2012-03-13 21:35 ` Jeff King 4 siblings, 1 reply; 116+ messages in thread From: Holger Hellmuth @ 2012-03-13 14:59 UTC (permalink / raw) To: Junio C Hamano Cc: Matthieu Moy, Jeff King, Marc Branchaud, Michael Haggerty, Carlos Martín Nieto, git On 13.03.2012 14:17, Junio C Hamano wrote: > that is required to understand it is greater. Also the current > implementation of 'upstream' has some weird semantics (or undesigned > bugs) pointed out by Peff, which would make it even more confusing. If Peff's "push to same branch in a different remote" is a bug (and IMHO it is) it should not count as a reason for what should be the default. One small point in favor of "current" I haven't seen mentioned: It is the smaller/more compatible change from the "matching" behaviour. The most important point for me in the discussion up till now (because it matches my newbie experiences): It doesn't matter that much for new users whether "current" or "upstream" is default, because they mostly work on master and create branches from local master. But in that case the typical situation where the default comes into play will be when they accidentally are on a branch other than master and try to use 'git push'. In that case "current" would push (wrongly) to a similar named branch on the remote while upstream would not because the local branch would have no upstream configured. Small point in favor of "upstream" The symmetry is what really makes me vote for "upstream". Both "upstream" and "current" play to the expectations of new users, "upstream" because of the symmetry and "current" because they usually expect some connection between branches of the same name in different repositories. But only upstream will help those who want to cure git push with git pull. And that would be the whole crowd having just a whiff of experience with cvs or svn. And if I could take a guess, that is the case for the majority of computer science students at a typical university (the rest mostly having no experience with version control at all) By the way, the documentation is very confusing in its description what git push without parameters does. For example it is not really explained in the description or options part, the only explanation is in the Examples. There "git push" points to "git push origin" and: ------------- "git push origin Without additional configuration, works like git push origin :. The default behavior of this command when no <refspec> is given can be configured by setting the push option of the remote. ------------ Now the refspec documentation never says anything about what '.' means (the only docu about refspecs I could find is in pull-fetch-param.txt that is included by git-fetch and git-pull. I thought there was another manpage about refspecs but I couldn't find it). And shouldn't the second sentence above be "... can be configured by setting the push.default option of the remote" ? Is this patchworthy (in that case I'll try to make one) or did I just not read at the right places? ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [RFC PATCH] push: start warning upcoming default change for push.default 2012-03-13 14:59 ` Holger Hellmuth @ 2012-03-13 17:41 ` Junio C Hamano 2012-03-14 19:15 ` Holger Hellmuth 0 siblings, 1 reply; 116+ messages in thread From: Junio C Hamano @ 2012-03-13 17:41 UTC (permalink / raw) To: Holger Hellmuth Cc: Matthieu Moy, Jeff King, Marc Branchaud, Michael Haggerty, Carlos Martín Nieto, git Holger Hellmuth <hellmuth@ira.uka.de> writes: > On 13.03.2012 14:17, Junio C Hamano wrote: >> that is required to understand it is greater. Also the current >> implementation of 'upstream' has some weird semantics (or undesigned >> bugs) pointed out by Peff, which would make it even more confusing. > > If Peff's "push to same branch in a different remote" is a bug (and > IMHO it is) it should not count as a reason for what should be the > default. I may phrased it poorly, but I don't think you mean "if the bug is fixed, then the behaviour of upstream is simple and easy to understand". The very reason the bug exists in the first place is that the semantics that mode wants to give its users is complex enough that even the people who should know (i.e. those who implement it) overlooked that there is a corner case their implementation was not handling. It is a demonstration that upstream is not an easy-to-understand choice to throw at new people. > By the way, the documentation is very confusing in its description > what git push without parameters does. For example it is not really > explained in the description or options part, the only explanation is > in the Examples. There "git push" points to "git push origin" and: > ------------- > "git push origin > Without additional configuration, works like git push origin :. > > The default behavior of this command when no <refspec> is > given can be configured by setting the push option of the > remote. > ------------ > > Now the refspec documentation never says anything about what '.' means > (the only docu about refspecs I could find is in pull-fetch-param.txt That should read: ... works like "git push origin :". That dot you see after the colon is a full-stop for the sentence, not a part of any refspec. > Is this patchworthy (in that case I'll try to make one) or did I just > not read at the right places? It is patch-worthy; you already know that it made you waste time looking for ':.'---the documentation shouldn't have done that. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [RFC PATCH] push: start warning upcoming default change for push.default 2012-03-13 17:41 ` Junio C Hamano @ 2012-03-14 19:15 ` Holger Hellmuth 2012-03-15 8:02 ` Matthieu Moy 0 siblings, 1 reply; 116+ messages in thread From: Holger Hellmuth @ 2012-03-14 19:15 UTC (permalink / raw) To: Junio C Hamano Cc: Matthieu Moy, Jeff King, Marc Branchaud, Michael Haggerty, Carlos Martín Nieto, git On 13.03.2012 18:41, Junio C Hamano wrote: > Holger Hellmuth<hellmuth@ira.uka.de> writes: >> If Peff's "push to same branch in a different remote" is a bug (and >> IMHO it is) it should not count as a reason for what should be the >> default. > > I may phrased it poorly, but I don't think you mean "if the bug is fixed, > then the behaviour of upstream is simple and easy to understand". The I think the behaviour of the whole pull/push system is not easy to understand. One has to learn a lot of concepts about git before being able to answer the simple question "if I do 'git push' now, what happens?". Since I am using git without any collaboration I never had much need to play around with the whole porcelain remote configuration (cloning and using git config was enough). So today I tried to create a bidirectional link between a local and a remote branch using only porcelain commands (i.e. without using git config directly). Somehow I didn't succeed. I can either use git checkout --track or git push -u to make a pull connection between the two, but to automatically push I would have to create a branch of the same name (and know that this is the magical ingredient that makes it work!) Maybe what is missing is a parameter to git-push that tells git that from now on this is what git push should do per default in this branch (Similar to what git checkout --track does). This would mean that even new users could do most remote configuration with just the knowledge of git checkout and git push. By the way I think I found another "hole" in the porcelain: If you add a single branch to follow with git remote add -t <branch> ..., you can't add another. A second git remote add -t <otherbranch> ... will be met with an error that the remote is already configured. I would have to delete the remote and add it again with git add -t <branch> -t <otherbranch> ..... Or use a different remote name (which would be confusing later on). Did I miss something? ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [RFC PATCH] push: start warning upcoming default change for push.default 2012-03-14 19:15 ` Holger Hellmuth @ 2012-03-15 8:02 ` Matthieu Moy 2012-03-15 10:43 ` Holger Hellmuth 0 siblings, 1 reply; 116+ messages in thread From: Matthieu Moy @ 2012-03-15 8:02 UTC (permalink / raw) To: Holger Hellmuth Cc: Junio C Hamano, Jeff King, Marc Branchaud, Michael Haggerty, Carlos Martín Nieto, git Holger Hellmuth <hellmuth@ira.uka.de> writes: > So today I tried to create a > bidirectional link between a local and a remote branch using only > porcelain commands (i.e. without using git config directly). Somehow I > didn't succeed. I can either use git checkout --track or git push -u > to make a pull connection between the two, but to automatically push I > would have to create a branch of the same name (and know that this is > the magical ingredient that makes it work!) In this particular case, having 'push.default=upstream' would have done it for you: your "push -u" would have set up the upstream, and the next "push" would have followed it. (or you could "git push remote local-branch:remote-branch") -- Matthieu Moy http://www-verimag.imag.fr/~moy/ ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [RFC PATCH] push: start warning upcoming default change for push.default 2012-03-15 8:02 ` Matthieu Moy @ 2012-03-15 10:43 ` Holger Hellmuth 0 siblings, 0 replies; 116+ messages in thread From: Holger Hellmuth @ 2012-03-15 10:43 UTC (permalink / raw) To: Matthieu Moy Cc: Junio C Hamano, Jeff King, Marc Branchaud, Michael Haggerty, Carlos Martín Nieto, git On 15.03.2012 09:02, Matthieu Moy wrote: > Holger Hellmuth<hellmuth@ira.uka.de> writes: > >> So today I tried to create a >> bidirectional link between a local and a remote branch using only >> porcelain commands (i.e. without using git config directly). Somehow I >> didn't succeed. I can either use git checkout --track or git push -u >> to make a pull connection between the two, but to automatically push I >> would have to create a branch of the same name (and know that this is >> the magical ingredient that makes it work!) > > In this particular case, having 'push.default=upstream' would have done > it for you: your "push -u" would have set up the upstream, and the next > "push" would have followed it. I know, this is why I voted for "upstream", but there are good reasons for "current" too. Whatever is decided on will still get some users by surprise. > (or you could "git push remote local-branch:remote-branch") > Sure, I can believe that a new user will be able to get at that line after studying the "git push" manual page (or reading a tutorial), but I really doubt he will easily find out where to go from there to simplify that line. And typing that line every time for a permanent connection is out of the question, right? That is why I think git push --track remote local-branch:remote-branch (or --permanent, --perm, --follow, --configure, --keep) would be a great help because a tutorial wouldn't have to talk about a lot of special cases, config options, it could just explain: ----------------------------- 1) To follow a remote repository do "git remote add <repo> <url> 2) To follow a remote branch do "git checkout [-b localbranch] --track <repo>/<branch>. Then "git pull" while in this branch will synchronize you whenever you want to be up-to-date. 3) To get a remote branch to follow you do "git push --track <repo> <local-branch>:<branch> once. Then "git push" while in this branch will synchronize the remote branch. ----------------------------- With this simple recipe 90% of all workflows could be configured by a novice without embarrasing himself. Can you find a similar simple and consise recipe that would work today (even with upstream or current) ? I doubt it. Sorry about opening up another tangent, but this is somewhat connected. If we give the novice an easy instrument to configure what he really wants then the default becomes much less important. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [RFC PATCH] push: start warning upcoming default change for push.default 2012-03-13 13:17 ` Junio C Hamano ` (2 preceding siblings ...) 2012-03-13 14:59 ` Holger Hellmuth @ 2012-03-13 15:02 ` Andreas Ericsson 2012-03-13 21:35 ` Jeff King 4 siblings, 0 replies; 116+ messages in thread From: Andreas Ericsson @ 2012-03-13 15:02 UTC (permalink / raw) To: Junio C Hamano Cc: Matthieu Moy, Jeff King, Marc Branchaud, Michael Haggerty, Carlos Martín Nieto, git On 03/13/2012 02:17 PM, Junio C Hamano wrote: > Matthieu Moy<Matthieu.Moy@grenoble-inp.fr> writes: > >> There's a rule of thumb which works very well for beginners: when "git >> push" tells you to pull before, then pull before. This rule of thumb >> works, but only provided "push" and "pull" are symmetrical. > > I actually think the "pull before push again" was written with only > CVS style non-branching workflow in mind, in other words, only to > help somebody who works on his master against the central master. > Obviously "push and pull are symmetrical" holds true for that single > branch workflow, but that does not mean a more complex workflow must > be symmetrical. > > Even though I think 'upstream' will be a superset of what 'current' > wants to do in an ideal world where the user configures everything > right (hence it ought to be the better default between the two), I > do not think that the target audience "let's change the default" > folks are trying to help is those who set @{upstream} correctly > point the destination for a branch they want to push to and leave it > unset for a strictly private branch. If we choose the default that > would primarily make it efficient for people who can configure > everything right, we are missing the point of this discussion. I > think the target audience to be helped is the people who do not > (yet) do anything complex, and the point of this discussion is to > help them avoid getting surprised. > > And by "surprised", I do not necessarily mean "dangerous". While we > should aim to avoid "dangerous", we should avoid "ununderstandable" > even more. > > Pushing 'current' from a branch 'topic' forked from either 'master' > or 'origin/master' will create a new branch 'topic' at the central > repository. But that is straightforward and understandable. The user > will see what happened in the feedback from the command, and there > is no need for the user to be experienced enough to know the mapping > of @{upstream} to understand why it happened. "I am on 'topic' and > I pushed, I created 'topic' there". Very simple explanation exists. > > On the other hand, the user needs to know not just 'branch' but also > understand the concept of @{upstream} in order to use 'upstream' > without surprise. When something goes wrong, prerequisite knowledge > that is required to understand it is greater. Also the current > implementation of 'upstream' has some weird semantics (or undesigned > bugs) pointed out by Peff, which would make it even more confusing. > > That makes me suspect that 'current' might be a more appropriate > default between the two. From that simple default, those in the > "shared central repository" world can graduate to 'upstream' once > they know what an 'upstream' is and how to take advantage of > per-branch configuration. Similarly, those in the "publish to be > pulled" world would graduate to 'matching'. Sensible sentiments, sir. Even with advanced usage, 'current' is what I think does the right thing in 99% of all cases, and it errs on the side of "least extra work when things go wrong". The questions to ask, I think, are these: * What would newcomers to git expect? You answered this nicely. * What does advanced users use *most of the time*? At $dayjob, 99.9% of all pushes are to get the changes of the current branch to the sharepoint repo. Once in a while (when tagging, usually whatnot) for some repositories, I wish to push maint and master to a public repository for the masses to use. This happens roughly once every 200 commits, according to a quick "git log" in two repos, but only for about 10 or so of the 60-odd repos we're maintaining, and only for two of the six developers working on them. It's very rare that I work on multiple already-created topics and they all finish at the same time. At most, I wish to push "maint" and "master" in one go. If I notice I've done the bad push, I need to make sure noone else fetched the thing during the time it takes me to undo the push, or I may have to quickly fix up the potentially broken branch. Either way, it can be a lot of work that I rarely have time for right then. * What causes the least damage when the default is less suitable? Quite a few times I've managed to push work-in-progress commits to random topics at work with the default "matching". If I miss that I've done so, undoing the damage is a great big pain in the butt, since it means either force-pushing to sharepoint or un-bisectable commits. The worst case for "current" would be if I merge one branch to master, forget to push the merged branch but do push 'master' to our sharepoint, and then someone else comes along and works a bit more on the topic I accidentally didn't push. When that happens, I can quite easily rebase my changes on top of the other devs, or merge with the sharepoint changes, and then re-merge to master without having to call a flag-day for the devs working on the same project. If I notice I've forgotten to push, I can just push again immediately and git will handle any errors for me. It never leads to any extra work for me, and never stalls anyone else from progressing with their own tasks. In light of that, "current" is really the only sensible way to go. -- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [RFC PATCH] push: start warning upcoming default change for push.default 2012-03-13 13:17 ` Junio C Hamano ` (3 preceding siblings ...) 2012-03-13 15:02 ` Andreas Ericsson @ 2012-03-13 21:35 ` Jeff King 4 siblings, 0 replies; 116+ messages in thread From: Jeff King @ 2012-03-13 21:35 UTC (permalink / raw) To: Junio C Hamano Cc: Matthieu Moy, Marc Branchaud, Michael Haggerty, Carlos Martín Nieto, git On Tue, Mar 13, 2012 at 06:17:13AM -0700, Junio C Hamano wrote: > Pushing 'current' from a branch 'topic' forked from either 'master' > or 'origin/master' will create a new branch 'topic' at the central > repository. But that is straightforward and understandable. The user > will see what happened in the feedback from the command, and there > is no need for the user to be experienced enough to know the mapping > of @{upstream} to understand why it happened. "I am on 'topic' and > I pushed, I created 'topic' there". Very simple explanation exists. > [...] > That makes me suspect that 'current' might be a more appropriate > default between the two. From that simple default, those in the > "shared central repository" world can graduate to 'upstream' once > they know what an 'upstream' is and how to take advantage of > per-branch configuration. Similarly, those in the "publish to be > pulled" world would graduate to 'matching'. Thanks for this explanation. When writing my last email, I had a gut feeling about how "current" was a simpler choice, but I didn't quite find the words to explain it. This paragraph (and the rest of the email) covers what I was trying to say. -Peff ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [RFC PATCH] push: start warning upcoming default change for push.default 2012-03-13 9:34 ` Matthieu Moy 2012-03-13 13:17 ` Junio C Hamano @ 2012-03-13 18:08 ` Dmitry Potapov 2012-03-14 4:46 ` Junio C Hamano 2012-03-14 9:07 ` Matthieu Moy 1 sibling, 2 replies; 116+ messages in thread From: Dmitry Potapov @ 2012-03-13 18:08 UTC (permalink / raw) To: Matthieu Moy Cc: Jeff King, Marc Branchaud, Michael Haggerty, Carlos Martín Nieto, git, gitster On Tue, Mar 13, 2012 at 1:34 PM, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote: > Jeff King <peff@peff.net> writes: > >> 1. If you are a new user who does like the implicit merge, you may >> find it convenient not to have to learn about "git checkout; git >> merge topic ; git push remote master". But it only helps you >> _sometimes_. If master has had other work built on it, your push >> will fail, and you will have to do the merge yourself. So it is >> only helping you by omitting a step some of the time, and you still >> have to learn why the step is sometimes necessary and sometimes >> not. > > There's a rule of thumb which works very well for beginners: when "git > push" tells you to pull before, then pull before. This rule of thumb > works, but only provided "push" and "pull" are symmetrical. I am not sure what you mean by symmetrical here, because they are never truly symmetrical as "pull" does merge and "push" does not. If there is a centralized workflow with only one branch then everything is simple, but it is not so with other workflows. Moreover, doing 'git pull' too often (unless it is 'git pull --rebase) pollutes history with useless merges, making more difficult to review changes, or doing git-bisect. > Now, if pushing sends commits to a branch other than 'upstream', you can > get the following scenario: > > $ git push > To bla > ! [rejected] master -> master (non-fast-forward) > error: failed to push some refs to 'bla' I agree that the current diagnostic is not suitable for beginners. Not-fast-forward push is something that beginners should never use, but from this message is not clear what is the alternative to forcing non-fast-forward push. > One can easily get in this situation even in a kernel-style workflow: > work from your desktop, push, work from your laptop, try to push and it > fails. IMHO, when you often switch between your desktop and laptop, 'matching' makes much more sense. If 'push' fails then usually I want to force non- fast-forward push, because the new series contain reworked patches that already were on the other computer. > > Back to my students, most of them will never get in this situation > because they won't use branch, so HEAD = master and upstream = > origin/master, So, there is no real difference between 'current' and 'upstream' for them. > but the not-so-newbies may get this once they start > creating branches ifever they have HEAD = topic-branch and upstream = > origin/master for example. The real question is what one expects from 'push' in that situation. It could be pushing this branch back to the upstream branch or creating a new feature branch in the upstream. > >> So far a lot of the discussion has focused on "what is the most sensible >> default for the most number of people". But I wonder if a better >> question is "what is the default that is the least likely to do >> something dangerous and embarrassing". > > I think "what's the most intuitive" is also very important. But it depends on the workflow that is employed by the project. Different projects may have different workflows. We can assume that the person who sets up the repository has good knowledge of Git and how to use it, but many others who work on the same project may not know Git well. For them "the most intuitive" means whatever policy this project has. Dmitry ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [RFC PATCH] push: start warning upcoming default change for push.default 2012-03-13 18:08 ` Dmitry Potapov @ 2012-03-14 4:46 ` Junio C Hamano 2012-03-14 12:47 ` Dmitry Potapov 2012-03-14 9:07 ` Matthieu Moy 1 sibling, 1 reply; 116+ messages in thread From: Junio C Hamano @ 2012-03-14 4:46 UTC (permalink / raw) To: Dmitry Potapov Cc: Matthieu Moy, Jeff King, Marc Branchaud, Michael Haggerty, Carlos Martín Nieto, git, gitster Dmitry Potapov <dpotapov@gmail.com> writes: >> One can easily get in this situation even in a kernel-style workflow: >> work from your desktop, push, work from your laptop, try to push and it >> fails. > > IMHO, when you often switch between your desktop and laptop, 'matching' > makes much more sense. If 'push' fails then usually I want to force non- > fast-forward push, because the new series contain reworked patches that > already were on the other computer. You are free to live dangerously, but please do not teach that to other people. Switching between two machines A and B is done a lot more safely if you arrange them to cross pull from each other, i.e. on machine A, remotes/B/* is where you keep copies of branches of B to with either of these machineA$ git fetch B refs/heads/*:refs/remotes/B/* machineB$ git push A refs/heads/*:refs/remotes/B/* (the latter is to emulate the former "fetch" you wish to run on A to get data from B in the reverse direction), and similarly on machine B, you use remotes/A/* to keep copies of branches of A. That way, the risk of losing your work because the "usually" in your "then usually I want to force" turns out to be untrue is greatly reduced. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [RFC PATCH] push: start warning upcoming default change for push.default 2012-03-14 4:46 ` Junio C Hamano @ 2012-03-14 12:47 ` Dmitry Potapov 2012-03-14 17:29 ` Junio C Hamano 0 siblings, 1 reply; 116+ messages in thread From: Dmitry Potapov @ 2012-03-14 12:47 UTC (permalink / raw) To: Junio C Hamano Cc: Matthieu Moy, Jeff King, Marc Branchaud, Michael Haggerty, Carlos Martín Nieto, git On Wed, Mar 14, 2012 at 8:46 AM, Junio C Hamano <gitster@pobox.com> wrote: > Dmitry Potapov <dpotapov@gmail.com> writes: > >>> One can easily get in this situation even in a kernel-style workflow: >>> work from your desktop, push, work from your laptop, try to push and it >>> fails. >> >> IMHO, when you often switch between your desktop and laptop, 'matching' >> makes much more sense. If 'push' fails then usually I want to force non- >> fast-forward push, because the new series contain reworked patches that >> already were on the other computer. > > You are free to live dangerously, but please do not teach that to other > people. Is it more dangerous than using "git reset --hard somewhere" ? I believe both cases I should be able to recover the lost using reflog. Anyway, so far I have never had any problem, because I do "git push" first and then look at failures and decide whether I want to discard the old series on the remote end. > Switching between two machines A and B is done a lot more safely if you > arrange them to cross pull from each other, i.e. on machine A, remotes/B/* > is where you keep copies of branches of B to with either of these > > machineA$ git fetch B refs/heads/*:refs/remotes/B/* > machineB$ git push A refs/heads/*:refs/remotes/B/* > > (the latter is to emulate the former "fetch" you wish to run on A to get > data from B in the reverse direction), and similarly on machine B, you use > remotes/A/* to keep copies of branches of A. I am aware about that, but the thing that stops me from using this is there is no way to delete automatically all references from the remote end that were deleted locally. (There is --mirror option, which can do this, but it is incompatible with refspecs) If I use only "git fetch B ...", I can run "git remote prune B" from time to time to remove branches that no longer exists on B. However, if I do "git push A ..." as you suggested then A will accumulate old garabage from B very quickly. Dmitry ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [RFC PATCH] push: start warning upcoming default change for push.default 2012-03-14 12:47 ` Dmitry Potapov @ 2012-03-14 17:29 ` Junio C Hamano 2012-03-14 17:49 ` Dmitry Potapov 0 siblings, 1 reply; 116+ messages in thread From: Junio C Hamano @ 2012-03-14 17:29 UTC (permalink / raw) To: Dmitry Potapov Cc: Matthieu Moy, Jeff King, Marc Branchaud, Michael Haggerty, Carlos Martín Nieto, git Dmitry Potapov <dpotapov@gmail.com> writes: > ... However, if I do > "git push A ..." as you suggested then A will accumulate old garabage > from B very quickly. That is not a valid excuse, is it? It only shows that lack of "push --prune A" is a problem to be solved. And hasn't it been solved already? ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [RFC PATCH] push: start warning upcoming default change for push.default 2012-03-14 17:29 ` Junio C Hamano @ 2012-03-14 17:49 ` Dmitry Potapov 2012-03-14 20:44 ` Junio C Hamano 0 siblings, 1 reply; 116+ messages in thread From: Dmitry Potapov @ 2012-03-14 17:49 UTC (permalink / raw) To: Junio C Hamano Cc: Matthieu Moy, Jeff King, Marc Branchaud, Michael Haggerty, Carlos Martín Nieto, git On Wed, Mar 14, 2012 at 9:29 PM, Junio C Hamano <gitster@pobox.com> wrote: > Dmitry Potapov <dpotapov@gmail.com> writes: > >> ... However, if I do >> "git push A ..." as you suggested then A will accumulate old garabage >> from B very quickly. > > That is not a valid excuse, is it? Maybe not, but so far I have never had any problem with the way I use now. So I have not had any real insensitive to change that. Though I agree that what you proposed is better except pruning deleted branches. > It only shows that lack of "push --prune A" is a problem to be solved. > > And hasn't it been solved already? > Has it? Somehow I cannot find the corresponding option in the manual. What did I miss? Dmitry ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [RFC PATCH] push: start warning upcoming default change for push.default 2012-03-14 17:49 ` Dmitry Potapov @ 2012-03-14 20:44 ` Junio C Hamano 0 siblings, 0 replies; 116+ messages in thread From: Junio C Hamano @ 2012-03-14 20:44 UTC (permalink / raw) To: Dmitry Potapov Cc: Matthieu Moy, Jeff King, Marc Branchaud, Michael Haggerty, Carlos Martín Nieto, git Dmitry Potapov <dpotapov@gmail.com> writes: >> It only shows that lack of "push --prune A" is a problem to be solved. >> >> And hasn't it been solved already? > > Has it? Somehow I cannot find the corresponding option in the manual. > What did I miss? What you are missing is that you are not running 1.7.10-rc to help shaking out last minute regressions. Please be a good resident on this list and help us out ;-) ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [RFC PATCH] push: start warning upcoming default change for push.default 2012-03-13 18:08 ` Dmitry Potapov 2012-03-14 4:46 ` Junio C Hamano @ 2012-03-14 9:07 ` Matthieu Moy 2012-03-14 13:23 ` Dmitry Potapov 1 sibling, 1 reply; 116+ messages in thread From: Matthieu Moy @ 2012-03-14 9:07 UTC (permalink / raw) To: Dmitry Potapov Cc: Jeff King, Marc Branchaud, Michael Haggerty, Carlos Martín Nieto, git, gitster Dmitry Potapov <dpotapov@gmail.com> writes: > On Tue, Mar 13, 2012 at 1:34 PM, Matthieu Moy > <Matthieu.Moy@grenoble-inp.fr> wrote: >> Jeff King <peff@peff.net> writes: >> >>> 1. If you are a new user who does like the implicit merge, you may >>> find it convenient not to have to learn about "git checkout; git >>> merge topic ; git push remote master". But it only helps you >>> _sometimes_. If master has had other work built on it, your push >>> will fail, and you will have to do the merge yourself. So it is >>> only helping you by omitting a step some of the time, and you still >>> have to learn why the step is sometimes necessary and sometimes >>> not. >> >> There's a rule of thumb which works very well for beginners: when "git >> push" tells you to pull before, then pull before. This rule of thumb >> works, but only provided "push" and "pull" are symmetrical. > > I am not sure what you mean by symmetrical here, because they are never > truly symmetrical as "pull" does merge and "push" does not. I mean "they work with the same branch". > If there is a centralized workflow with only one branch then > everything is simple, but it is not so with other workflows. I don't get this. With either 'current' or 'upstream', both pull and push deal with one local and one remote branch. The only asymetry is the case of non-fast forward (push fails, pull merges). But it's all about transmitting changes from a branch to another, in one or another direction. > Moreover, doing 'git pull' too often (unless it is 'git pull --rebase) > pollutes history with useless merges, making more difficult to review > changes, or doing git-bisect. What's your point here? How does it invalidate the rule of thumb above? Whether you want to pull often or not, it does not change the fact that you cannot do non-fast forward push (at least, not without losing history). If the user tried to push, what would you suggest if not pulling (or merging in whatever way you want)? Blame the user who wanted to push that he shouldn't have tried that? > I agree that the current diagnostic is not suitable for beginners. > Not-fast-forward push is something that beginners should never use, > but from this message is not clear what is the alternative to forcing > non-fast-forward push. Again, what would you suggest? Teach --force to beginners? >> One can easily get in this situation even in a kernel-style workflow: >> work from your desktop, push, work from your laptop, try to push and it >> fails. > > IMHO, when you often switch between your desktop and laptop, 'matching' > makes much more sense. Then, if you worked on branch 'foo' from your desktop, and 'bar' on your laptop, you'll get errors about non-fast forward push from both machines. > If 'push' fails then usually I want to force non- fast-forward push, > because the new series contain reworked patches that already were on > the other computer. ... but if they were not, you've just silently errased your previous work. I have no problem with you working like this, but please don't teach that to beginners. >> but the not-so-newbies may get this once they start >> creating branches ifever they have HEAD = topic-branch and upstream = >> origin/master for example. > > The real question is what one expects from 'push' in that situation. It > could be pushing this branch back to the upstream branch or creating a > new feature branch in the upstream. Yes. But both of them are covered by 'push.default=upstream', depending on how you configured the upstream. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [RFC PATCH] push: start warning upcoming default change for push.default 2012-03-14 9:07 ` Matthieu Moy @ 2012-03-14 13:23 ` Dmitry Potapov 2012-03-14 14:47 ` Matthieu Moy 0 siblings, 1 reply; 116+ messages in thread From: Dmitry Potapov @ 2012-03-14 13:23 UTC (permalink / raw) To: Matthieu Moy Cc: Jeff King, Marc Branchaud, Michael Haggerty, Carlos Martín Nieto, git, gitster On Wed, Mar 14, 2012 at 1:07 PM, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote: > Dmitry Potapov <dpotapov@gmail.com> writes: > >> If there is a centralized workflow with only one branch then >> everything is simple, but it is not so with other workflows. > > I don't get this. With either 'current' or 'upstream', both pull and > push deal with one local and one remote branch. The only asymetry is the > case of non-fast forward (push fails, pull merges). But it's all about > transmitting changes from a branch to another, in one or another > direction. If a user has 'master' after cloning and then create another branch with different names, are you sure that the user expects that this second branch to be pushed to a remote 'master'? And then what about his stale local 'master'? Those who understand the concept tracking may be happy with 'upstream' but when it comes to the least surprise principle for beginner , I believe 'current' is better. Maybe it would be even better if it did not create a new remote branch without asking first: Staying on foo-branch, you do: $ git push Warning: foo-branch does not exist on the remote, if you want to create it, type: "git push foo-branch" In this way, it will be safer. > >> Moreover, doing 'git pull' too often (unless it is 'git pull --rebase) >> pollutes history with useless merges, making more difficult to review >> changes, or doing git-bisect. > > What's your point here? How does it invalidate the rule of thumb above? The point is that you still need to understand what you are doing. It is not 'pull' magically resolve the problem. On the other hand, if you really want a workflow similar to CVS then you need "git pull --rebase" (you can configure 'pull' to do rebase by default, but beginners do not know about it). BTW, whether you do merge or rebase, you still need to test the result before pushing. Even if there was no conflicts, it may not work anymore. And while you are merging and testing everything, somebody else could push his changes. So, a centralized workflow may appear simple, but it does not scale well, and often leads to many untested and hastily merged commits. >> I agree that the current diagnostic is not suitable for beginners. >> Not-fast-forward push is something that beginners should never use, >> but from this message is not clear what is the alternative to forcing >> non-fast-forward push. > > Again, what would you suggest? Teach --force to beginners? Not of course. I said above non-fast forward push should not be used by beginners. However, if you have branches and merge them (using 'pull' or 'merge'), it is silly pretend that they do not exist. If you happy with CVS-like behavior then just do "pull --rebase". > >>> One can easily get in this situation even in a kernel-style workflow: >>> work from your desktop, push, work from your laptop, try to push and it >>> fails. >> >> IMHO, when you often switch between your desktop and laptop, 'matching' >> makes much more sense. > > Then, if you worked on branch 'foo' from your desktop, and 'bar' on your > laptop, you'll get errors about non-fast forward push from both machines. Right... and then I look at the cause, and usually I have made some minor fixes to some series of patches. So when I make my mind, I do non-fast forward push, but I do not think it is how beginners should start to use 'git'. > >> If 'push' fails then usually I want to force non- fast-forward push, >> because the new series contain reworked patches that already were on >> the other computer. > > ... but if they were not, you've just silently errased your previous > work. I have no problem with you working like this, but please don't > teach that to beginners. Basically, it is same as doing 'git reset --hard somewhere'. I use it sometimes, but I have never suggested that for beginners... Dmitry ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [RFC PATCH] push: start warning upcoming default change for push.default 2012-03-14 13:23 ` Dmitry Potapov @ 2012-03-14 14:47 ` Matthieu Moy 2012-03-14 17:47 ` Dmitry Potapov 0 siblings, 1 reply; 116+ messages in thread From: Matthieu Moy @ 2012-03-14 14:47 UTC (permalink / raw) To: Dmitry Potapov Cc: Jeff King, Marc Branchaud, Michael Haggerty, Carlos Martín Nieto, git, gitster Dmitry Potapov <dpotapov@gmail.com> writes: > Not of course. I said above non-fast forward push should not be used by > beginners. Do you mean "beginners should not force non-fast forward push", or "beginners should not use flow where push may be denied because of non-fast forward"? If the second, this implies that beginners should never have a shared repository, either shared for one user and multiple machines, or shared between developers? If you mean that shared repositories are too complex for beginners, my experience is exactly the opposite. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [RFC PATCH] push: start warning upcoming default change for push.default 2012-03-14 14:47 ` Matthieu Moy @ 2012-03-14 17:47 ` Dmitry Potapov 2012-03-15 8:05 ` Matthieu Moy 0 siblings, 1 reply; 116+ messages in thread From: Dmitry Potapov @ 2012-03-14 17:47 UTC (permalink / raw) To: Matthieu Moy Cc: Jeff King, Marc Branchaud, Michael Haggerty, Carlos Martín Nieto, git, gitster On Wed, Mar 14, 2012 at 6:47 PM, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote: > Dmitry Potapov <dpotapov@gmail.com> writes: > >> Not of course. I said above non-fast forward push should not be used by >> beginners. > > Do you mean "beginners should not force non-fast forward push", or > "beginners should not use flow where push may be denied because of > non-fast forward"? Of course, the former. I have never said that the centralized workflow should never been used. I have only said that it is not scalable and lead to problems in larger projects. > If the second, this implies that beginners should never have a shared > repository, Well, you can set up a shared repository where everyone has their own namespaces to push. I don't say that that it is better than having one public repository per user, but it may be easier to setup... So it only implies that you cannot have a centralized workflow in this way. > either shared for one user and multiple machines, or shared > between developers? I am not sure that I understood this part. > If you mean that shared repositories are too complex for beginners, my > experience is exactly the opposite. It is not too complex but it is wrong for any more or less serious project. Git is flexible enough to cover different workflows, including some variant of a centralized workflow, but git was not designed with the centralized workflow in mind. So some trade-offs are different in it than in VCS that were designed primary (if not only) to be used with a centralized workflow. IMHO if you teach git then you should teach a distributed workflow, because it is the workflow where advantages of git is most obvious... Dmitry ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [RFC PATCH] push: start warning upcoming default change for push.default 2012-03-14 17:47 ` Dmitry Potapov @ 2012-03-15 8:05 ` Matthieu Moy 0 siblings, 0 replies; 116+ messages in thread From: Matthieu Moy @ 2012-03-15 8:05 UTC (permalink / raw) To: Dmitry Potapov Cc: Jeff King, Marc Branchaud, Michael Haggerty, Carlos Martín Nieto, git, gitster Dmitry Potapov <dpotapov@gmail.com> writes: > On Wed, Mar 14, 2012 at 6:47 PM, Matthieu Moy > <Matthieu.Moy@grenoble-inp.fr> wrote: >> Dmitry Potapov <dpotapov@gmail.com> writes: >> >>> Not of course. I said above non-fast forward push should not be used by >>> beginners. >> >> Do you mean "beginners should not force non-fast forward push", or >> "beginners should not use flow where push may be denied because of >> non-fast forward"? > > Of course, the former. I have never said that the centralized workflow > should never been used. I have only said that it is not scalable and > lead to problems in larger projects. Then I don't follow you. The starting point of the discussion was my rule of thumb about push/pull: | There's a rule of thumb which works very well for beginners: when "git | push" tells you to pull before, then pull before. This rule of thumb | works, but only provided "push" and "pull" are symmetrical. I can rephrase the end as "... provided 'push' pushes to the same branch 'pull' pulls from" (i.e. provided push.default=upstream). Can you explain what you disagree with here? Or do you actually agree with it? Then, I showed the message of "git push" in the non-fast forward case, which suggests that the user should pull, and you said: | I agree that the current diagnostic is not suitable for beginners. Again, what do you mean? What diagnosis would you suggest, if not pulling? >> either shared for one user and multiple machines, or shared >> between developers? > > I am not sure that I understood this part. I mean that a repository can be shared because multiple developers have acces to it, or because the same developer has several clones. >> If you mean that shared repositories are too complex for beginners, my >> experience is exactly the opposite. > > It is not too complex but it is wrong for any more or less serious > project. I never argued against distributed development. I'm saying that centralized development also makes sense, especially with beginners. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [RFC PATCH] push: start warning upcoming default change for push.default 2012-03-12 18:37 ` Jeff King 2012-03-12 19:06 ` Junio C Hamano 2012-03-13 9:34 ` Matthieu Moy @ 2012-03-14 8:59 ` Michael Haggerty 2012-03-14 14:00 ` Jeff King 2 siblings, 1 reply; 116+ messages in thread From: Michael Haggerty @ 2012-03-14 8:59 UTC (permalink / raw) To: Jeff King Cc: Matthieu Moy, Marc Branchaud, Carlos Martín Nieto, git, gitster On 03/12/2012 07:37 PM, Jeff King wrote: > On Mon, Mar 12, 2012 at 05:37:32PM +0100, Matthieu Moy wrote: >> * For newbies, the sequence "create an empty repository, clone it, >> commit and push" works like a charm with either 'upstream' or >> 'current'. Today, the first push to an empty repository requires >> either saying "git push origin master" or "git push --all", both of >> which sound like black magic to the poor user who did not yet learn >> what 'origin' is and what a branch is. > > Ending that confusion is one of the best reasons to switch the default, > IMHO, but I don't think it argues for "current" versus "upstream", as > they both fix it (but Michael's matching-current hybrid would not, so I > agree it is less appealing). In the case of my proposed matching-current hybrid, the error message for the failing push would make it pretty obvious what went wrong and how to fix it; something like: $ git push The remote repository "git.example.com:myproject" does not yet contain a branch called "master". If you would like to create one now, type git push origin master For other alternatives, please see gitworkflows(7). This error message would appear *whenever* the matching-current hybrid policy caused the push to fail. Since this problem occurs only if (1) the upstream repository is empty and (2) the user hasn't configured a more liberal global push.default, and since it is blindingly obvious what to do to fix the problem, it doesn't seem especially onerous. (One could even create a special-case to allow such a push when the upstream repository is empty, but I don't think the gain in convenience is worth the loss of consistency.) > So far a lot of the discussion has focused on "what is the most sensible > default for the most number of people". But I wonder if a better > question is "what is the default that is the least likely to do > something dangerous and embarrassing". People who use git enough to say > "wow, I don't like this default for my workflow" are probably at the > point that they can configure push.default themselves. I agree entirely. And here is an algorithm for deciding what the default should be: 1. Make a list of branch configurations that can be distinguished by git, which would be something like all combinations of * remote has a branch with the same name as the current branch? * no * yes, and remote branch could be fast-forwarded to local state * yes, but remote branch cannot be fast-forwarded to local state * local branch has known upstream branch on remote? * no * yes, and remote upstream branch could be fast-forwarded to the state of the current local branch * yes, but remote upstream branch cannot be fast-forwarded to the state of the current local branch 2. In each of these situations, decide what "git push" should do in each of the common workflows. 3. In the branching configurations for which all workflows agree about what "git push" should do, then that is what "git push" should do by default. When they do not agree, then "git push" should do nothing, give an informative error message, and leave it to the user to decide. If all workflows agree on a safe subset of what "git push" should do (for example, "matching" and "current" agree that the current branch should be pushed even though they disagree whether other branches should be pushed), then it might be OK to carry out the safe subset. The most common workflows, along with the configuration settings that are recommended for that workflow, should be given standard names and documented in gitworkflows(7). The warning message for a failed "git push" invocations (especially if push.default is unset) should direct the user to this manpage. Isn't it obvious?: The fact that we cannot even agree among ourselves what "git push" should do in all cases *proves* that we are trying to be too ambitious with DWIM. "git push" must therefore become more deferential when the obvious thing to do is unclear, especially given that mistakes (due to the very nature of "git push") often have embarrassing and publicly visible effects. Michael -- Michael Haggerty mhagger@alum.mit.edu http://softwareswirl.blogspot.com/ ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [RFC PATCH] push: start warning upcoming default change for push.default 2012-03-14 8:59 ` Michael Haggerty @ 2012-03-14 14:00 ` Jeff King 0 siblings, 0 replies; 116+ messages in thread From: Jeff King @ 2012-03-14 14:00 UTC (permalink / raw) To: Michael Haggerty Cc: Matthieu Moy, Marc Branchaud, Carlos Martín Nieto, git, gitster On Wed, Mar 14, 2012 at 09:59:04AM +0100, Michael Haggerty wrote: > > Ending that confusion is one of the best reasons to switch the default, > > IMHO, but I don't think it argues for "current" versus "upstream", as > > they both fix it (but Michael's matching-current hybrid would not, so I > > agree it is less appealing). > > In the case of my proposed matching-current hybrid, the error message > for the failing push would make it pretty obvious what went wrong and > how to fix it; something like: > > $ git push > The remote repository "git.example.com:myproject" does not yet > contain a branch called "master". If you would like to create one > now, type > > git push origin master > > For other alternatives, please see gitworkflows(7). > > This error message would appear *whenever* the matching-current hybrid > policy caused the push to fail. Since this problem occurs only if (1) > the upstream repository is empty and (2) the user hasn't configured a > more liberal global push.default, and since it is blindingly obvious > what to do to fix the problem, it doesn't seem especially onerous. Thanks for the clarification. That does go a long way towards dealing with the confusion. I think I'd be OK with that, though I am on the fence about whether just pushing (i.e., "current") would be better or worse. > 3. In the branching configurations for which all workflows agree about > what "git push" should do, then that is what "git push" should do by > default. When they do not agree, then "git push" should do nothing, > give an informative error message, and leave it to the user to > decide. > [...] > Isn't it obvious?: The fact that we cannot even agree among ourselves > what "git push" should do in all cases *proves* that we are trying to be > too ambitious with DWIM. "git push" must therefore become more > deferential when the obvious thing to do is unclear, especially given > that mistakes (due to the very nature of "git push") often have > embarrassing and publicly visible effects. I find your approach interesting, but it doesn't deal with one problem: user perception when git fails to do something out of the box. I am worried that the rule above means that push will end up defaulting to nothing. It is one thing to say "there are so many workflows, and they do not agree, so we should be safe and do nothing"; that makes sense to an advanced user who thinks about things like different workflows. But to a brand-new git user who is running "push" in their first session, it makes git seem very unfriendly. And that's why I think either "current" or "current-if-matching" as you describe is a sane default. I don't think it matches with what the "upstream" people want, and so does not meet your criteria above as a default behavior. But it does something sensible and not very dangerous or embarrassing, and it means git will do something that is probably useful out of the box for a new user. -Peff ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [RFC PATCH] push: start warning upcoming default change for push.default 2012-03-09 8:31 ` [RFC PATCH] push: start warning upcoming default change for push.default Matthieu Moy 2012-03-09 10:01 ` Junio C Hamano 2012-03-09 10:25 ` Carlos Martín Nieto @ 2012-03-09 11:26 ` Ævar Arnfjörð Bjarmason 2012-03-16 8:51 ` Clemens Buchacher 2012-03-19 16:11 ` Andrew Myers 4 siblings, 0 replies; 116+ messages in thread From: Ævar Arnfjörð Bjarmason @ 2012-03-09 11:26 UTC (permalink / raw) To: Matthieu Moy; +Cc: git, gitster On Fri, Mar 9, 2012 at 09:31, Matthieu Moy <Matthieu.Moy@imag.fr> wrote: > More inexperienced users will often push right after committing, and at > that time they're still very much in the "working-on-one-branch" state of > mind. "upstream" would be a safer default mode of operation for 'git push' > for them even when they have their personal publishing repository (also in > a shared public repository settings, "matching" is rarely the right > default mode). I very much like changing the default, thanks for working on this, this'll make Git a lot more sensible by default. </aol> ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [RFC PATCH] push: start warning upcoming default change for push.default 2012-03-09 8:31 ` [RFC PATCH] push: start warning upcoming default change for push.default Matthieu Moy ` (2 preceding siblings ...) 2012-03-09 11:26 ` Ævar Arnfjörð Bjarmason @ 2012-03-16 8:51 ` Clemens Buchacher 2012-03-16 9:43 ` Matthieu Moy 2012-03-19 16:11 ` Andrew Myers 4 siblings, 1 reply; 116+ messages in thread From: Clemens Buchacher @ 2012-03-16 8:51 UTC (permalink / raw) To: Matthieu Moy; +Cc: git, gitster Hi, On Fri, Mar 09, 2012 at 09:31:26AM +0100, Matthieu Moy wrote: > > In preparation for flipping the default to the "upstream" mode from the > "matching" mode that is the upstream default, start warning users when they > rely on unconfigured "git push" to default to the "matching" mode. I haven't had time to follow the entire discussion, but I have been thinking about this myself a little and I also find it hard to decide between "current" and "upstream". So I just wanted to throw in another option: If neither default is the right thing to do, then we should not choose either. Instead, by default make push act according to "current" or "upstream" only if they would do the same thing anyways. In other words, push the current branch only if it is also tracking a remote branch of the same name. If "current" and "upstream" disagree, git push errors out and asks the user to use an explicit refspec or change push.default according to their preferred workflow. Clemens ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [RFC PATCH] push: start warning upcoming default change for push.default 2012-03-16 8:51 ` Clemens Buchacher @ 2012-03-16 9:43 ` Matthieu Moy 2012-03-16 12:05 ` Junio C Hamano 0 siblings, 1 reply; 116+ messages in thread From: Matthieu Moy @ 2012-03-16 9:43 UTC (permalink / raw) To: Clemens Buchacher; +Cc: git, gitster Clemens Buchacher <drizzd@aon.at> writes: > If "current" and "upstream" disagree, git push errors out and asks the > user to use an explicit refspec or change push.default according to > their preferred workflow. I actually like this idea. Or at least, much more than "current, but only if the remote already exists". In most simple case, it will just work, and it will error out with an explicit message in every case which could have confused the user. I'd count "upstream is not set" as "current and upstream agree on 'current'". IOW, use "current", but error out if there's a configured upstream that is different. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [RFC PATCH] push: start warning upcoming default change for push.default 2012-03-16 9:43 ` Matthieu Moy @ 2012-03-16 12:05 ` Junio C Hamano 2012-03-16 12:42 ` Matthieu Moy 0 siblings, 1 reply; 116+ messages in thread From: Junio C Hamano @ 2012-03-16 12:05 UTC (permalink / raw) To: Matthieu Moy; +Cc: Clemens Buchacher, git Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes: > I'd count "upstream is not set" as "current and upstream agree on > 'current'". IOW, use "current", but error out if there's a configured > upstream that is different. And if there is no configured upstream, should it error out, or should it just push the current one to its own name? ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [RFC PATCH] push: start warning upcoming default change for push.default 2012-03-16 12:05 ` Junio C Hamano @ 2012-03-16 12:42 ` Matthieu Moy 2012-03-16 21:48 ` Clemens Buchacher 0 siblings, 1 reply; 116+ messages in thread From: Matthieu Moy @ 2012-03-16 12:42 UTC (permalink / raw) To: Junio C Hamano; +Cc: Clemens Buchacher, git Junio C Hamano <gitster@pobox.com> writes: > Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes: > >> I'd count "upstream is not set" as "current and upstream agree on >> 'current'". IOW, use "current", but error out if there's a configured >> upstream that is different. > > And if there is no configured upstream, should it error out, or should it > just push the current one to its own name? I meant just push the current one to its own name. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [RFC PATCH] push: start warning upcoming default change for push.default 2012-03-16 12:42 ` Matthieu Moy @ 2012-03-16 21:48 ` Clemens Buchacher 2012-03-17 20:46 ` Matthieu Moy 0 siblings, 1 reply; 116+ messages in thread From: Clemens Buchacher @ 2012-03-16 21:48 UTC (permalink / raw) To: Matthieu Moy; +Cc: Junio C Hamano, git On Fri, Mar 16, 2012 at 01:42:36PM +0100, Matthieu Moy wrote: > Junio C Hamano <gitster@pobox.com> writes: > > > Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes: > > > >> I'd count "upstream is not set" as "current and upstream agree on > >> 'current'". IOW, use "current", but error out if there's a configured > >> upstream that is different. > > > > And if there is no configured upstream, should it error out, or should it > > just push the current one to its own name? > > I meant just push the current one to its own name. Altough in a somewhat rarer case, this has the same problem as "current": git checkout -b master origin/master git checkout -b topic master git push If a branch called topic already exists on origin, push will now try to update it with the local branch topic. But they do not have any clear connection, except for the name. Clemens ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [RFC PATCH] push: start warning upcoming default change for push.default 2012-03-16 21:48 ` Clemens Buchacher @ 2012-03-17 20:46 ` Matthieu Moy 0 siblings, 0 replies; 116+ messages in thread From: Matthieu Moy @ 2012-03-17 20:46 UTC (permalink / raw) To: Clemens Buchacher; +Cc: Junio C Hamano, git Clemens Buchacher <drizzd@aon.at> writes: > On Fri, Mar 16, 2012 at 01:42:36PM +0100, Matthieu Moy wrote: >> Junio C Hamano <gitster@pobox.com> writes: >> >> > Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes: >> > >> >> I'd count "upstream is not set" as "current and upstream agree on >> >> 'current'". IOW, use "current", but error out if there's a configured >> >> upstream that is different. >> > >> > And if there is no configured upstream, should it error out, or should it >> > just push the current one to its own name? >> >> I meant just push the current one to its own name. > > Altough in a somewhat rarer case, this has the same problem as > "current": > > git checkout -b master origin/master > git checkout -b topic master > git push > > If a branch called topic already exists on origin, push will now try to > update it with the local branch topic. But they do not have any clear > connection, except for the name. Yes, but the user can hardly expect anything else here. So, it may be a (user) mistake, but it's not a surprise. BTW, 'matching' also has this drawback, and I never saw anyone complain about it (maybe I didn't listen enough though). -- Matthieu Moy http://www-verimag.imag.fr/~moy/ ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [RFC PATCH] push: start warning upcoming default change for push.default 2012-03-09 8:31 ` [RFC PATCH] push: start warning upcoming default change for push.default Matthieu Moy ` (3 preceding siblings ...) 2012-03-16 8:51 ` Clemens Buchacher @ 2012-03-19 16:11 ` Andrew Myers 4 siblings, 0 replies; 116+ messages in thread From: Andrew Myers @ 2012-03-19 16:11 UTC (permalink / raw) To: git I would like to register my vote to change the default behavior of git push to either current (preferred) or upstream. I'm the git admin on my team which uses a shared repository with many branches. The current default behavior has caused confusion and problems for inexperienced users (or users who refuse to self educate). While the optimum solution would be users who learn the system but this change would make (at least) my job easier. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: git push default behaviour? 2012-03-09 8:25 ` Matthieu Moy 2012-03-09 8:31 ` [RFC PATCH] push: start warning upcoming default change for push.default Matthieu Moy @ 2012-03-09 9:57 ` Junio C Hamano 2012-03-09 12:11 ` Matthieu Moy ` (3 more replies) 1 sibling, 4 replies; 116+ messages in thread From: Junio C Hamano @ 2012-03-09 9:57 UTC (permalink / raw) To: Matthieu Moy Cc: Jeff King, Dmitry Potapov, Marc Branchaud, Carlos Martín Nieto, Jeremy Morton, Thomas Rast, git Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes: > Junio C Hamano <gitster@pobox.com> writes: > >> I just dug it up; start from here: >> >> http://thread.gmane.org/gmane.comp.version-control.git/123350/focus=123541 > > That's an old discussion. A more recent one is here: > > http://thread.gmane.org/gmane.comp.version-control.git/166743 > > (interleaved with a discussion about tag namespace, but the end of the > message is about push.default) I'd say that it only shows that everybody for some strange reason forgot to learn from history, including me, in that more recent thread. Luckily, Jeff noticed eerily familiarity this time around. > (i.e. "Care to roll an appliable patch?", which I guess everyone has > been too lazy to do) I doubt that it would have solved any issue we suffered in the 1.6.3 to 1.6.4 timeframe if somebody gave a concluding patch after that message in the more recent discussion. Specifically, it would not have solved anything that these raised: http://thread.gmane.org/gmane.comp.version-control.git/118866/focus=119142 http://thread.gmane.org/gmane.comp.version-control.git/118866/focus=119148 Resurrecting the old patch that was reverted is the easiest part. It is much more important to spread the word to the people who will be hurt by the default change well before it actually happens, and to get them engaged in the discussion, along with those who would benefit from such a change. That needs to happen before any patch that reverts a revert. Even in the kernel community, I suspect that most people do not follow this mailing list anymore and simply trust that we won't make changes that affect them negatively. People will complain only after a change hits them, and tell us "We didn't know that you will be making this stupid change." And having this thread here does not count as "spreading the word". I can send a message saying "There is a proposal to change the default behaviour of 'git push' on the Git mailing list, and you may be negatively affected if you do not see anything in the output from 'git config push.default' when such a change happens. On the other hand, you may want to see the default behaviour to change. In either case, please join the discussion to give us more data point and help us decide the future of Git." to the kernel list. Anybody could, for that matter. One thing I refuse to do is to fight this battle alone for "let's change the default" folks, especially when I am not convinced that it is a good change to begin with. It is "let's change the default" folks' responsibility to help the legwork. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: git push default behaviour? 2012-03-09 9:57 ` git push default behaviour? Junio C Hamano @ 2012-03-09 12:11 ` Matthieu Moy 2012-03-09 16:22 ` Junio C Hamano 2012-03-09 14:56 ` Jakub Narebski ` (2 subsequent siblings) 3 siblings, 1 reply; 116+ messages in thread From: Matthieu Moy @ 2012-03-09 12:11 UTC (permalink / raw) To: Junio C Hamano Cc: Jeff King, Dmitry Potapov, Marc Branchaud, Carlos Martín Nieto, Jeremy Morton, Thomas Rast, git Junio C Hamano <gitster@pobox.com> writes: > I can send a message saying "[...]" to the kernel list. Anybody could, > for that matter. That would have been something sensible to do a few years ago, but today, I think we are far, far beyond the point where Git was a tool meant primarily for kernel hackers. I don't think considering the kernel community as more important than other users will help making Git easy to use for bare mortals. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: git push default behaviour? 2012-03-09 12:11 ` Matthieu Moy @ 2012-03-09 16:22 ` Junio C Hamano 2012-03-09 17:44 ` Junio C Hamano 0 siblings, 1 reply; 116+ messages in thread From: Junio C Hamano @ 2012-03-09 16:22 UTC (permalink / raw) To: Matthieu Moy Cc: Jeff King, Dmitry Potapov, Marc Branchaud, Carlos Martín Nieto, Jeremy Morton, Thomas Rast, git Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes: > Junio C Hamano <gitster@pobox.com> writes: > >> I can send a message saying "[...]" to the kernel list. Anybody could, >> for that matter. > > That would have been something sensible to do a few years ago, but > today, I think we are far, far beyond the point where Git was a tool > meant primarily for kernel hackers. I don't think considering the kernel > community as more important than other users will help making Git easy > to use for bare mortals. That is *EXACTLY* the issue. The kernel is one example community that *I* can cover, and if we were going to continue discussion, I'm willing to help doing so because your change will *NEVER* work unless we spread the word to *all* the relevant communities whose members may be negatively affected. That is what I am saying in the part you quoted. But I obviously *WILL* *NOT* be able to do so for *all* communities whose members may be negatively affected. Let me repeat the part you omitted from your quote: One thing I refuse to do is to fight this battle alone for "let's change the default" folks, especially when I am not convinced that it is a good change to begin with. It is "let's change the default" folks' responsibility to help the legwork. Now, you have realized that the kernel community is only one of the places where "let's change the default" folks need to spread the word and solicit their involvement, are you willing to do your part? People will complain only after a change hits them, and tell us "We didn't know that you will be making this stupid change." And having this thread here does not count as "spreading the word". ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: git push default behaviour? 2012-03-09 16:22 ` Junio C Hamano @ 2012-03-09 17:44 ` Junio C Hamano 0 siblings, 0 replies; 116+ messages in thread From: Junio C Hamano @ 2012-03-09 17:44 UTC (permalink / raw) To: Matthieu Moy Cc: Jeff King, Dmitry Potapov, Marc Branchaud, Carlos Martín Nieto, Jeremy Morton, Thomas Rast, git Junio C Hamano <gitster@pobox.com> writes: > Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes: > >> Junio C Hamano <gitster@pobox.com> writes: >> >>> I can send a message saying "[...]" to the kernel list. Anybody could, >>> for that matter. >> ... > But I obviously *WILL* *NOT* be able to do so for *all* communities > whose members may be negatively affected. Oh, let's avoid any misunderstanding before it happens. I am not saying that we need to get involvement only from people who might like the current default. If you read the "[...]" part you omitted from your quote again, you will notice that the RFH message was carefully crafted to take a neutral position, and solicit input from both sides, and that was very much on purpose. I was hoping that the reaction to my reply would be that "let's change the default" folks to help polishing the wording of the RFH message further, and post the final one to help spreading the word, both in the forums of projects that will be helped by the change, and of those that will be irritated by the change. I didn't mean to suggest anybody to play politics by asking input from only one side to skew the discussion, even though it is not like we will decide by majority vote anyway. Deciding in favor of whichever position you happen to like is not the goal. Avoiding user surprises and unnecessary harm is. And that is why the lesson the older thread from 1.6.3-1.6.4 era teaches us is important. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: git push default behaviour? 2012-03-09 9:57 ` git push default behaviour? Junio C Hamano 2012-03-09 12:11 ` Matthieu Moy @ 2012-03-09 14:56 ` Jakub Narebski 2012-03-09 16:23 ` Junio C Hamano 2012-03-12 9:34 ` Matthieu Moy 2012-03-17 15:49 ` Eric Hanchrow 3 siblings, 1 reply; 116+ messages in thread From: Jakub Narebski @ 2012-03-09 14:56 UTC (permalink / raw) To: Junio C Hamano Cc: Matthieu Moy, Jeff King, Dmitry Potapov, Marc Branchaud, Carlos Martin Nieto, Jeremy Morton, Thomas Rast, git [I am sorry if you have received duplicates] Junio C Hamano <gitster@pobox.com> writes: > Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes: >> Junio C Hamano <gitster@pobox.com> writes: >> >>> I just dug it up; start from here: >>> >>> http://thread.gmane.org/gmane.comp.version-control.git/123350/focus=123541 >> >> That's an old discussion. A more recent one is here: >> >> http://thread.gmane.org/gmane.comp.version-control.git/166743 >> >> (interleaved with a discussion about tag namespace, but the end of the >> message is about push.default) > > I'd say that it only shows that everybody for some strange reason > forgot to learn from history, including me, in that more recent > thread. Luckily, Jeff noticed eerily familiarity this time around. Nb. if I remember it correctly one of problems seen with transition to new default was that there were no command-line equivalent to 'push.default = matching'... but now we have ":" and "+:" magic refspec. >> (i.e. "Care to roll an appliable patch?", which I guess everyone has >> been too lazy to do) [...] > Resurrecting the old patch that was reverted is the easiest part. > > It is much more important to spread the word to the people who will > be hurt by the default change well before it actually happens, and > to get them engaged in the discussion, along with those who would > benefit from such a change. That needs to happen before any patch > that reverts a revert. > > Even in the kernel community, I suspect that most people do not > follow this mailing list anymore and simply trust that we won't make > changes that affect them negatively. People will complain only after > a change hits them, and tell us "We didn't know that you will be > making this stupid change." And having this thread here does not > count as "spreading the word". > > I can send a message saying "There is a proposal to change the > default behaviour of 'git push' on the Git mailing list, and you may > be negatively affected if you do not see anything in the output from > 'git config push.default' when such a change happens. On the other > hand, you may want to see the default behaviour to change. In either > case, please join the discussion to give us more data point and help > us decide the future of Git." to the kernel list. Anybody could, for > that matter. There are other places where we can send such message beside git mailing list and LKML: There is Junio's "Git Blame" blog, there is Git page on Google+; we can ask for such annoncement to be posted also on GitHub Blog... Spread the word... -- Jakub Narebski ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: git push default behaviour? 2012-03-09 14:56 ` Jakub Narebski @ 2012-03-09 16:23 ` Junio C Hamano 2012-03-13 15:18 ` Jakub Narebski 0 siblings, 1 reply; 116+ messages in thread From: Junio C Hamano @ 2012-03-09 16:23 UTC (permalink / raw) To: Jakub Narebski Cc: Matthieu Moy, Jeff King, Dmitry Potapov, Marc Branchaud, Carlos Martin Nieto, Jeremy Morton, Thomas Rast, git Jakub Narebski <jnareb@gmail.com> writes: > There are other places where we can send such message beside git > mailing list and LKML: There is Junio's "Git Blame" blog, there is Git > page on Google+; we can ask for such annoncement to be posted also > on GitHub Blog... And you are saying who will do all of the above? ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: git push default behaviour? 2012-03-09 16:23 ` Junio C Hamano @ 2012-03-13 15:18 ` Jakub Narebski 0 siblings, 0 replies; 116+ messages in thread From: Jakub Narebski @ 2012-03-13 15:18 UTC (permalink / raw) To: Junio C Hamano Cc: Matthieu Moy, Jeff King, Dmitry Potapov, Marc Branchaud, Carlos Martin Nieto, Jeremy Morton, Thomas Rast, git On Fri, 9 Mar 2012, Junio C Hamano wrote: > Jakub Narebski <jnareb@gmail.com> writes: > > > There are other places where we can send such message beside git > > mailing list and LKML: There is Junio's "Git Blame" blog, there is Git > > page on Google+; we can ask for such annoncement to be posted also > > on GitHub Blog... > > And you are saying who will do all of the above? I would certainly not be announcing this message on yours "Git Blame" blog, and you usually accompany new post on blog with announcement on G+ (I don't remember if via "Git" page or via your own personal Google+ page). I can go round git hosting sites asking to post announcements, similarly to what I do during annual "Git User's Survey". -- Jakub Narebski Poland ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: git push default behaviour? 2012-03-09 9:57 ` git push default behaviour? Junio C Hamano 2012-03-09 12:11 ` Matthieu Moy 2012-03-09 14:56 ` Jakub Narebski @ 2012-03-12 9:34 ` Matthieu Moy 2012-03-12 16:29 ` Junio C Hamano 2012-03-17 15:49 ` Eric Hanchrow 3 siblings, 1 reply; 116+ messages in thread From: Matthieu Moy @ 2012-03-12 9:34 UTC (permalink / raw) To: Junio C Hamano Cc: Jeff King, Dmitry Potapov, Marc Branchaud, Carlos Martín Nieto, Jeremy Morton, Thomas Rast, git Junio C Hamano <gitster@pobox.com> writes: > I can send a message saying "There is a proposal to change the > default behaviour of 'git push' on the Git mailing list, and you may > be negatively affected if you do not see anything in the output from > 'git config push.default' when such a change happens. On the other > hand, you may want to see the default behaviour to change. In either > case, please join the discussion to give us more data point and help > us decide the future of Git." to the kernel list. Anybody could, for > that matter. Here's an attempt to an improved message. The first paragraph is here to make sure people understand their opinion counts (before they stop reading because it's too long). The rest explains the change and the way to get involved: ---------- 8< ---------- 8< ----------- There is a proposal to change the default behaviour of 'git push' on the Git mailing list. The goal of this message is to encourage you to discuss it before it happens (or the change is aborted, depending on the outcome of the discussion). In the current setting (i.e. push.default=matching), 'git push' without argument will push all branches that exist locally and remotely with the same name. This is usually appropriate when a developer pushes to his own public repository, but confusing if not dangerous when using a shared repository. The proposal is to change the default to 'upstream', i.e. push only the current branch, and push it to the upstream branch (the one 'git pull' would pull from). 'current' is another candidate. For more details on the behavior of Git with these values, read the documentation about 'push.default' in 'man git-config' (http://schacon.github.com/git/git-config.html). You may be negatively affected when such a change happens if you do not see anything in the output from 'git config push.default' and if you rely on the fact that 'git push' pushes all your matching branches. On the other hand, you may want to see the default behaviour to change, especially if you are using shared repositories. In either case, please join the discussion to give us more data point and help us decide the future of Git. To join the discussion, send your messages to: git@vger.kernel.org You don't need to subscribe the list to post, and it's customary to Cc: posters when replying on this list. To view the current discussion, see this thread: http://thread.gmane.org/gmane.comp.version-control.git/192547/focus=192694 -- Matthieu Moy http://www-verimag.imag.fr/~moy/ ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: git push default behaviour? 2012-03-12 9:34 ` Matthieu Moy @ 2012-03-12 16:29 ` Junio C Hamano 2012-03-13 9:47 ` Matthieu Moy 0 siblings, 1 reply; 116+ messages in thread From: Junio C Hamano @ 2012-03-12 16:29 UTC (permalink / raw) To: Matthieu Moy Cc: Jeff King, Dmitry Potapov, Marc Branchaud, Carlos Martín Nieto, Jeremy Morton, Thomas Rast, git Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes: > Here's an attempt to an improved message. The first paragraph is here to > make sure people understand their opinion counts (before they stop > reading because it's too long). The rest explains the change and the way > to get involved: Sounds OK from a cursory read, except for a few minor details. Thanks. Nitpicks follow. > ---------- 8< ---------- 8< ----------- > > There is a proposal to change the default behaviour of 'git push' > on the Git mailing list. The goal of this message is to encourage you > to discuss it before it happens (or the change is aborted, depending > on the outcome of the discussion). > > In the current setting (i.e. push.default=matching), 'git push' without > argument will push all branches that exist locally and remotely with > the same name. This is usually appropriate when a developer pushes to > his own public repository, but confusing if not dangerous when using a > shared repository. The proposal is to change the default to "usually appropriate" tries to avoid claiming that this statement is the final judgement. "confusing" may need to be stated the same way, i.e. "but may be confusing". Alternatively, we can drop "usually". > 'upstream', i.e. push only the current branch, and push it to the > upstream branch (the one 'git pull' would pull from). 'current' is > another candidate. When I find myself needing to clarify a jargon with parenthesized rephrase, I drop the jargon and parentheses and see if it makes it easier to read. And in this case I think it does. i.e. push only the current branch to the branch 'git pull' would pull from. What 'upstream' does is explained but not 'current'; here is my attempt. Another candidate is 'current'; this pushes only the current branch to the branch of the same name. > For more details on the behavior of Git with these values, read > the documentation about 'push.default' in 'man git-config' > (http://schacon.github.com/git/git-config.html). > > You may be negatively affected when such a change happens if you > do not see anything in the output from 'git config push.default' > and if you rely on the fact that 'git push' pushes all your > matching branches. On the other hand, you may want to see the Let's stress that they are relying on the _default_ a bit stronger. "and if you rely on the default that pushes all your" > default behaviour to change, especially if you are using shared > repositories. In either case, please join the discussion to give > us more data point and help us decide the future of Git. > To join the discussion, send your messages to: git@vger.kernel.org > You don't need to subscribe the list to post, and it's customary to > Cc: posters when replying on this list. > To view the current discussion, see this thread: > http://thread.gmane.org/gmane.comp.version-control.git/192547/focus=192694 As this is not an invitation to start a new discussion, "speak without reading what have already been said" is not something we would want to encourage, so I'd prefer to see the order swapped, like What has been discussed so far can be seen in these threads: ... gmane references ... To join the discussion, send your messages to: git@vger.kernel.org The list accepts messages from non-subscribers, and you do not have to ask "please Cc me, I am not subscribed", as it's customary to Cc: posters when replying on this list. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: git push default behaviour? 2012-03-12 16:29 ` Junio C Hamano @ 2012-03-13 9:47 ` Matthieu Moy 2012-03-13 12:34 ` Junio C Hamano 0 siblings, 1 reply; 116+ messages in thread From: Matthieu Moy @ 2012-03-13 9:47 UTC (permalink / raw) To: Junio C Hamano Cc: Jeff King, Dmitry Potapov, Marc Branchaud, Carlos Martín Nieto, Jeremy Morton, Thomas Rast, git Junio C Hamano <gitster@pobox.com> writes: > Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes: > >> Here's an attempt to an improved message. The first paragraph is here to >> make sure people understand their opinion counts (before they stop >> reading because it's too long). The rest explains the change and the way >> to get involved: > > Sounds OK from a cursory read, except for a few minor details. > > Thanks. Nitpicks follow. I'm taking them all. Here's the result: ---------- 8< ---------- 8< ----------- There is a proposal to change the default behaviour of 'git push' on the Git mailing list. The goal of this message is to encourage you to discuss it before it happens (or the change is aborted, depending on the outcome of the discussion). In the current setting (i.e. push.default=matching), 'git push' without argument will push all branches that exist locally and remotely with the same name. This is usually appropriate when a developer pushes to his own public repository, but may be confusing if not dangerous when using a shared repository. The proposal is to change the default to 'upstream', i.e. push only the current branch, and push it to the branch 'git pull' would pull from. Another candidate is 'current'; this pushes only the current branch to the remote branch of the same name. For more details on the behavior of Git with these values, read the documentation about 'push.default' in 'man git-config' (http://schacon.github.com/git/git-config.html). You may be negatively affected when such a change happens if you do not see anything in the output from 'git config push.default' and if you rely on the default that pushes all your matching branches. On the other hand, you may want to see the default behaviour to change, especially if you are using shared repositories. In either case, please join the discussion to give us more data point and help us decide the future of Git. What has been discussed so far can be seen in this thread: http://thread.gmane.org/gmane.comp.version-control.git/192547/focus=192694 Previous relevant discussions include: http://thread.gmane.org/gmane.comp.version-control.git/123350/focus=123541 http://thread.gmane.org/gmane.comp.version-control.git/166743 To join the discussion, send your messages to: git@vger.kernel.org The list accepts messages from non-subscribers, and you do not have to ask "please Cc me, I am not subscribed", as it's customary to Cc: posters when replying on this list. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: git push default behaviour? 2012-03-13 9:47 ` Matthieu Moy @ 2012-03-13 12:34 ` Junio C Hamano 2012-03-16 19:35 ` Junio C Hamano 0 siblings, 1 reply; 116+ messages in thread From: Junio C Hamano @ 2012-03-13 12:34 UTC (permalink / raw) To: Matthieu Moy Cc: Jeff King, Dmitry Potapov, Marc Branchaud, Carlos Martín Nieto, Jeremy Morton, Thomas Rast, git Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes: >> Sounds OK from a cursory read, except for a few minor details. >> >> Thanks. Nitpicks follow. > > I'm taking them all. Here's the result: I'd hold onto this version for a few days before I paste it in my blog or send it to k-list in order to give others a chance to improve the text further, but this looks good (obviously) to me. Thanks for getting the ball rolling. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: git push default behaviour? 2012-03-13 12:34 ` Junio C Hamano @ 2012-03-16 19:35 ` Junio C Hamano 0 siblings, 0 replies; 116+ messages in thread From: Junio C Hamano @ 2012-03-16 19:35 UTC (permalink / raw) To: git Cc: Jeff King, Dmitry Potapov, Marc Branchaud, Carlos Martín Nieto, Jeremy Morton, Thomas Rast, Matthieu Moy Junio C Hamano <gitster@pobox.com> writes: > Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes: > >>> Sounds OK from a cursory read, except for a few minor details. >>> >>> Thanks. Nitpicks follow. >> >> I'm taking them all. Here's the result: > > I'd hold onto this version for a few days before I paste it in my > blog or send it to k-list in order to give others a chance to > improve the text further, but this looks good (obviously) to me. > > Thanks for getting the ball rolling. So a few days passed, and I do not think we heard anything from anybody. I am not sure if that means everybody is happy with the wording of the draft, or simply nobody cares, but unless I hear from anybody further on this topic, I'll start my part of distributing this to where I feel are appropriate tonight [*1*]. People who want to see the default changed, please help the message to reach corners where mine wouldn't reach. For that matter, people who want to see that the default remains the same, please do the same. Thanks. [Footnote] *1* The places I have in mind are: - This list (which may be pointless) - linux-kernel@vger.kernel.org - http://git-blame.blogspot.com/ - http://gplus.to/gitster - http://gplus.to/git - Google internal (there are a few users at $DAYJOB) ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: git push default behaviour? 2012-03-09 9:57 ` git push default behaviour? Junio C Hamano ` (2 preceding siblings ...) 2012-03-12 9:34 ` Matthieu Moy @ 2012-03-17 15:49 ` Eric Hanchrow 3 siblings, 0 replies; 116+ messages in thread From: Eric Hanchrow @ 2012-03-17 15:49 UTC (permalink / raw) To: git In response to http://git-blame.blogspot.com/2012/03/please-discuss-what-git-push-should-do.html: I think either 'current' or 'upstream' is a better default than 'matching', since it's less likely to surprise newbies. However, I cannot decide which of 'current' or 'upstream' is the best choice. It might be worthwhile to have 'git push' warn when someone has push.default = current or push.default = upstream, AND when @{u} has a different name than the local branch -- in other words, emit a warning when 'upstream'' and 'current' refer to different branches. The warning itself should be turn-off-able, since it would get pretty old pretty quickly. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: git push default behaviour? 2012-03-08 15:00 ` Marc Branchaud 2012-03-08 15:26 ` Matthieu Moy @ 2012-03-08 17:37 ` Dmitry Potapov 1 sibling, 0 replies; 116+ messages in thread From: Dmitry Potapov @ 2012-03-08 17:37 UTC (permalink / raw) To: Marc Branchaud; +Cc: Carlos Martín Nieto, Jeremy Morton, Thomas Rast, git On Thu, Mar 8, 2012 at 7:00 PM, Marc Branchaud <marcnarc@xiplink.com> 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 ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: git push default behaviour? 2012-03-08 10:38 ` Jeremy Morton 2012-03-08 10:42 ` Carlos Martín Nieto @ 2012-03-08 11:33 ` Jakub Narebski 2012-03-08 11:34 ` Jeremy Morton 1 sibling, 1 reply; 116+ messages in thread From: Jakub Narebski @ 2012-03-08 11:33 UTC (permalink / raw) To: Jeremy Morton; +Cc: Carlos Martín Nieto, Thomas Rast, git Jeremy Morton <jeremy@configit.com> writes: > On Thu, Mar 8, 2012 at 10:28 AM, Carlos Martín Nieto <cmn@elego.de> wrote: > > 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. > > 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 ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: git push default behaviour? 2012-03-08 11:33 ` Jakub Narebski @ 2012-03-08 11:34 ` Jeremy Morton 2012-03-13 15:27 ` Jakub Narebski 0 siblings, 1 reply; 116+ messages in thread From: Jeremy Morton @ 2012-03-08 11:34 UTC (permalink / raw) To: Jakub Narebski; +Cc: Carlos Martín Nieto, Thomas Rast, git On Thu, Mar 8, 2012 at 11:33 AM, Jakub Narebski <jnareb@gmail.com> wrote: > 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. Best regards, Jeremy Morton (Jez) ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: git push default behaviour? 2012-03-08 11:34 ` Jeremy Morton @ 2012-03-13 15:27 ` Jakub Narebski 2012-03-14 12:12 ` Jeremy Morton 0 siblings, 1 reply; 116+ messages in thread From: Jakub Narebski @ 2012-03-13 15:27 UTC (permalink / raw) To: Jeremy Morton; +Cc: Carlos Martín Nieto, Thomas Rast, git On Thu, 8 Mar 2012, Jeremy Morton wrote: > On Thu, Mar 8, 2012 at 11:33 AM, Jakub Narebski <jnareb@gmail.com> wrote: > > 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 ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: git push default behaviour? 2012-03-13 15:27 ` Jakub Narebski @ 2012-03-14 12:12 ` Jeremy Morton 2012-03-14 17:16 ` Jakub Narebski 0 siblings, 1 reply; 116+ messages in thread From: Jeremy Morton @ 2012-03-14 12:12 UTC (permalink / raw) To: Jakub Narebski; +Cc: Carlos Martín Nieto, Thomas Rast, git 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 <jnareb@gmail.com> wrote: > On Thu, 8 Mar 2012, Jeremy Morton wrote: >> On Thu, Mar 8, 2012 at 11:33 AM, Jakub Narebski <jnareb@gmail.com> wrote: > >> > 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 ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: git push default behaviour? 2012-03-14 12:12 ` Jeremy Morton @ 2012-03-14 17:16 ` Jakub Narebski 0 siblings, 0 replies; 116+ messages in thread From: Jakub Narebski @ 2012-03-14 17:16 UTC (permalink / raw) To: Jeremy Morton; +Cc: Carlos Martín Nieto, Thomas Rast, git Could you please do not top-post? TIA. Jeremy Morton wrote: > On Tue, Mar 13, 2012 at 4:27 PM, Jakub Narebski <jnareb@gmail.com> wrote: > > On Thu, 8 Mar 2012, Jeremy Morton wrote: > >> On Thu, Mar 8, 2012 at 11:33 AM, Jakub Narebski <jnareb@gmail.com> wrote: > > > >> > 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. C.f. http://thread.gmane.org/gmane.comp.version-control.git/189895 http://thread.gmane.org/gmane.comp.version-control.git/189946/focus=191119 Though that is only a proposal and a prototype. -- Jakub Narebski Poland ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: git push default behaviour? 2012-03-08 10:28 ` Carlos Martín Nieto 2012-03-08 10:38 ` Jeremy Morton @ 2012-03-08 11:54 ` Matthieu Moy 2012-03-08 12:12 ` demerphq 1 sibling, 1 reply; 116+ messages in thread From: Matthieu Moy @ 2012-03-08 11:54 UTC (permalink / raw) To: Carlos Martín Nieto; +Cc: Jeremy Morton, Thomas Rast, git Carlos Martín Nieto <cmn@elego.de> writes: > 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. There were some discussions about changing the default, and I thought people agreed that 'upstream' was a better default value for push.default: http://permalink.gmane.org/gmane.comp.version-control.git/167149 it needs to be done with a sane migration path, however, and I guess no one stepped in to start the process (but I may have missed some further discussions). -- Matthieu Moy http://www-verimag.imag.fr/~moy/ ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: git push default behaviour? 2012-03-08 11:54 ` Matthieu Moy @ 2012-03-08 12:12 ` demerphq 0 siblings, 0 replies; 116+ messages in thread From: demerphq @ 2012-03-08 12:12 UTC (permalink / raw) To: Matthieu Moy; +Cc: Carlos Martín Nieto, Jeremy Morton, Thomas Rast, git On 8 March 2012 12:54, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote: > Carlos Martín Nieto <cmn@elego.de> writes: > >> 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. > > There were some discussions about changing the default, and I thought > people agreed that 'upstream' was a better default value for > push.default: > > http://permalink.gmane.org/gmane.comp.version-control.git/167149 > > it needs to be done with a sane migration path, however, and I guess no > one stepped in to start the process (but I may have missed some further > discussions). From the point of view of new users the current default is sub-optimal and confusing. I actually find the current default an odd choice, as I personally have *never* wanted to push all the branches at once, nor have I ever seen a colleague want to do that. cheers, Yves -- perl -Mre=debug -e "/just|another|perl|hacker/" ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: git push default behaviour? 2012-03-08 10:01 git push default behaviour? Jeremy Morton 2012-03-08 10:11 ` Thomas Rast @ 2012-03-17 9:36 ` Sebastien Douche 2012-03-17 9:38 ` Jeremy Morton 1 sibling, 1 reply; 116+ messages in thread From: Sebastien Douche @ 2012-03-17 9:36 UTC (permalink / raw) To: Jeremy Morton; +Cc: git On Thu, Mar 8, 2012 at 11:01, Jeremy Morton <jeremy@configit.com> wrote: > Hi everyone, Hi Jeremy (sorry to be late, back from holiday) > I've noticed that the default behaviour of 'git push' is to push to > *all* branches that have a remote branch set up. In order to push > just to one branch, you must specify 'git push repo branchname'. > > This seems rather unintuative to me I made many Git presentation and managed a lot of training[1] and the first thing I explain on the configuration is : 1. set your name and email 2. change the default push option[2] Moreover, most people I see don't understand the default behaviour: it's a frequently ask question by beginner. [1] For git French : http://gitfr.net/blog [2] I recommend tracking -- Sebastien Douche <sdouche@gmail.com> Twitter: @sdouche / G+: +sdouche ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: git push default behaviour? 2012-03-17 9:36 ` Sebastien Douche @ 2012-03-17 9:38 ` Jeremy Morton 2012-03-17 9:51 ` Sebastien Douche 0 siblings, 1 reply; 116+ messages in thread From: Jeremy Morton @ 2012-03-17 9:38 UTC (permalink / raw) To: Sebastien Douche; +Cc: git On Sat, Mar 17, 2012 at 9:36 AM, Sebastien Douche <sdouche@gmail.com> wrote: > On Thu, Mar 8, 2012 at 11:01, Jeremy Morton <jeremy@configit.com> wrote: >> Hi everyone, > > Hi Jeremy (sorry to be late, back from holiday) > >> I've noticed that the default behaviour of 'git push' is to push to >> *all* branches that have a remote branch set up. In order to push >> just to one branch, you must specify 'git push repo branchname'. >> >> This seems rather unintuative to me > > I made many Git presentation and managed a lot of training[1] and the > first thing I explain on the configuration is : > > 1. set your name and email > 2. change the default push option[2] So, that would seem to be a rather strong indication that the default push option is a bad one. :-) Best regards, Jeremy Morton (Jez) ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: git push default behaviour? 2012-03-17 9:38 ` Jeremy Morton @ 2012-03-17 9:51 ` Sebastien Douche 2012-03-18 10:26 ` Pavel Pospíšil 0 siblings, 1 reply; 116+ messages in thread From: Sebastien Douche @ 2012-03-17 9:51 UTC (permalink / raw) To: Jeremy Morton; +Cc: git On Sat, Mar 17, 2012 at 10:38, Jeremy Morton <jeremy@configit.com> wrote: >> I made many Git presentation and managed a lot of training[1] and the >> first thing I explain on the configuration is : >> >> 1. set your name and email >> 2. change the default push option[2] > > So, that would seem to be a rather strong indication that the default > push option is a bad one. :-) True. Never understood why matching is the default value :). Btw, thank you for the discussion, I forgot to do that :(. -- Sebastien Douche <sdouche@gmail.com> Twitter: @sdouche / G+: +sdouche ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: git push default behaviour? 2012-03-17 9:51 ` Sebastien Douche @ 2012-03-18 10:26 ` Pavel Pospíšil 0 siblings, 0 replies; 116+ messages in thread From: Pavel Pospíšil @ 2012-03-18 10:26 UTC (permalink / raw) To: git Hi, I consider myself a little bit experienced git newbie. I use git 1.7.5.4 I use git for 9 month in this way: 1. copy a released version from a centralized versioning control system (this VCS does not have any git interface) to my local git repo 2. do work in git in my-branch 3. copy current work-in-progress reconfiguration from VCS to git 4. rebase my-branch onto current work-in-progress 5. copy my work to VCS Therefore, no usage of push/pull. I created my first public repo in which I share the released versions of 4 development streams in 4 independent branches with my colleagues. My usual workflow is: 1. copy a released version from VCS to my local git repo 2. git add . 3. git commit 4. git tag <release-name> 5. git push <my-public-repo> HEAD 6. git push <release-name> I expected that push is meant (even after reading man git-push) to be used in this way: 1. do some work in my-branch 2. merge it to master 3. git push and this will push only the changes in the master branch I am currently switched on. Now, I realized that git push default is not "upstream" (the behaviour I expected) but is "matching" that brings more automation (I assume git community wants to achieve as much automation as possible). I agree with Sebastien that current git push.default is too much automation for newbies that "upstream" would be a better default for newbies. I came across an inconvenience in man git-push. There is no Configuration section that will inform about the push.default configuration parameter and educate the reading about various push behaviours. I know that there is man git-config but it's too long and it's too tedious to read all git configuration options. Maybe, adding the Configuration section to man git-push will help. Best regards, Pavel Pospisil On Sat, Mar 17, 2012 at 10:51 AM, Sebastien Douche <sdouche@gmail.com> wrote: > > On Sat, Mar 17, 2012 at 10:38, Jeremy Morton <jeremy@configit.com> wrote: > >> I made many Git presentation and managed a lot of training[1] and the > >> first thing I explain on the configuration is : > >> > >> 1. set your name and email > >> 2. change the default push option[2] > > > > So, that would seem to be a rather strong indication that the default > > push option is a bad one. :-) > > True. Never understood why matching is the default value :). Btw, > thank you for the discussion, I forgot to do that :(. > > -- > Sebastien Douche <sdouche@gmail.com> > Twitter: @sdouche / G+: +sdouche > -- > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 116+ messages in thread
end of thread, other threads:[~2012-03-19 16:15 UTC | newest] Thread overview: 116+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-03-08 10:01 git push default behaviour? Jeremy Morton 2012-03-08 10:11 ` Thomas Rast 2012-03-08 10:13 ` Jeremy Morton 2012-03-08 10:28 ` Carlos Martín Nieto 2012-03-08 10:38 ` Jeremy Morton 2012-03-08 10:42 ` Carlos Martín Nieto 2012-03-08 10:43 ` Jeremy Morton 2012-03-08 18:22 ` Junio C Hamano 2012-03-08 18:35 ` Matthieu Moy 2012-03-08 19:03 ` Andreas Krey 2012-03-08 19:29 ` Junio C Hamano 2012-03-09 8:05 ` Matthieu Moy 2012-03-09 9:50 ` Junio C Hamano 2012-03-09 11:28 ` Jeremy Morton 2012-03-09 11:54 ` Matthieu Moy 2012-03-09 14:42 ` Jakub Narebski 2012-03-19 6:02 ` Miles Bader 2012-03-19 16:12 ` Philippe Vaucher 2012-03-08 15:00 ` Marc Branchaud 2012-03-08 15:26 ` Matthieu Moy 2012-03-08 17:49 ` Dmitry Potapov 2012-03-08 18:04 ` Matthieu Moy 2012-03-09 3:38 ` Jeff King 2012-03-09 5:23 ` Junio C Hamano 2012-03-09 5:38 ` Junio C Hamano 2012-03-09 8:06 ` demerphq 2012-03-09 8:48 ` Thomas Rast 2012-03-09 9:50 ` Junio C Hamano 2012-03-16 9:38 ` Gelonida N 2012-03-09 8:25 ` Matthieu Moy 2012-03-09 8:31 ` [RFC PATCH] push: start warning upcoming default change for push.default Matthieu Moy 2012-03-09 10:01 ` Junio C Hamano 2012-03-09 20:21 ` Junio C Hamano 2012-03-09 10:25 ` Carlos Martín Nieto 2012-03-09 18:30 ` Marc Branchaud 2012-03-09 21:08 ` Stefan Haller 2012-03-10 21:05 ` Junio C Hamano 2012-03-11 20:26 ` Stefan Haller 2012-03-12 8:47 ` Matthieu Moy 2012-03-12 11:22 ` Stefan Haller 2012-03-12 12:46 ` Matthieu Moy 2012-03-12 16:11 ` Junio C Hamano 2012-03-12 15:10 ` Marc Branchaud 2012-03-10 6:16 ` Michael Haggerty 2012-03-12 15:13 ` Marc Branchaud 2012-03-12 16:37 ` Matthieu Moy 2012-03-12 17:53 ` Junio C Hamano 2012-03-12 18:37 ` Jeff King 2012-03-12 19:06 ` Junio C Hamano 2012-03-12 19:33 ` Junio C Hamano 2012-03-12 20:16 ` Marc Branchaud 2012-03-13 9:40 ` Matthieu Moy 2012-03-13 9:36 ` Matthieu Moy 2012-03-13 21:30 ` Jeff King 2012-03-13 22:54 ` Junio C Hamano 2012-03-14 13:50 ` Jeff King 2012-03-14 20:59 ` Junio C Hamano 2012-03-13 9:34 ` Matthieu Moy 2012-03-13 13:17 ` Junio C Hamano 2012-03-13 13:35 ` Matthieu Moy 2012-03-13 20:01 ` Auto-matching upstream branches by name (was: [RFC PATCH] push: start warning upcoming default change for push.default) Stefan Haller 2012-03-14 9:10 ` Auto-matching upstream branches by name Matthieu Moy 2012-03-13 14:31 ` [RFC PATCH] push: start warning upcoming default change for push.default Marc Branchaud 2012-03-13 14:59 ` Holger Hellmuth 2012-03-13 17:41 ` Junio C Hamano 2012-03-14 19:15 ` Holger Hellmuth 2012-03-15 8:02 ` Matthieu Moy 2012-03-15 10:43 ` Holger Hellmuth 2012-03-13 15:02 ` Andreas Ericsson 2012-03-13 21:35 ` Jeff King 2012-03-13 18:08 ` Dmitry Potapov 2012-03-14 4:46 ` Junio C Hamano 2012-03-14 12:47 ` Dmitry Potapov 2012-03-14 17:29 ` Junio C Hamano 2012-03-14 17:49 ` Dmitry Potapov 2012-03-14 20:44 ` Junio C Hamano 2012-03-14 9:07 ` Matthieu Moy 2012-03-14 13:23 ` Dmitry Potapov 2012-03-14 14:47 ` Matthieu Moy 2012-03-14 17:47 ` Dmitry Potapov 2012-03-15 8:05 ` Matthieu Moy 2012-03-14 8:59 ` Michael Haggerty 2012-03-14 14:00 ` Jeff King 2012-03-09 11:26 ` Ævar Arnfjörð Bjarmason 2012-03-16 8:51 ` Clemens Buchacher 2012-03-16 9:43 ` Matthieu Moy 2012-03-16 12:05 ` Junio C Hamano 2012-03-16 12:42 ` Matthieu Moy 2012-03-16 21:48 ` Clemens Buchacher 2012-03-17 20:46 ` Matthieu Moy 2012-03-19 16:11 ` Andrew Myers 2012-03-09 9:57 ` git push default behaviour? Junio C Hamano 2012-03-09 12:11 ` Matthieu Moy 2012-03-09 16:22 ` Junio C Hamano 2012-03-09 17:44 ` Junio C Hamano 2012-03-09 14:56 ` Jakub Narebski 2012-03-09 16:23 ` Junio C Hamano 2012-03-13 15:18 ` Jakub Narebski 2012-03-12 9:34 ` Matthieu Moy 2012-03-12 16:29 ` Junio C Hamano 2012-03-13 9:47 ` Matthieu Moy 2012-03-13 12:34 ` Junio C Hamano 2012-03-16 19:35 ` Junio C Hamano 2012-03-17 15:49 ` Eric Hanchrow 2012-03-08 17:37 ` Dmitry Potapov 2012-03-08 11:33 ` Jakub Narebski 2012-03-08 11:34 ` Jeremy Morton 2012-03-13 15:27 ` Jakub Narebski 2012-03-14 12:12 ` Jeremy Morton 2012-03-14 17:16 ` Jakub Narebski 2012-03-08 11:54 ` Matthieu Moy 2012-03-08 12:12 ` demerphq 2012-03-17 9:36 ` Sebastien Douche 2012-03-17 9:38 ` Jeremy Morton 2012-03-17 9:51 ` Sebastien Douche 2012-03-18 10:26 ` Pavel Pospíšil
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.