* [PATCH] Switch receive.denyCurrentBranch to "refuse" [not found] <cover.1233275583u.git.johannes.schindelin@gmx.de> @ 2009-01-30 0:34 ` Johannes Schindelin 2009-01-30 1:28 ` Jay Soffian ` (6 more replies) 0 siblings, 7 replies; 43+ messages in thread From: Johannes Schindelin @ 2009-01-30 0:34 UTC (permalink / raw) To: git; +Cc: gitster Many, many users set up non-bare repositories on their server, and are confused that the working directory is not updated. The reason may be that they did not read the manual, or that they found "helpful" walk-throughs via Google, or that they did not understand the concepts behind Git. Or, the reason could be that we made a design mistake, and that the number of puzzled new users should tell us something. Granted, we wanted to have a longer grace period for old-timers, but let's face it: - old-timers will have to edit their configs at some stage anyway, - for old-timers, it will be a matter of less than a minute, - new-timers will not spend frustrated hours, and - since there are many more new-timers now than old-timers, we should cater for them anyway. To make it easier for old-timers, the error message was enhanced to suggest how to allow updating the current branch easily. For the tests relying on the old behavior, receive.denyCurrentBranch was set to false, to avoid breaking them. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> --- Let's be honest here, I have not much respect for users who fail to read up enough to understand what they are doing. But hearing from those users constantly is really unnerving. And it would be a one-time cost to old-timers. builtin-receive-pack.c | 9 ++++++--- t/t5400-send-pack.sh | 5 ++++- t/t5401-update-hooks.sh | 1 + t/t5405-send-pack-rewind.sh | 1 + t/t5516-fetch-push.sh | 1 + t/t5517-push-mirror.sh | 3 ++- t/t5521-pull-symlink.sh | 1 + t/t5701-clone-local.sh | 2 +- 8 files changed, 17 insertions(+), 6 deletions(-) diff --git a/builtin-receive-pack.c b/builtin-receive-pack.c index 6564a97..e9510fc 100644 --- a/builtin-receive-pack.c +++ b/builtin-receive-pack.c @@ -19,7 +19,7 @@ enum deny_action { static int deny_deletes = 0; static int deny_non_fast_forwards = 0; -static enum deny_action deny_current_branch = DENY_WARN; +static enum deny_action deny_current_branch = DENY_REFUSE; static int receive_fsck_objects; static int receive_unpack_limit = -1; static int transfer_unpack_limit = -1; @@ -239,9 +239,12 @@ static const char *update(struct command *cmd) " that are now in HEAD."); break; case DENY_REFUSE: - if (!is_ref_checked_out(name)) + if (is_bare_repository() || !is_ref_checked_out(name)) break; - error("refusing to update checked out branch: %s", name); + error("refusing to update checked out branch: %s\n" + "if you know what you are doing, you can allow it by " + "setting\n\n" + "\tgit config receive.denyCurrentBranch true\n", name); return "branch is currently checked out"; } diff --git a/t/t5400-send-pack.sh b/t/t5400-send-pack.sh index b21317d..240380c 100755 --- a/t/t5400-send-pack.sh +++ b/t/t5400-send-pack.sh @@ -33,6 +33,7 @@ test_expect_success setup ' git update-ref HEAD "$commit" && git clone ./. victim && cd victim && + git config receive.denyCurrentBranch false && git log && cd .. && git update-ref HEAD "$zero" && @@ -131,13 +132,15 @@ test_expect_success \ cd .. && git clone parent child && cd child && git push --all && cd ../parent && - git branch -a >branches && ! grep origin/master branches + git branch -a >branches && ! grep origin/master branches && + cd .. ' rewound_push_setup() { rm -rf parent child && mkdir parent && cd parent && git init && echo one >file && git add file && git commit -m one && + git config receive.denyCurrentBranch false && echo two >file && git commit -a -m two && cd .. && git clone parent child && cd child && git reset --hard HEAD^ diff --git a/t/t5401-update-hooks.sh b/t/t5401-update-hooks.sh index 64f66c9..7f04b64 100755 --- a/t/t5401-update-hooks.sh +++ b/t/t5401-update-hooks.sh @@ -18,6 +18,7 @@ test_expect_success setup ' git update-ref refs/heads/master $commit0 && git update-ref refs/heads/tofail $commit1 && git clone ./. victim && + GIT_DIR=victim/.git git config receive.denyCurrentBranch false && GIT_DIR=victim/.git git update-ref refs/heads/tofail $commit1 && git update-ref refs/heads/master $commit1 && git update-ref refs/heads/tofail $commit0 diff --git a/t/t5405-send-pack-rewind.sh b/t/t5405-send-pack-rewind.sh index cb9aacc..37c1f23 100755 --- a/t/t5405-send-pack-rewind.sh +++ b/t/t5405-send-pack-rewind.sh @@ -6,6 +6,7 @@ test_description='forced push to replace commit we do not have' test_expect_success setup ' + git config receive.denyCurrentBranch false && >file1 && git add file1 && test_tick && git commit -m Initial && diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh index 4426df9..9ca2730 100755 --- a/t/t5516-fetch-push.sh +++ b/t/t5516-fetch-push.sh @@ -12,6 +12,7 @@ mk_empty () { ( cd testrepo && git init && + git config receive.denyCurrentBranch false && mv .git/hooks .git/hooks-disabled ) } diff --git a/t/t5517-push-mirror.sh b/t/t5517-push-mirror.sh index ea49ded..0a31a4e 100755 --- a/t/t5517-push-mirror.sh +++ b/t/t5517-push-mirror.sh @@ -19,7 +19,8 @@ mk_repo_pair () { mkdir mirror && ( cd mirror && - git init + git init && + git config receive.denyCurrentBranch false ) && mkdir master && ( diff --git a/t/t5521-pull-symlink.sh b/t/t5521-pull-symlink.sh index 5672b51..736c24e 100755 --- a/t/t5521-pull-symlink.sh +++ b/t/t5521-pull-symlink.sh @@ -14,6 +14,7 @@ test_description='pulling from symlinked subdir' # # The working directory is subdir-link. +git config receive.denyCurrentBranch false mkdir subdir echo file >subdir/file git add subdir/file diff --git a/t/t5701-clone-local.sh b/t/t5701-clone-local.sh index 3559d17..06b2f13 100755 --- a/t/t5701-clone-local.sh +++ b/t/t5701-clone-local.sh @@ -119,7 +119,7 @@ test_expect_success 'bundle clone with nonexistent HEAD' ' test_expect_success 'clone empty repository' ' cd "$D" && mkdir empty && - (cd empty && git init) && + (cd empty && git init && git config receive.denyCurrentBranch false) && git clone empty empty-clone && test_tick && (cd empty-clone -- 1.6.1.2.531.g6f52 ^ permalink raw reply related [flat|nested] 43+ messages in thread
* Re: [PATCH] Switch receive.denyCurrentBranch to "refuse" 2009-01-30 0:34 ` [PATCH] Switch receive.denyCurrentBranch to "refuse" Johannes Schindelin @ 2009-01-30 1:28 ` Jay Soffian 2009-01-30 1:32 ` Asheesh Laroia ` (5 subsequent siblings) 6 siblings, 0 replies; 43+ messages in thread From: Jay Soffian @ 2009-01-30 1:28 UTC (permalink / raw) To: Johannes Schindelin; +Cc: git, gitster On Thu, Jan 29, 2009 at 7:34 PM, Johannes Schindelin <johannes.schindelin@gmx.de> wrote: > Or, the reason could be that we made a design mistake, and that the > number of puzzled new users should tell us something. I happen to have spent some time looking at Mercurial the other day since I was curious how it's evolved since I last played with it, and so w/that perspective, I think that git did make a small design mistake. With mercurial, pull and push are symmetric opposites. Neither, by default, updates the working copy. (Confusingly for users of both mercurial and git, the mercurial equivalent of "git pull" is "hg fetch". Doh.) Anyway, I think that this may be what leads to confusion. git pull updates the working copy, and beginners I think expect that push, which sounds like the opposite of pull, ought do the same thing. j. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] Switch receive.denyCurrentBranch to "refuse" 2009-01-30 0:34 ` [PATCH] Switch receive.denyCurrentBranch to "refuse" Johannes Schindelin 2009-01-30 1:28 ` Jay Soffian @ 2009-01-30 1:32 ` Asheesh Laroia 2010-04-13 16:42 ` [PATCH] Switch receive.denyCurrentBranch to "refuse" Dave Abrahams 2010-04-13 17:57 ` [PATCH] Switch receive.denyCurrentBranch to "refuse" Junio C Hamano [not found] ` <7v4ozhd1wp.fsf@gitster.siamese.dyndns.org> ` (4 subsequent siblings) 6 siblings, 2 replies; 43+ messages in thread From: Asheesh Laroia @ 2009-01-30 1:32 UTC (permalink / raw) To: Johannes Schindelin; +Cc: git, gitster On Fri, 30 Jan 2009, Johannes Schindelin wrote: > case DENY_REFUSE: > - if (!is_ref_checked_out(name)) > + if (is_bare_repository() || !is_ref_checked_out(name)) > break; > - error("refusing to update checked out branch: %s", name); > + error("refusing to update checked out branch: %s\n" > + "if you know what you are doing, you can allow it by " > + "setting\n\n" > + "\tgit config receive.denyCurrentBranch true\n", name); It seems like those new users you're trying to protect could use an additional sentence, like: "A bare repository would not have this issue." or "You may prefer to have a bare repository instead." Being told how to do it right is even better than being told that you're doing it wrong. (-: -- Asheesh. -- Fame is a vapor; popularity an accident; the only earthly certainty is oblivion. -- Mark Twain ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] Switch receive.denyCurrentBranch to "refuse" 2009-01-30 1:32 ` Asheesh Laroia @ 2010-04-13 16:42 ` Dave Abrahams 2010-04-13 17:57 ` [PATCH] Switch receive.denyCurrentBranch to "refuse" Junio C Hamano 1 sibling, 0 replies; 43+ messages in thread From: Dave Abrahams @ 2010-04-13 16:42 UTC (permalink / raw) To: git Asheesh Laroia <asheesh <at> asheesh.org> writes: > Being told how to do it right is even better than being told that you're > doing it wrong. I would prefer if Git would simply "not refuse," but barring that, a more verbose error would be helpful. I knew what I was doing in http://github.com/jelmer/dulwich/issues/issue/17, but it took me a long time to even notice git's message. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] Switch receive.denyCurrentBranch to "refuse" 2009-01-30 1:32 ` Asheesh Laroia 2010-04-13 16:42 ` [PATCH] Switch receive.denyCurrentBranch to "refuse" Dave Abrahams @ 2010-04-13 17:57 ` Junio C Hamano 1 sibling, 0 replies; 43+ messages in thread From: Junio C Hamano @ 2010-04-13 17:57 UTC (permalink / raw) To: Asheesh Laroia; +Cc: Johannes Schindelin, git Asheesh Laroia <asheesh@asheesh.org> writes: > On Fri, 30 Jan 2009, Johannes Schindelin wrote: > >> case DENY_REFUSE: >> + if (is_bare_repository() || !is_ref_checked_out(name)) >> break; >> + error("refusing to update checked out branch: %s\n" >> + "if you know what you are doing, you can allow it by " >> + "setting\n\n" >> + "\tgit config receive.denyCurrentBranch true\n", name); > > Being told how to do it right is even better than being told that > you're doing it wrong. (-: Of course you are correct, but there are two _right ways_ that are completely different, depending on how the repository you are pushing into is meant to be used: - If you are using it as a shared central repository, a distribution point, or a back-up location, you don't need a working tree, and as you say, the "checked out branch" condition will not trigger, if you made it a bare one. - People do wish a way to keep a repository with a checkout, and that is often the reason why this codepath is triggered. They want a checkout in the repository (perhaps they are serving the files in them from a webserver). For them, "pushing into it" is not the ultimate goal, but "having its working tree and keeping it up-to-date" is. For that, pushing into a "reception branch" and merging that to the checkout from the post-update hook is probably the right way (Cf. [*1*] especially is "See also ..."). Also I do not think it would help users to suggest "bare repository" even for the first class of users. - If the user knows what a "bare" repository is, the user would realize "Hmm, I am not allowed to push to the checked out branch? Wait, this repository does not even need a working tree, so if I make it a bare one, I wouldn't have any checked out branch by definition and I wouldn't have this issue" without being told. - If the user does not know what a "bare" repository is, the user may not even realize that the target repository does not have to have a working tree. In such a case, there won't be a mental "click" between "checked out" and "bare" anyway. The added message to suggest "bare" will be another line of unintelligible gitspeak in the message to them. [Reference] *1* https://git.wiki.kernel.org/index.php/GitFaq#Why_won.27t_I_see_changes_in_the_remote_repo_after_.22git_push.22.3F ^ permalink raw reply [flat|nested] 43+ messages in thread
[parent not found: <7v4ozhd1wp.fsf@gitster.siamese.dyndns.org>]
* Re: [PATCH] Switch receive.denyCurrentBranch to "refuse" [not found] ` <7v4ozhd1wp.fsf@gitster.siamese.dyndns.org> @ 2009-01-30 2:18 ` Junio C Hamano 2009-01-30 13:24 ` Johannes Schindelin 0 siblings, 1 reply; 43+ messages in thread From: Junio C Hamano @ 2009-01-30 2:18 UTC (permalink / raw) To: Johannes Schindelin; +Cc: git I do not think this improves anything. @@ -239,9 +239,12 @@ static const char *update(struct command *cmd) " that are now in HEAD."); break; case DENY_REFUSE: - if (!is_ref_checked_out(name)) + if (is_bare_repository() || !is_ref_checked_out(name)) break; - error("refusing to update checked out branch: %s", name); + error("refusing to update checked out branch: %s\n" + "if you know what you are doing, you can allow it by " + "setting\n\n" + "\tgit config receive.denyCurrentBranch true\n", name); return "branch is currently checked out"; } As the message I am currently getting from such a push is: $ git push ../victim-010 next:master Total 0 (delta 0), reused 0 (delta 0) warning: updating the currently checked out branch; this may cause confusion, as the index and working tree do not reflect changes that are now in HEAD. To ../victim-010 a34a9db..d79e69c next -> master which is much better than what you did. It at least tries to explain why it is warning, even though I think it has a huge room for improvement. Saying "If you know what you are doing" never works in practice. It can serve as an excuse for you to later say, "See, I told you so", but that is the only usefulness of the expression, and everybody, especially the most clueless people, *think* they know what they are doing. You alluded that we wanted to make grace period much longer, but you want to cut it short. I think it is a huge mistake. The warning has only been there for the last two months, and only can be seen from v1.6.1-rc1 or newer software. These new people even haven't a chance to learn from the existing warning. I think what would work much better would be a patch that keeps the warn-but-allow as the default, but clarifies the warning message. Say these things in separate paragraphs, perhaps in red blinking letters: (1) what symptoms, that are easily observable by the most novice users, are caused by "index and work tree going out of sync" the warning talks about, and why that would not be what they want; (2) if the user did not mean to do it (and the user can tell by observing the symptom described in the previous point), describe what needs to be done to recover from the fallout this push has caused (we do not need a recipe; pointing at a URL or manpage is fine), and what switch to flip to prevent herself from doing it again in the future; (3) if the user did mean it, and finds the above two big warning annoying, what switch to flip to squelch the warning for future pushes. The goal of the warning should be to *force* people *choose*, either to silently-allow (aka DENY_IGNORE) or refuse (DENY_REFUSE), and give enough information for them to make an informed decision. We can afford to be annoyingly long, loud and verbose there. On the other hand, you cannot make the message for DENY_REFUSE annoyingly long, as people may have already chosen to say "please refuse my push into a live branch". If you are making "refuse" the default, an annoyingly long message is even worse. "Yeah, thanks for stopping me, but you do not have to remind me every time that I made a mistake in large red letters. I perfectly well know what I am doing, I perfectly well know that I did not want to push into that branch, I just made a mistake---you do not have to be so loud". I suspect that you cannot even be long enough to be informative, not to annoy people. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] Switch receive.denyCurrentBranch to "refuse" 2009-01-30 2:18 ` Junio C Hamano @ 2009-01-30 13:24 ` Johannes Schindelin 2009-01-30 16:33 ` Jeff King 0 siblings, 1 reply; 43+ messages in thread From: Johannes Schindelin @ 2009-01-30 13:24 UTC (permalink / raw) To: Junio C Hamano; +Cc: git Hi, On Thu, 29 Jan 2009, Junio C Hamano wrote: > @@ -239,9 +239,12 @@ static const char *update(struct command *cmd) > " that are now in HEAD."); > break; > case DENY_REFUSE: > - if (!is_ref_checked_out(name)) > + if (is_bare_repository() || !is_ref_checked_out(name)) > break; > - error("refusing to update checked out branch: %s", name); > + error("refusing to update checked out branch: %s\n" > + "if you know what you are doing, you can allow it by " > + "setting\n\n" > + "\tgit config receive.denyCurrentBranch true\n", name); > return "branch is currently checked out"; > } > > As the message I am currently getting from such a push is: > > $ git push ../victim-010 next:master > Total 0 (delta 0), reused 0 (delta 0) > warning: updating the currently checked out branch; this may cause confusion, > as the index and working tree do not reflect changes that are now in HEAD. > To ../victim-010 > a34a9db..d79e69c next -> master > > which is much better than what you did. It at least tries to explain why > it is warning, even though I think it has a huge room for improvement. I do not really care about the output. You are probably right, it should be different from what I proposed. > You alluded that we wanted to make grace period much longer, but you > want to cut it short. I think it is a huge mistake. The warning has > only been there for the last two months, and only can be seen from > v1.6.1-rc1 or newer software. These new people even haven't a chance to > learn from the existing warning. In reality, people will not learn from the warning. Those that are old-timers (and who should be warned in the first place, instead of refuses) will just happily ignore that there was a warning: the command they used so often and the worked all the time just happened to work -- again -- no matter what the output is. But we are really hurting new users, and let's face it, the balance of time cost currently is in a huge favor of the old-timers there. Not only are there many more newbies these days than old timers. No, the _time_ spent by an old-timer to read an appropriate message and fix the setup would be _substantially_ shorter than the _hours_ of frustration a newbie spends on the issue. And we claim to make decentralized repositories easy. > I think what would work much better would be a patch that keeps the > warn-but-allow as the default, but clarifies the warning message. As I said, I am _convinced_ that a warning will do nothing at all. Just like the warning about the dashed commands, nobody who should be concerned will notice it. > (1) what symptoms, that are easily observable by the most novice users, > are caused by "index and work tree going out of sync" the warning > talks about, and why that would not be what they want; > > (2) if the user did not mean to do it (and the user can tell by observing > the symptom described in the previous point), describe what needs to > be done to recover from the fallout this push has caused (we do not > need a recipe; pointing at a URL or manpage is fine), and what switch > to flip to prevent herself from doing it again in the future; > > (3) if the user did mean it, and finds the above two big warning > annoying, what switch to flip to squelch the warning for future > pushes. > > The goal of the warning should be to *force* people *choose*, either to > silently-allow (aka DENY_IGNORE) or refuse (DENY_REFUSE), and give enough > information for them to make an informed decision. We can afford to be > annoyingly long, loud and verbose there. > > On the other hand, you cannot make the message for DENY_REFUSE annoyingly > long, as people may have already chosen to say "please refuse my push into > a live branch". > > If you are making "refuse" the default, an annoyingly long message is even > worse. "Yeah, thanks for stopping me, but you do not have to remind me > every time that I made a mistake in large red letters. I perfectly well > know what I am doing, I perfectly well know that I did not want to push > into that branch, I just made a mistake---you do not have to be so loud". > > I suspect that you cannot even be long enough to be informative, not to > annoy people. Let's reap all the opinions about this issue, and then I'll do the wrap-up patch. But this is a serious issue that seriously needs to be coped with. We are getting another generation of "Git is difficult" users that way. Ciao, Dscho ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] Switch receive.denyCurrentBranch to "refuse" 2009-01-30 13:24 ` Johannes Schindelin @ 2009-01-30 16:33 ` Jeff King 2009-01-30 16:55 ` Johannes Schindelin 0 siblings, 1 reply; 43+ messages in thread From: Jeff King @ 2009-01-30 16:33 UTC (permalink / raw) To: Johannes Schindelin; +Cc: Junio C Hamano, git On Fri, Jan 30, 2009 at 02:24:57PM +0100, Johannes Schindelin wrote: > Let's reap all the opinions about this issue, and then I'll do the wrap-up > patch. I thought what Junio said was very reasonable (improve the message and give it some more time to work). But I honestly do not care that much either way. I probably would have made the original patch default to "deny" if not for discussion recommending to be conservative. On the other hand, I don't think we have really given the "warning" approach enough time to see whether it is working (and I don't necessarily disagree with your gut feeling that it won't work; I am undecided, which leads me to want more data). -Peff ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] Switch receive.denyCurrentBranch to "refuse" 2009-01-30 16:33 ` Jeff King @ 2009-01-30 16:55 ` Johannes Schindelin 0 siblings, 0 replies; 43+ messages in thread From: Johannes Schindelin @ 2009-01-30 16:55 UTC (permalink / raw) To: Jeff King; +Cc: Junio C Hamano, git Hi, On Fri, 30 Jan 2009, Jeff King wrote: > On Fri, Jan 30, 2009 at 02:24:57PM +0100, Johannes Schindelin wrote: > > > Let's reap all the opinions about this issue, and then I'll do the > > wrap-up patch. > > I thought what Junio said was very reasonable (improve the message and > give it some more time to work). > > But I honestly do not care that much either way. I probably would have > made the original patch default to "deny" if not for discussion > recommending to be conservative. On the other hand, I don't think we > have really given the "warning" approach enough time to see whether it > is working (and I don't necessarily disagree with your gut feeling that > it won't work; I am undecided, which leads me to want more data). It is not working: http://groups.google.com/group/msysgit/msg/55b1aa03fbbbefba?dmode=source (I am simply assuming that the mentioned 1.6.1-preview has the warning, since denyCurrentBranch is in v1.6.1-rc1~59^2, and I am too short on time to check it in detail (which would mean finding a Windows machine and running a test)). Ciao, Dscho ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] Switch receive.denyCurrentBranch to "refuse" 2009-01-30 0:34 ` [PATCH] Switch receive.denyCurrentBranch to "refuse" Johannes Schindelin ` (2 preceding siblings ...) [not found] ` <7v4ozhd1wp.fsf@gitster.siamese.dyndns.org> @ 2009-01-30 2:30 ` Miklos Vajna 2009-01-30 13:28 ` Johannes Schindelin 2009-01-30 2:55 ` Jeff King ` (2 subsequent siblings) 6 siblings, 1 reply; 43+ messages in thread From: Miklos Vajna @ 2009-01-30 2:30 UTC (permalink / raw) To: Johannes Schindelin; +Cc: git, gitster [-- Attachment #1: Type: text/plain, Size: 445 bytes --] On Fri, Jan 30, 2009 at 01:34:28AM +0100, Johannes Schindelin <johannes.schindelin@gmx.de> wrote: > - error("refusing to update checked out branch: %s", name); > + error("refusing to update checked out branch: %s\n" > + "if you know what you are doing, you can allow it by " > + "setting\n\n" > + "\tgit config receive.denyCurrentBranch true\n", name); Shouldn't this be git config receive.denyCurrentBranch ignore instead of "true"? [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --] ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] Switch receive.denyCurrentBranch to "refuse" 2009-01-30 2:30 ` Miklos Vajna @ 2009-01-30 13:28 ` Johannes Schindelin 2009-02-11 0:11 ` Miklos Vajna 0 siblings, 1 reply; 43+ messages in thread From: Johannes Schindelin @ 2009-01-30 13:28 UTC (permalink / raw) To: Miklos Vajna; +Cc: git, gitster Hi, On Fri, 30 Jan 2009, Miklos Vajna wrote: > On Fri, Jan 30, 2009 at 01:34:28AM +0100, Johannes Schindelin <johannes.schindelin@gmx.de> wrote: > > - error("refusing to update checked out branch: %s", name); > > + error("refusing to update checked out branch: %s\n" > > + "if you know what you are doing, you can allow it by " > > + "setting\n\n" > > + "\tgit config receive.denyCurrentBranch true\n", name); > > Shouldn't this be > > git config receive.denyCurrentBranch ignore > > instead of "true"? Right. However, as Junio pointed out, we do not want to give this resolution in the error message. I am now leaning more to something like refusing to update checked out branch '%s' in non-bare repository Hmm? Old-timers will know "oh, what the hell, I did not mark my repository as bare!", and new-timers will no longer be confused. Ciao, Dscho ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] Switch receive.denyCurrentBranch to "refuse" 2009-01-30 13:28 ` Johannes Schindelin @ 2009-02-11 0:11 ` Miklos Vajna 2009-02-11 1:04 ` Junio C Hamano 0 siblings, 1 reply; 43+ messages in thread From: Miklos Vajna @ 2009-02-11 0:11 UTC (permalink / raw) To: Johannes Schindelin; +Cc: git, gitster [-- Attachment #1: Type: text/plain, Size: 838 bytes --] [ Sorry for the late reply, I did not read my mail recently. ] On Fri, Jan 30, 2009 at 02:28:39PM +0100, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote: > > Shouldn't this be > > > > git config receive.denyCurrentBranch ignore > > > > instead of "true"? > > Right. > > However, as Junio pointed out, we do not want to give this resolution in > the error message. I am now leaning more to something like > > refusing to update checked out branch '%s' in non-bare repository > > Hmm? > > Old-timers will know "oh, what the hell, I did not mark my repository as > bare!", and new-timers will no longer be confused. So in an "I know what I'm doing" mode, is "git config core.bare true" in a non-bare repo considered as a better workaround than using "git config receive.denyCurrentBranch ignore"? [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --] ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] Switch receive.denyCurrentBranch to "refuse" 2009-02-11 0:11 ` Miklos Vajna @ 2009-02-11 1:04 ` Junio C Hamano 0 siblings, 0 replies; 43+ messages in thread From: Junio C Hamano @ 2009-02-11 1:04 UTC (permalink / raw) To: Miklos Vajna; +Cc: Johannes Schindelin, git, gitster Miklos Vajna <vmiklos@frugalware.org> writes: > [ Sorry for the late reply, I did not read my mail recently. ] > > On Fri, Jan 30, 2009 at 02:28:39PM +0100, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote: >> > Shouldn't this be >> > >> > git config receive.denyCurrentBranch ignore >> > >> > instead of "true"? >> >> Right. >> >> However, as Junio pointed out, we do not want to give this resolution in >> the error message. I am now leaning more to something like >> >> refusing to update checked out branch '%s' in non-bare repository >> >> Hmm? >> >> Old-timers will know "oh, what the hell, I did not mark my repository as >> bare!", and new-timers will no longer be confused. > > So in an "I know what I'm doing" mode, is "git config core.bare true" in > a non-bare repo considered as a better workaround than using "git config > receive.denyCurrentBranch ignore"? If you have to ask, you do not know what you're doing ;-) ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] Switch receive.denyCurrentBranch to "refuse" 2009-01-30 0:34 ` [PATCH] Switch receive.denyCurrentBranch to "refuse" Johannes Schindelin ` (3 preceding siblings ...) 2009-01-30 2:30 ` Miklos Vajna @ 2009-01-30 2:55 ` Jeff King 2009-01-30 14:11 ` Johannes Schindelin 2009-01-30 7:17 ` Johannes Sixt 2009-01-30 16:17 ` Jay Soffian 6 siblings, 1 reply; 43+ messages in thread From: Jeff King @ 2009-01-30 2:55 UTC (permalink / raw) To: Johannes Schindelin; +Cc: git, gitster On Fri, Jan 30, 2009 at 01:34:28AM +0100, Johannes Schindelin wrote: > Let's be honest here, I have not much respect for users who fail > to read up enough to understand what they are doing. > > But hearing from those users constantly is really unnerving. And > it would be a one-time cost to old-timers. I am not personally opposed to changing this default. I seem to recall some opposition when this was brought up initially, but I don't recall any specific reason besides "change is bad". Maybe those who oppose want to summarize their arguments here. I was hoping that introducing the warning would cause new users to "get it". But since this warning was put in place, I think we have still gotten a few questions on the list about this. I don't know if it simply because they are on older versions, or if the warning is insufficient. If the former, then perhaps that argues for leaving it a little longer. > case DENY_REFUSE: > - if (!is_ref_checked_out(name)) > + if (is_bare_repository() || !is_ref_checked_out(name)) Now what is this change about? > --- a/t/t5701-clone-local.sh > +++ b/t/t5701-clone-local.sh > @@ -119,7 +119,7 @@ test_expect_success 'bundle clone with nonexistent HEAD' ' > test_expect_success 'clone empty repository' ' > cd "$D" && > mkdir empty && > - (cd empty && git init) && > + (cd empty && git init && git config receive.denyCurrentBranch false) && > git clone empty empty-clone && > test_tick && > (cd empty-clone Perhaps some of these tests would do better to actually just use a bare repository. That would better match the expected workflow for cloning empty, anyway. -Peff ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] Switch receive.denyCurrentBranch to "refuse" 2009-01-30 2:55 ` Jeff King @ 2009-01-30 14:11 ` Johannes Schindelin 0 siblings, 0 replies; 43+ messages in thread From: Johannes Schindelin @ 2009-01-30 14:11 UTC (permalink / raw) To: Jeff King; +Cc: git, gitster Hi, On Thu, 29 Jan 2009, Jeff King wrote: > On Fri, Jan 30, 2009 at 01:34:28AM +0100, Johannes Schindelin wrote: > > > Let's be honest here, I have not much respect for users who fail > > to read up enough to understand what they are doing. > > > > But hearing from those users constantly is really unnerving. And > > it would be a one-time cost to old-timers. > > I am not personally opposed to changing this default. I seem to > recall some opposition when this was brought up initially, but I don't > recall any specific reason besides "change is bad". Maybe those who > oppose want to summarize their arguments here. We like to play it safe when changing behavior that does not meet expectations of old-timers. For example, all those early adopters who have forks of the linux-2.6 repository (and probably that repository itself, too) do not have core.bare set. So whenever an old-timer would upgrade to a new Git _with_ my patch, they would need to change their setup. A one-time cost. And far easier to accomodate than the push for non-dashed commands (which people still seem to grumble about, even if they should have realized by now that calling Git through the wrapper exclusively brings so many advantages). > I was hoping that introducing the warning would cause new users to "get > it". But since this warning was put in place, I think we have still > gotten a few questions on the list about this. I don't know if it simply > because they are on older versions, or if the warning is insufficient. > If the former, then perhaps that argues for leaving it a little longer. I would argue it is because users cannot read :-) > > case DENY_REFUSE: > > - if (!is_ref_checked_out(name)) > > + if (is_bare_repository() || !is_ref_checked_out(name)) > > Now what is this change about? I missed the fact that is_ref_checked_out() already checked for that. > > --- a/t/t5701-clone-local.sh > > +++ b/t/t5701-clone-local.sh > > @@ -119,7 +119,7 @@ test_expect_success 'bundle clone with nonexistent HEAD' ' > > test_expect_success 'clone empty repository' ' > > cd "$D" && > > mkdir empty && > > - (cd empty && git init) && > > + (cd empty && git init && git config receive.denyCurrentBranch false) && > > git clone empty empty-clone && > > test_tick && > > (cd empty-clone > > Perhaps some of these tests would do better to actually just use a bare > repository. Right. I just ran out of time, but did not want to hide the patch from the community. > That would better match the expected workflow for cloning empty, anyway. Well, I did not want to mix up the two of them. Besides, I have this patch in my personal tree for quite some time now, always wanting to clean it up enough to send it...) Ciao, Dscho ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] Switch receive.denyCurrentBranch to "refuse" 2009-01-30 0:34 ` [PATCH] Switch receive.denyCurrentBranch to "refuse" Johannes Schindelin ` (4 preceding siblings ...) 2009-01-30 2:55 ` Jeff King @ 2009-01-30 7:17 ` Johannes Sixt 2009-01-30 7:34 ` Jeff King 2009-01-30 16:17 ` Jay Soffian 6 siblings, 1 reply; 43+ messages in thread From: Johannes Sixt @ 2009-01-30 7:17 UTC (permalink / raw) To: Johannes Schindelin; +Cc: git, gitster Johannes Schindelin schrieb: > + error("refusing to update checked out branch: %s\n" > + "if you know what you are doing, you can allow it by " > + "setting\n\n" > + "\tgit config receive.denyCurrentBranch true\n", name); Oh, fscking hell, I should have screamed out loudly when Jeff named this option "denyCurrentBranch" instead of "allowCurrentBranch". It's all too easy to fall into the trap, like you here. Sigh. -- J we-don't-need-no-double-negations 6t ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] Switch receive.denyCurrentBranch to "refuse" 2009-01-30 7:17 ` Johannes Sixt @ 2009-01-30 7:34 ` Jeff King 2009-01-30 13:23 ` Johannes Schindelin 0 siblings, 1 reply; 43+ messages in thread From: Jeff King @ 2009-01-30 7:34 UTC (permalink / raw) To: Johannes Sixt; +Cc: Johannes Schindelin, git, gitster On Fri, Jan 30, 2009 at 08:17:48AM +0100, Johannes Sixt wrote: > Johannes Schindelin schrieb: > > + error("refusing to update checked out branch: %s\n" > > + "if you know what you are doing, you can allow it by " > > + "setting\n\n" > > + "\tgit config receive.denyCurrentBranch true\n", name); > > Oh, fscking hell, I should have screamed out loudly when Jeff named this > option "denyCurrentBranch" instead of "allowCurrentBranch". It's all too > easy to fall into the trap, like you here. Sorry. ;P On the other hand, you also missed the boat on receive.denyDeletes and receive.denyNonFastForwards. -Peff ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] Switch receive.denyCurrentBranch to "refuse" 2009-01-30 7:34 ` Jeff King @ 2009-01-30 13:23 ` Johannes Schindelin 2009-01-30 14:35 ` Jeff King 0 siblings, 1 reply; 43+ messages in thread From: Johannes Schindelin @ 2009-01-30 13:23 UTC (permalink / raw) To: Jeff King; +Cc: Johannes Sixt, git, gitster Hi, On Fri, 30 Jan 2009, Jeff King wrote: > On Fri, Jan 30, 2009 at 08:17:48AM +0100, Johannes Sixt wrote: > > > Johannes Schindelin schrieb: > > > + error("refusing to update checked out branch: %s\n" > > > + "if you know what you are doing, you can allow it by " > > > + "setting\n\n" > > > + "\tgit config receive.denyCurrentBranch true\n", name); > > > > Oh, fscking hell, I should have screamed out loudly when Jeff named this > > option "denyCurrentBranch" instead of "allowCurrentBranch". It's all too > > easy to fall into the trap, like you here. > > Sorry. ;P > > On the other hand, you also missed the boat on receive.denyDeletes and > receive.denyNonFastForwards. The idea with these is that they are _booleans_, and therefore [receive] denyDeletes is something natural to write, because "denyDeletes" is _not_ the default. However, with denyCurrentBranch we wanted to change the default in the long run, so I agree it was a not-so-brilliant choice. Ciao, Dscho ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] Switch receive.denyCurrentBranch to "refuse" 2009-01-30 13:23 ` Johannes Schindelin @ 2009-01-30 14:35 ` Jeff King 0 siblings, 0 replies; 43+ messages in thread From: Jeff King @ 2009-01-30 14:35 UTC (permalink / raw) To: Johannes Schindelin; +Cc: Johannes Sixt, git, gitster On Fri, Jan 30, 2009 at 02:23:02PM +0100, Johannes Schindelin wrote: > > On the other hand, you also missed the boat on receive.denyDeletes and > > receive.denyNonFastForwards. > > The idea with these is that they are _booleans_, and therefore > > [receive] > denyDeletes > > is something natural to write, because "denyDeletes" is _not_ the default. > > However, with denyCurrentBranch we wanted to change the default in the > long run, so I agree it was a not-so-brilliant choice. Good point. I do agree that allowCurrentBranch would have been a better name, but I don't know that it is worth the pain now of adding new config plus supporting the old name forever. -Peff ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] Switch receive.denyCurrentBranch to "refuse" 2009-01-30 0:34 ` [PATCH] Switch receive.denyCurrentBranch to "refuse" Johannes Schindelin ` (5 preceding siblings ...) 2009-01-30 7:17 ` Johannes Sixt @ 2009-01-30 16:17 ` Jay Soffian 2009-01-30 16:28 ` Jeff King 2009-01-30 17:01 ` Johannes Schindelin 6 siblings, 2 replies; 43+ messages in thread From: Jay Soffian @ 2009-01-30 16:17 UTC (permalink / raw) To: Johannes Schindelin; +Cc: git, gitster On Thu, Jan 29, 2009 at 7:34 PM, Johannes Schindelin <johannes.schindelin@gmx.de> wrote: > Many, many users set up non-bare repositories on their server, and are > confused that the working directory is not updated. This comes up on the list from time-to-time and is even in the FAQ. It has even been suggested that HEAD be detached when pushing into a non-bare repository, but I am not suggesting that again. I wonder if it might be helpful to teach clone to setup a push line in the cloned repo. i.e.: [remote "origin"] url = ... fetch = +refs/heads/*:refs/remotes/origin/* push = refs/heads/*:refs/remotes/origin/* This could be a configurable default behavior when cloning from a non-bare repo (can that be determined?) and/or as a switch (--satellite perhaps?). j. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] Switch receive.denyCurrentBranch to "refuse" 2009-01-30 16:17 ` Jay Soffian @ 2009-01-30 16:28 ` Jeff King 2009-01-30 17:01 ` Johannes Schindelin 1 sibling, 0 replies; 43+ messages in thread From: Jeff King @ 2009-01-30 16:28 UTC (permalink / raw) To: Jay Soffian; +Cc: Johannes Schindelin, git, gitster On Fri, Jan 30, 2009 at 11:17:49AM -0500, Jay Soffian wrote: > I wonder if it might be helpful to teach clone to setup a push line in > the cloned repo. i.e.: > > [remote "origin"] > url = ... > fetch = +refs/heads/*:refs/remotes/origin/* > push = refs/heads/*:refs/remotes/origin/* That refspec doesn't make sense, since the downstream is not the "origin" to the upstream repo. But I don't think this is a good solution; it is fundamentally changing the layout of pushed branches in the upstream repo, which is going to cause a lot of confusion. > This could be a configurable default behavior when cloning from a > non-bare repo (can that be determined?) and/or as a switch > (--satellite perhaps?). I don't think you can tell whether a repo you are cloning is bare. -Peff ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] Switch receive.denyCurrentBranch to "refuse" 2009-01-30 16:17 ` Jay Soffian 2009-01-30 16:28 ` Jeff King @ 2009-01-30 17:01 ` Johannes Schindelin 2009-01-30 18:50 ` Jay Soffian 1 sibling, 1 reply; 43+ messages in thread From: Johannes Schindelin @ 2009-01-30 17:01 UTC (permalink / raw) To: Jay Soffian; +Cc: git, gitster Hi, On Fri, 30 Jan 2009, Jay Soffian wrote: > On Thu, Jan 29, 2009 at 7:34 PM, Johannes Schindelin > <johannes.schindelin@gmx.de> wrote: > > Many, many users set up non-bare repositories on their server, and are > > confused that the working directory is not updated. > > This comes up on the list from time-to-time and is even in the FAQ. So much so that it is high time we admitted that we have a design bug there. > It has even been suggested that HEAD be detached when pushing into a > non-bare repository, but I am not suggesting that again. No, because that would be as wrong as trying to update the working directory in any other way. (Not only is it possible that you are a git-shell user, in which case you have no business meddling with the working directory -- or the symbolic ref HEAD -- to begin with, but you also run into the problem that you might not know where the working directory is at all, let alone if there is one.) So it is a good thing you are not suggesting it again. > I wonder if it might be helpful to teach clone to setup a push line in > the cloned repo. i.e.: > > [remote "origin"] > url = ... > fetch = +refs/heads/*:refs/remotes/origin/* > push = refs/heads/*:refs/remotes/origin/* > > This could be a configurable default behavior when cloning from a > non-bare repo (can that be determined?) and/or as a switch > (--satellite perhaps?). As Peff commented, this would be horribly wrong if the remote has a different "origin" remote. Not forcing the push does not help either, it is still wrong. But I think there is an even more fundamental problem: You do not want that default push. We have "push only those refs the remote and the local repository share" rule for a reason. It is way too easy to publish something you did not mean to publish otherwise. Ciao, Dscho ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] Switch receive.denyCurrentBranch to "refuse" 2009-01-30 17:01 ` Johannes Schindelin @ 2009-01-30 18:50 ` Jay Soffian 2009-01-30 19:03 ` Johannes Schindelin 0 siblings, 1 reply; 43+ messages in thread From: Jay Soffian @ 2009-01-30 18:50 UTC (permalink / raw) To: Johannes Schindelin; +Cc: git, gitster On Fri, Jan 30, 2009 at 12:01 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote: > As Peff commented, this would be horribly wrong if the remote has a > different "origin" remote. Not forcing the push does not help either, it > is still wrong. Got it. Here was my impression of the work-flow we're trying to help beginners with: machineA$ mkdir repo machineA$ cd repo machineA$ git init machineA$ add, commit, add, commit... machineB$ git clone ssh://machine1/repo machineB$ add, commit, add, commit... machineB$ git push (And if my impression is wrong, then stop me right here and I'll shut-up on this thread.) In this case, the clone operation sets up the repo on B to fetch all of the branches from the repo on A. But it doesn't do anything to help the user with pushing the repo from B back to machine A. So perhaps: git clone --origin machineA --push-as machineB ssh://machineA/repo [remote "machineA"] url = ... fetch = +refs/heads/*:refs/remotes/machineA/* push = +refs/heads/*:refs/remotes/machineB/* Now fetch and push are symmetric operations on machineB. > But I think there is an even more fundamental problem: You do not want > that default push. We have "push only those refs the remote and the local > repository share" rule for a reason. It is way too easy to publish > something you did not mean to publish otherwise. I don't have a good answer for that, other than to say that if user is setting up symmetric repositories, user wants to push everything. j. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] Switch receive.denyCurrentBranch to "refuse" 2009-01-30 18:50 ` Jay Soffian @ 2009-01-30 19:03 ` Johannes Schindelin 2009-01-31 0:56 ` Nanako Shiraishi 0 siblings, 1 reply; 43+ messages in thread From: Johannes Schindelin @ 2009-01-30 19:03 UTC (permalink / raw) To: Jay Soffian; +Cc: git, gitster Hi, On Fri, 30 Jan 2009, Jay Soffian wrote: > On Fri, Jan 30, 2009 at 12:01 PM, Johannes Schindelin > <Johannes.Schindelin@gmx.de> wrote: > > As Peff commented, this would be horribly wrong if the remote has a > > different "origin" remote. Not forcing the push does not help either, > > it is still wrong. > > Got it. Here was my impression of the work-flow we're trying to help > beginners with: > > machineA$ mkdir repo > machineA$ cd repo > machineA$ git init > machineA$ add, commit, add, commit... > > machineB$ git clone ssh://machine1/repo > machineB$ add, commit, add, commit... > machineB$ git push > > (And if my impression is wrong, then stop me right here and I'll > shut-up on this thread.) I think your impression is not wrong. BUT. You cannot just cater for one workflow and fsck the other workflows over. You'll have to devise a method that helps the workflow you are interested in, but leaves the others alone. Example: the thing I heard most often was "I want to start this repository, but there is nothing in there yet, yet I want other people to clone it already so they'll see something when I do." I admit, it does not strike me sensible, but so does cloning an empty repository. As I could not understand how people would want to vote for Bush. Yet they did, so I guess I'll have to live with it. Ciao, Dscho ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] Switch receive.denyCurrentBranch to "refuse" 2009-01-30 19:03 ` Johannes Schindelin @ 2009-01-31 0:56 ` Nanako Shiraishi 2009-02-01 1:27 ` Junio C Hamano ` (2 more replies) 0 siblings, 3 replies; 43+ messages in thread From: Nanako Shiraishi @ 2009-01-31 0:56 UTC (permalink / raw) To: Johannes Schindelin; +Cc: Jay Soffian, git, gitster Quoting Johannes Schindelin <Johannes.Schindelin@gmx.de>: > You cannot just cater for one workflow and fsck the other workflows over. > > You'll have to devise a method that helps the workflow you are interested > in, but leaves the others alone. I think you'd want to repeat that to yourself when you propose to switch the default for denyCurrentcurrentBranch config to "true" too hastily the next time? I don't think your patch matches the tradition of how defaults are changed in git project. You don't introduce a large change just after the maintainer hints about going into a freeze for 1.X.Y release when Y isn't zero. I assume that everybody, including the maintainer who is too heavyweight and has too much inertia to accept too sudden a change of the course, wants to eventually make the default to deny pushing to the current branch. But I think such a change should come at 1.7.0 release at the earliest, and a constructive thing to do is to put in a patch to 1.6.2 that helps the users with the eventual transition. How about doing these before the 1.7.0 release? 1. Add some code to git-clone to set the config to "deny" if it is not a bare repository. The reason I think this makes sense is because the reason why old-timers want to push into the current branch is because they are used to the old layout that doesn't use separate remotes. If they use today's git-clone and still want to use the old layout, they need to update the config file in the new clone anyway. The "deny" is just another thing for them to fix at that point. I suspect that Junio will not like this in 1.6.2 because it is an unannounced and unplanned change in behavior, but I think it is a reasonable preparatory step, probably in 1.6.3, before you change the default to deny in release 1.7.0. 2. Reword the warning message as Junio suggested in his response. I don't know the details of the code very well, but I think you can tell a repository that doesn't have the config at all from a repository that has the config set to "warn", and you can use "annoyingly long" (in Junio's words) message to force the user set the config to a desired value only when pushing into the former kind, and say that the default will change to deny in release 1.7.0. When pushing into the latter, the warning message can be shorter (probably you can say "warning: updating the current branch in a non-bare repository" and nothing else). 3. Reword the error message as you proposed to say "error: won't update the current branch in a non-bare repository", without saying anything else. You want to eventually change the default to deny, and there is no point to teach how to allow it to people who set the config to deny themselves, nor to new people who created their repository with updated git-clone. I think this makes sense to do in 1.6.2 release, because the only people who will see this message will be the people who set the config to deny themselves, especially if you postpone the change to git-clone for the upcoming release. What do people think? -- Nanako Shiraishi http://ivory.ap.teacup.com/nanako3/ ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] Switch receive.denyCurrentBranch to "refuse" 2009-01-31 0:56 ` Nanako Shiraishi @ 2009-02-01 1:27 ` Junio C Hamano 2009-02-01 1:39 ` Junio C Hamano 2009-02-02 12:41 ` Jeff King 2009-02-01 2:06 ` Junio C Hamano 2009-02-01 22:59 ` Johannes Schindelin 2 siblings, 2 replies; 43+ messages in thread From: Junio C Hamano @ 2009-02-01 1:27 UTC (permalink / raw) To: Nanako Shiraishi; +Cc: Johannes Schindelin, Jay Soffian, git Nanako Shiraishi <nanako3@lavabit.com> writes: > How about doing these before the 1.7.0 release? > ... > What do people think? I haven't manged to convince myself about the "git init" change (I have the code and also I've looked at the extent of damage the change causes to the existing test suite), but at least I think it is a sensible suggestion to differentiate between unconfigured-wwwand-defaults-to-warn case and configured-to-warn-so-we-warn case. Something like this. -- >8 -- Subject: [PATCH] receive-pack: explain what to do when push updates the current branch This makes "git push" issue a more detailed instruction when a user pushes into the current branch of a non-bare repository without having an explicit configuration set to receive.denycurrentbranch. In such a case, it will also tell the user that the default will change to refusal in a future version of git. Signed-off-by: Junio C Hamano <gitster@pobox.com> --- builtin-receive-pack.c | 58 +++++++++++++++++++++++++++++++++++------------ t/t5516-fetch-push.sh | 6 ++-- 2 files changed, 46 insertions(+), 18 deletions(-) diff --git a/builtin-receive-pack.c b/builtin-receive-pack.c index 6564a97..f2c94fc 100644 --- a/builtin-receive-pack.c +++ b/builtin-receive-pack.c @@ -12,6 +12,7 @@ static const char receive_pack_usage[] = "git-receive-pack <git-dir>"; enum deny_action { + DENY_UNCONFIGURED, DENY_IGNORE, DENY_WARN, DENY_REFUSE, @@ -19,7 +20,7 @@ enum deny_action { static int deny_deletes = 0; static int deny_non_fast_forwards = 0; -static enum deny_action deny_current_branch = DENY_WARN; +static enum deny_action deny_current_branch = DENY_UNCONFIGURED; static int receive_fsck_objects; static int receive_unpack_limit = -1; static int transfer_unpack_limit = -1; @@ -214,6 +215,35 @@ static int is_ref_checked_out(const char *ref) return !strcmp(head, ref); } +static char *warn_unconfigured_deny_msg[] = { + "Updating the currently checked out branch may cause confusion,", + "as the index and work tree do not reflect changes that are in HEAD." + "As a result, you may see the changes you just pushed into it", + "reverted when you run 'git diff' over there, and you may want", + "to run 'git reset --hard' before starting to work to recover.", + "", + "You can set 'receive.denyCurrentBranch' configuration variable to", + "'refuse' in the repository to forbid pushing into the current branch", + "of it." + "", + "To allow pushing into the current branch, you can set it to 'ignore';", + "but this is not recommended unless you really know what you are doing.", + "", + "To squelch this message, you can set it to 'warn'.", + "", + "Note that the default will change in a future version of git", + "to refuse updating the currentbranch unless you have the", + "configuration variable set to either 'ignore' or 'warn'." +}; + +static void warn_unconfigured_deny(void) +{ + int i; + for (i = 0; i < ARRAY_SIZE(warn_unconfigured_deny_msg); i++) + warning(warn_unconfigured_deny_msg[i]); +} + + static const char *update(struct command *cmd) { const char *name = cmd->ref_name; @@ -227,22 +257,20 @@ static const char *update(struct command *cmd) return "funny refname"; } - switch (deny_current_branch) { - case DENY_IGNORE: - break; - case DENY_WARN: - if (!is_ref_checked_out(name)) + if (is_ref_checked_out(name)) { + switch (deny_current_branch) { + case DENY_IGNORE: break; - warning("updating the currently checked out branch; this may" - " cause confusion,\n" - "as the index and working tree do not reflect changes" - " that are now in HEAD."); - break; - case DENY_REFUSE: - if (!is_ref_checked_out(name)) + case DENY_UNCONFIGURED: + case DENY_WARN: + warning("updating the current branch"); + if (deny_current_branch == DENY_UNCONFIGURED) + warn_unconfigured_deny(); break; - error("refusing to update checked out branch: %s", name); - return "branch is currently checked out"; + case DENY_REFUSE: + error("refusing to update checked out branch: %s", name); + return "branch is currently checked out"; + } } if (!is_null_sha1(new_sha1) && !has_sha1_file(new_sha1)) { diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh index 4426df9..89649e7 100755 --- a/t/t5516-fetch-push.sh +++ b/t/t5516-fetch-push.sh @@ -492,7 +492,7 @@ test_expect_success 'warn on push to HEAD of non-bare repository' ' git checkout master && git config receive.denyCurrentBranch warn) && git push testrepo master 2>stderr && - grep "warning.*this may cause confusion" stderr + grep "warning: updating the current branch" stderr ' test_expect_success 'deny push to HEAD of non-bare repository' ' @@ -510,7 +510,7 @@ test_expect_success 'allow push to HEAD of bare repository (bare)' ' git config receive.denyCurrentBranch true && git config core.bare true) && git push testrepo master 2>stderr && - ! grep "warning.*this may cause confusion" stderr + ! grep "warning: updating the current branch" stderr ' test_expect_success 'allow push to HEAD of non-bare repository (config)' ' @@ -520,7 +520,7 @@ test_expect_success 'allow push to HEAD of non-bare repository (config)' ' git config receive.denyCurrentBranch false ) && git push testrepo master 2>stderr && - ! grep "warning.*this may cause confusion" stderr + ! grep "warning: updating the current branch" stderr ' test_expect_success 'fetch with branches' ' -- 1.6.1.2.312.g5be3c ^ permalink raw reply related [flat|nested] 43+ messages in thread
* Re: [PATCH] Switch receive.denyCurrentBranch to "refuse" 2009-02-01 1:27 ` Junio C Hamano @ 2009-02-01 1:39 ` Junio C Hamano 2009-02-02 12:41 ` Jeff King 1 sibling, 0 replies; 43+ messages in thread From: Junio C Hamano @ 2009-02-01 1:39 UTC (permalink / raw) To: Nanako Shiraishi; +Cc: Johannes Schindelin, Jay Soffian, git Junio C Hamano <gitster@pobox.com> writes: > I haven't manged to convince myself about the "git init" change (I have > the code and also I've looked at the extent of damage the change causes to > the existing test suite),... And here is such a patch. -- >8 -- Subject: [PATCH] Set receive.denyCurrentBranch to true in a new non-bare repository This prepares new people to get used to the default planned for 1.7.0; necessary adjustments are done to many tests, as they all assumed the traditional "only warn but allow updating" semantics. Signed-off-by: Junio C Hamano <gitster@pobox.com> --- builtin-init-db.c | 2 ++ t/t5400-send-pack.sh | 2 ++ t/t5401-update-hooks.sh | 1 + t/t5405-send-pack-rewind.sh | 1 + t/t5516-fetch-push.sh | 1 + t/t5517-push-mirror.sh | 3 ++- t/t5521-pull-symlink.sh | 20 +++++++++++++------- t/t5701-clone-local.sh | 4 +++- 8 files changed, 25 insertions(+), 9 deletions(-) diff --git a/builtin-init-db.c b/builtin-init-db.c index ee3911f..26c10cc 100644 --- a/builtin-init-db.c +++ b/builtin-init-db.c @@ -250,6 +250,8 @@ static int create_default_files(const char *template_path) strcmp(git_dir + strlen(work_tree), "/.git")) { git_config_set("core.worktree", work_tree); } + if (!reinit) + git_config_set("receive.denyCurrentBranch", "refuse"); } if (!reinit) { diff --git a/t/t5400-send-pack.sh b/t/t5400-send-pack.sh index b21317d..5c9c277 100755 --- a/t/t5400-send-pack.sh +++ b/t/t5400-send-pack.sh @@ -33,6 +33,7 @@ test_expect_success setup ' git update-ref HEAD "$commit" && git clone ./. victim && cd victim && + git config receive.denyCurrentBranch warn && git log && cd .. && git update-ref HEAD "$zero" && @@ -138,6 +139,7 @@ rewound_push_setup() { rm -rf parent child && mkdir parent && cd parent && git init && echo one >file && git add file && git commit -m one && + git config receive.denyCurrentBranch warn && echo two >file && git commit -a -m two && cd .. && git clone parent child && cd child && git reset --hard HEAD^ diff --git a/t/t5401-update-hooks.sh b/t/t5401-update-hooks.sh index 64f66c9..325714e 100755 --- a/t/t5401-update-hooks.sh +++ b/t/t5401-update-hooks.sh @@ -18,6 +18,7 @@ test_expect_success setup ' git update-ref refs/heads/master $commit0 && git update-ref refs/heads/tofail $commit1 && git clone ./. victim && + GIT_DIR=victim/.git git config receive.denyCurrentBranch warn && GIT_DIR=victim/.git git update-ref refs/heads/tofail $commit1 && git update-ref refs/heads/master $commit1 && git update-ref refs/heads/tofail $commit0 diff --git a/t/t5405-send-pack-rewind.sh b/t/t5405-send-pack-rewind.sh index cb9aacc..4bda18a 100755 --- a/t/t5405-send-pack-rewind.sh +++ b/t/t5405-send-pack-rewind.sh @@ -8,6 +8,7 @@ test_expect_success setup ' >file1 && git add file1 && test_tick && git commit -m Initial && + git config receive.denyCurrentBranch warn && mkdir another && ( cd another && diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh index 89649e7..a67ebd0 100755 --- a/t/t5516-fetch-push.sh +++ b/t/t5516-fetch-push.sh @@ -12,6 +12,7 @@ mk_empty () { ( cd testrepo && git init && + git config receive.denyCurrentBranch warn && mv .git/hooks .git/hooks-disabled ) } diff --git a/t/t5517-push-mirror.sh b/t/t5517-push-mirror.sh index ea49ded..e2ad260 100755 --- a/t/t5517-push-mirror.sh +++ b/t/t5517-push-mirror.sh @@ -19,7 +19,8 @@ mk_repo_pair () { mkdir mirror && ( cd mirror && - git init + git init && + git config receive.denyCurrentBranch warn ) && mkdir master && ( diff --git a/t/t5521-pull-symlink.sh b/t/t5521-pull-symlink.sh index 5672b51..66b5ac1 100755 --- a/t/t5521-pull-symlink.sh +++ b/t/t5521-pull-symlink.sh @@ -14,13 +14,19 @@ test_description='pulling from symlinked subdir' # # The working directory is subdir-link. -mkdir subdir -echo file >subdir/file -git add subdir/file -git commit -q -m file -git clone -q . clone-repo -ln -s clone-repo/subdir/ subdir-link - +test_expect_success setup ' + mkdir subdir && + echo file >subdir/file && + git add subdir/file && + git commit -q -m file && + git clone -q . clone-repo && + ln -s clone-repo/subdir/ subdir-link && + ( + cd clone-repo && + git config receive.denyCurrentBranch warn + ) && + git config receive.denyCurrentBranch warn +' # Demonstrate that things work if we just avoid the symlink # diff --git a/t/t5701-clone-local.sh b/t/t5701-clone-local.sh index 3559d17..10accc2 100755 --- a/t/t5701-clone-local.sh +++ b/t/t5701-clone-local.sh @@ -119,7 +119,9 @@ test_expect_success 'bundle clone with nonexistent HEAD' ' test_expect_success 'clone empty repository' ' cd "$D" && mkdir empty && - (cd empty && git init) && + (cd empty && + git init && + git config receive.denyCurrentBranch warn) && git clone empty empty-clone && test_tick && (cd empty-clone -- 1.6.1.2.312.g5be3c ^ permalink raw reply related [flat|nested] 43+ messages in thread
* Re: [PATCH] Switch receive.denyCurrentBranch to "refuse" 2009-02-01 1:27 ` Junio C Hamano 2009-02-01 1:39 ` Junio C Hamano @ 2009-02-02 12:41 ` Jeff King 2009-02-03 4:30 ` Junio C Hamano 2009-02-03 8:01 ` Junio C Hamano 1 sibling, 2 replies; 43+ messages in thread From: Jeff King @ 2009-02-02 12:41 UTC (permalink / raw) To: Junio C Hamano; +Cc: Nanako Shiraishi, Johannes Schindelin, Jay Soffian, git On Sat, Jan 31, 2009 at 05:27:45PM -0800, Junio C Hamano wrote: > I haven't manged to convince myself about the "git init" change (I have > the code and also I've looked at the extent of damage the change causes to I think the "git init" change doesn't make sense. In fact, I don't think such a proposal ever really makes sense (and I have even proposed it in the past, but others arguments have changed my way of thinking). The reason is that you are just moving the breakage to a different point in their workflow. The claim is that it's not OK for this to break: cd foo && git init git push ;# ok ... time passes, git upgrade ... git push ;# broken but it somehow _is_ OK for this to break: cd foo && git init git push ;# ok ... time passes, git upgrade ... cd bar && git init git push ;# broken In both cases, you have a sequence of commands that does one thing with one git version, and something else with another git version. The only difference is whether your sequence includes git init. So while you don't break people with existing repositories, you are still breaking anybody who creates a new one and gets confused when there is new behavior (or even has scripts which involve repository creation). So in my opinion either the breakage is serious enough not to allow the change, or minor enough (compared to the benefit) to allow it. But changing default config in git init is: - a half-way solution that leaves some workflows broken and some not - possibly even _worse_, since now we have sacrificed consistency. So now users wonder why some of their repos show breakage and some don't. Or why a particular behavior goes away when they try to write a test case that involves creating a new test repo. And note that it doesn't matter whether you think the right path is to make the change or not: I am only arguing here against this sort of half-way technique. > -- >8 -- > Subject: [PATCH] receive-pack: explain what to do when push updates the current branch > > This makes "git push" issue a more detailed instruction when a user pushes > into the current branch of a non-bare repository without having an > explicit configuration set to receive.denycurrentbranch. In such a case, > it will also tell the user that the default will change to refusal in a > future version of git. I think this is a definite improvement over the current behavior. As I said before, I am not sure what is the right path (though I think I am leaning towards leaving the warning longer based on the recent discussion), but if we are to leave the default to warn and not refuse, I think this should definitely be applied. A few comments on the specific message: > } > > +static char *warn_unconfigured_deny_msg[] = { > + "Updating the currently checked out branch may cause confusion,", > + "as the index and work tree do not reflect changes that are in HEAD." > + "As a result, you may see the changes you just pushed into it", Missing comma between lines 2 and 3, which results in an overly long line in the output. > + "You can set 'receive.denyCurrentBranch' configuration variable to", > + "'refuse' in the repository to forbid pushing into the current branch", > + "of it." Maybe this should specifically say "remote repository". If you understand how the feature works, it is obvious that you must do it that way, but for less advanced users it is not even clear that this text is being generated by the remote end. > + "To allow pushing into the current branch, you can set it to 'ignore';", > + "but this is not recommended unless you really know what you are doing." I thought somebody (you?) argued against the phrase "unless you really know what you are doing". And it is better here in context explaining the general issue. But as a user, now I have to ask: do I know what I am doing, and if not, how do I find out? The two obvious solutions for people who "know what they are doing" are running "git reset --hard", and installing a hook that does something sensible. I don't know if it is worth mentioning them here (the former is mentioned earlier in the message, but that doesn't necessarily mean the user understands all the implications). Since there are so many subtleties to explain, maybe it make sense to simply put in a pointer to an expanded discussion in the "git push" manpage? -Peff ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] Switch receive.denyCurrentBranch to "refuse" 2009-02-02 12:41 ` Jeff King @ 2009-02-03 4:30 ` Junio C Hamano 2009-02-03 17:45 ` Junio C Hamano 2009-02-03 8:01 ` Junio C Hamano 1 sibling, 1 reply; 43+ messages in thread From: Junio C Hamano @ 2009-02-03 4:30 UTC (permalink / raw) To: Jeff King; +Cc: Nanako Shiraishi, Johannes Schindelin, Jay Soffian, git Jeff King <peff@peff.net> writes: > In both cases, you have a sequence of commands that does one thing with > one git version, and something else with another git version. The only > difference is whether your sequence includes git init. I vaguely remember arguing against different behaviour between a new repository and an existing one in the past on a different topic myself. I am not married to the idea of effectively flipping the default to "refuse" in a new repository early, and do not mind dropping the "git init" change at all. I do not like the inconsistency myself. The only reason why I did that "git init" patch was because I just thought that it might be a good way to help new people sooner, who will start using git after 1.6.2 gets released but before 1.7.0 flips the default for everybody, while explaining people older than 1.6.2 what is happening in the warning/error message during the transition period. I suspect it could be argued that with an extra line that says "the default will change to 'refuse' in 1.7.0 for all repositories, but we are making the change early for newly created repositories to help new people", the main idea of the patch may be salvageable, but I do not deeply care either way. By the way, I just realized one thing. When we flip the default to "refuse" in 1.7.0 for everybody, we will need the explanation and instruction on how to get a non-default behaviour and how to squelch the message when we "refuse by defaut", just like my first patch did when we "warn by default". It is entirely possible some people simply skip 1.6.2 and directly jump to 1.7.0, and while we cannot help them avoid the surprise caused by the change in behaviour, we cannot be silent in such a situation. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] Switch receive.denyCurrentBranch to "refuse" 2009-02-03 4:30 ` Junio C Hamano @ 2009-02-03 17:45 ` Junio C Hamano 2009-02-06 14:06 ` Jeff King 0 siblings, 1 reply; 43+ messages in thread From: Junio C Hamano @ 2009-02-03 17:45 UTC (permalink / raw) To: Jeff King; +Cc: Nanako Shiraishi, Johannes Schindelin, Jay Soffian, git Junio C Hamano <gitster@pobox.com> writes: > By the way, I just realized one thing. > > When we flip the default to "refuse" in 1.7.0 for everybody, we will need > the explanation and instruction on how to get a non-default behaviour and > how to squelch the message when we "refuse by defaut", just like my first > patch did when we "warn by default". It is entirely possible some people > simply skip 1.6.2 and directly jump to 1.7.0, and while we cannot help > them avoid the surprise caused by the change in behaviour, we cannot be > silent in such a situation. And this is meant for 1.7.0, and is queued at the tip of 'pu' just for the heck of it. It will flip the default to "refuse", but explains why the operation that used to succeed suddenly started failing, how to get the older behaviour back (but with caveats), and how to squelch this message. Adjustments to the tests were resurrected from the previous "init-db" patch. Since this is meant for 1.7.0 that does flip the default for everybody, there is no need to touch init-db anymore. -- >8 -- [PATCH] Refuse updating the current branch in a non-bare repository via push This makes git-push to refuse pushing-push into a non-bare repository to update its current branch by default. To help people who are used to be able to do this (and later "reset --hard" it in some other way), a big error message is issued when this refusal is triggered. Hosting sites that do not give the users direct access to customize their repositories (e.g. repo.or.cz, gitorious, github etc.) may further want to explicitly set the configuration variable to "refuse" for their customers' repositories. Signed-off-by: Junio C Hamano <gitster@pobox.com> --- builtin-receive-pack.c | 40 +++++++++++++++++----------------------- t/t5400-send-pack.sh | 2 ++ t/t5401-update-hooks.sh | 1 + t/t5405-send-pack-rewind.sh | 1 + t/t5516-fetch-push.sh | 1 + t/t5517-push-mirror.sh | 3 ++- t/t5521-pull-symlink.sh | 20 +++++++++++++------- t/t5701-clone-local.sh | 4 +++- 8 files changed, 40 insertions(+), 32 deletions(-) diff --git a/builtin-receive-pack.c b/builtin-receive-pack.c index 6f61c45..17ab4f5 100644 --- a/builtin-receive-pack.c +++ b/builtin-receive-pack.c @@ -215,33 +215,27 @@ static int is_ref_checked_out(const char *ref) return !strcmp(head, ref); } -static char *warn_unconfigured_deny_msg[] = { - "Updating the currently checked out branch may cause confusion,", - "as the index and work tree do not reflect changes that are in HEAD.", - "As a result, you may see the changes you just pushed into it", - "reverted when you run 'git diff' over there, and you may want", - "to run 'git reset --hard' before starting to work to recover.", +static char *refuse_unconfigured_deny_msg[] = { + "By default, updating the current branch in a non-bare repository", + "is denied, because it will make the index and work tree inconsistent", + "with what you pushed, and will require 'git reset --hard' to match", + "the work tree to HEAD.", "", "You can set 'receive.denyCurrentBranch' configuration variable to", - "'refuse' in the remote repository to forbid pushing into its", - "current branch." + "'ignore' or 'warn' in the remote repository to allow pushing into", + "its current branch; however, this is not recommended unless you", + "arranged to update its work tree to match what you pushed in some", + "other way.", "", - "To allow pushing into the current branch, you can set it to 'ignore';", - "but this is not recommended unless you arranged to update its work", - "tree to match what you pushed in some other way.", - "", - "To squelch this message, you can set it to 'warn'.", - "", - "Note that the default will change in a future version of git", - "to refuse updating the current branch unless you have the", - "configuration variable set to either 'ignore' or 'warn'." + "To squelch this message, you can set the configuration variable to", + "'refuse'." }; -static void warn_unconfigured_deny(void) +static void refuse_unconfigured_deny(void) { int i; - for (i = 0; i < ARRAY_SIZE(warn_unconfigured_deny_msg); i++) - warning(warn_unconfigured_deny_msg[i]); + for (i = 0; i < ARRAY_SIZE(refuse_unconfigured_deny_msg); i++) + error(refuse_unconfigured_deny_msg[i]); } static const char *update(struct command *cmd) @@ -261,14 +255,14 @@ static const char *update(struct command *cmd) switch (deny_current_branch) { case DENY_IGNORE: break; - case DENY_UNCONFIGURED: case DENY_WARN: warning("updating the current branch"); - if (deny_current_branch == DENY_UNCONFIGURED) - warn_unconfigured_deny(); break; case DENY_REFUSE: + case DENY_UNCONFIGURED: error("refusing to update checked out branch: %s", name); + if (deny_current_branch == DENY_UNCONFIGURED) + refuse_unconfigured_deny(); return "branch is currently checked out"; } } diff --git a/t/t5400-send-pack.sh b/t/t5400-send-pack.sh index b21317d..5c9c277 100755 --- a/t/t5400-send-pack.sh +++ b/t/t5400-send-pack.sh @@ -33,6 +33,7 @@ test_expect_success setup ' git update-ref HEAD "$commit" && git clone ./. victim && cd victim && + git config receive.denyCurrentBranch warn && git log && cd .. && git update-ref HEAD "$zero" && @@ -138,6 +139,7 @@ rewound_push_setup() { rm -rf parent child && mkdir parent && cd parent && git init && echo one >file && git add file && git commit -m one && + git config receive.denyCurrentBranch warn && echo two >file && git commit -a -m two && cd .. && git clone parent child && cd child && git reset --hard HEAD^ diff --git a/t/t5401-update-hooks.sh b/t/t5401-update-hooks.sh index 64f66c9..325714e 100755 --- a/t/t5401-update-hooks.sh +++ b/t/t5401-update-hooks.sh @@ -18,6 +18,7 @@ test_expect_success setup ' git update-ref refs/heads/master $commit0 && git update-ref refs/heads/tofail $commit1 && git clone ./. victim && + GIT_DIR=victim/.git git config receive.denyCurrentBranch warn && GIT_DIR=victim/.git git update-ref refs/heads/tofail $commit1 && git update-ref refs/heads/master $commit1 && git update-ref refs/heads/tofail $commit0 diff --git a/t/t5405-send-pack-rewind.sh b/t/t5405-send-pack-rewind.sh index cb9aacc..4bda18a 100755 --- a/t/t5405-send-pack-rewind.sh +++ b/t/t5405-send-pack-rewind.sh @@ -8,6 +8,7 @@ test_expect_success setup ' >file1 && git add file1 && test_tick && git commit -m Initial && + git config receive.denyCurrentBranch warn && mkdir another && ( cd another && diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh index 89649e7..a67ebd0 100755 --- a/t/t5516-fetch-push.sh +++ b/t/t5516-fetch-push.sh @@ -12,6 +12,7 @@ mk_empty () { ( cd testrepo && git init && + git config receive.denyCurrentBranch warn && mv .git/hooks .git/hooks-disabled ) } diff --git a/t/t5517-push-mirror.sh b/t/t5517-push-mirror.sh index ea49ded..e2ad260 100755 --- a/t/t5517-push-mirror.sh +++ b/t/t5517-push-mirror.sh @@ -19,7 +19,8 @@ mk_repo_pair () { mkdir mirror && ( cd mirror && - git init + git init && + git config receive.denyCurrentBranch warn ) && mkdir master && ( diff --git a/t/t5521-pull-symlink.sh b/t/t5521-pull-symlink.sh index 5672b51..66b5ac1 100755 --- a/t/t5521-pull-symlink.sh +++ b/t/t5521-pull-symlink.sh @@ -14,13 +14,19 @@ test_description='pulling from symlinked subdir' # # The working directory is subdir-link. -mkdir subdir -echo file >subdir/file -git add subdir/file -git commit -q -m file -git clone -q . clone-repo -ln -s clone-repo/subdir/ subdir-link - +test_expect_success setup ' + mkdir subdir && + echo file >subdir/file && + git add subdir/file && + git commit -q -m file && + git clone -q . clone-repo && + ln -s clone-repo/subdir/ subdir-link && + ( + cd clone-repo && + git config receive.denyCurrentBranch warn + ) && + git config receive.denyCurrentBranch warn +' # Demonstrate that things work if we just avoid the symlink # diff --git a/t/t5701-clone-local.sh b/t/t5701-clone-local.sh index 3559d17..10accc2 100755 --- a/t/t5701-clone-local.sh +++ b/t/t5701-clone-local.sh @@ -119,7 +119,9 @@ test_expect_success 'bundle clone with nonexistent HEAD' ' test_expect_success 'clone empty repository' ' cd "$D" && mkdir empty && - (cd empty && git init) && + (cd empty && + git init && + git config receive.denyCurrentBranch warn) && git clone empty empty-clone && test_tick && (cd empty-clone -- 1.6.1.2.346.g115a3 ^ permalink raw reply related [flat|nested] 43+ messages in thread
* Re: [PATCH] Switch receive.denyCurrentBranch to "refuse" 2009-02-03 17:45 ` Junio C Hamano @ 2009-02-06 14:06 ` Jeff King 2009-02-07 7:51 ` Junio C Hamano 0 siblings, 1 reply; 43+ messages in thread From: Jeff King @ 2009-02-06 14:06 UTC (permalink / raw) To: Junio C Hamano; +Cc: Nanako Shiraishi, Johannes Schindelin, Jay Soffian, git On Tue, Feb 03, 2009 at 09:45:54AM -0800, Junio C Hamano wrote: > And this is meant for 1.7.0, and is queued at the tip of 'pu' just for the > heck of it. Looks sane to me for 1.7.0, but it will probably require tweaking of which tests are fixed at that time (and actually, I think some can just be cleaned up to use bare repositories instead of adding the config -- but let's deal with that when the patch is ready to be applied). > This makes git-push to refuse pushing-push into a non-bare repository to As opposed to non-pushing push? -Peff ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] Switch receive.denyCurrentBranch to "refuse" 2009-02-06 14:06 ` Jeff King @ 2009-02-07 7:51 ` Junio C Hamano 0 siblings, 0 replies; 43+ messages in thread From: Junio C Hamano @ 2009-02-07 7:51 UTC (permalink / raw) To: Jeff King; +Cc: Nanako Shiraishi, Johannes Schindelin, Jay Soffian, git Jeff King <peff@peff.net> writes: >> This makes git-push to refuse pushing-push into a non-bare repository to > > As opposed to non-pushing push? Editor/finger slippage. Thanks for catching it. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] Switch receive.denyCurrentBranch to "refuse" 2009-02-02 12:41 ` Jeff King 2009-02-03 4:30 ` Junio C Hamano @ 2009-02-03 8:01 ` Junio C Hamano 2009-02-03 8:07 ` Jeff King 1 sibling, 1 reply; 43+ messages in thread From: Junio C Hamano @ 2009-02-03 8:01 UTC (permalink / raw) To: Jeff King; +Cc: Nanako Shiraishi, Johannes Schindelin, Jay Soffian, git Jeff King <peff@peff.net> writes: > I think this is a definite improvement over the current behavior. As I > said before, I am not sure what is the right path (though I think I am > leaning towards leaving the warning longer based on the recent > discussion), but if we are to leave the default to warn and not refuse, > I think this should definitely be applied. > > A few comments on the specific message: Thanks. The commit was only in 'pu', so I'll be amending it instead of applying an incremental, but here is the interdiff to incorporate your comments. builtin-receive-pack.c | 9 +++++---- 1 files changed, 5 insertions(+), 4 deletions(-) diff --git c/builtin-receive-pack.c w/builtin-receive-pack.c index f2c94fc..09c07d9 100644 --- c/builtin-receive-pack.c +++ w/builtin-receive-pack.c @@ -217,17 +217,18 @@ static int is_ref_checked_out(const char *ref) static char *warn_unconfigured_deny_msg[] = { "Updating the currently checked out branch may cause confusion,", - "as the index and work tree do not reflect changes that are in HEAD." + "as the index and work tree do not reflect changes that are in HEAD.", "As a result, you may see the changes you just pushed into it", "reverted when you run 'git diff' over there, and you may want", "to run 'git reset --hard' before starting to work to recover.", "", "You can set 'receive.denyCurrentBranch' configuration variable to", - "'refuse' in the repository to forbid pushing into the current branch", - "of it." + "'refuse' in the remote repository to forbid pushing into the", + "current branch of it." "", "To allow pushing into the current branch, you can set it to 'ignore';", - "but this is not recommended unless you really know what you are doing.", + "but this is not recommended unless you arranged its work tree to get", + "updated to match what you pushed in some other way.", "", "To squelch this message, you can set it to 'warn'.", "", ^ permalink raw reply related [flat|nested] 43+ messages in thread
* Re: [PATCH] Switch receive.denyCurrentBranch to "refuse" 2009-02-03 8:01 ` Junio C Hamano @ 2009-02-03 8:07 ` Jeff King 2009-02-03 9:22 ` Junio C Hamano 0 siblings, 1 reply; 43+ messages in thread From: Jeff King @ 2009-02-03 8:07 UTC (permalink / raw) To: Junio C Hamano; +Cc: Nanako Shiraishi, Johannes Schindelin, Jay Soffian, git On Tue, Feb 03, 2009 at 12:01:43AM -0800, Junio C Hamano wrote: > "To allow pushing into the current branch, you can set it to 'ignore';", > - "but this is not recommended unless you really know what you are doing.", > + "but this is not recommended unless you arranged its work tree to get", > + "updated to match what you pushed in some other way.", This is much better, but I believe it needs to be "...arranged _for_ its work tree to get updated..." to be grammatically correct. And as a nit (which I seem to be full of tonight), you can get rid of the passive voice by saying: but this is not recommended unless you arranged to update its work tree to match what you pushed in some other way. which is slightly more clear, IMHO. -Peff ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] Switch receive.denyCurrentBranch to "refuse" 2009-02-03 8:07 ` Jeff King @ 2009-02-03 9:22 ` Junio C Hamano 0 siblings, 0 replies; 43+ messages in thread From: Junio C Hamano @ 2009-02-03 9:22 UTC (permalink / raw) To: Jeff King; +Cc: Nanako Shiraishi, Johannes Schindelin, Jay Soffian, git Jeff King <peff@peff.net> writes: > On Tue, Feb 03, 2009 at 12:01:43AM -0800, Junio C Hamano wrote: > >> "To allow pushing into the current branch, you can set it to 'ignore';", >> - "but this is not recommended unless you really know what you are doing.", >> + "but this is not recommended unless you arranged its work tree to get", >> + "updated to match what you pushed in some other way.", > > This is much better, but I believe it needs to be "...arranged _for_ > its work tree to get updated..." to be grammatically correct. > > And as a nit (which I seem to be full of tonight), you can get rid of > the passive voice by saying: > > but this is not recommended unless you arranged to update its work > tree to match what you pushed in some other way. > > which is slightly more clear, IMHO. Much more clear. I overuse the passive voice, I know it is a bad habit I somehow cannot shake off. Thanks. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] Switch receive.denyCurrentBranch to "refuse" 2009-01-31 0:56 ` Nanako Shiraishi 2009-02-01 1:27 ` Junio C Hamano @ 2009-02-01 2:06 ` Junio C Hamano 2009-02-01 3:37 ` Sam Vilain 2009-02-01 22:59 ` Johannes Schindelin 2 siblings, 1 reply; 43+ messages in thread From: Junio C Hamano @ 2009-02-01 2:06 UTC (permalink / raw) To: Nanako Shiraishi; +Cc: Johannes Schindelin, Jay Soffian, git Nanako Shiraishi <nanako3@lavabit.com> writes: > I assume that everybody, including the maintainer who is too heavyweight > and has too much inertia to accept too sudden a change of the course, > wants to eventually make the default to deny pushing to the current > branch. But I think such a change should come at 1.7.0 release at the > earliest, and a constructive thing to do is to put in a patch to 1.6.2 > that helps the users with the eventual transition. I am not opposed to eventually change the default to refuse at some point, but I have to say that now would not be the best time to do so. Jeff's 986e823 (receive-pack: detect push to current branch of non-bare repo, 2008-11-08) that is v1.6.1-rc1~59^2 was the one we started warning about this, and we only had one major release since then, and I'd love to see a solid rc or even the final release by mid February. By the way, I do not appreciate other people who I have never met speculate about my body mass very much. I am on the skinner end of the spectrum, if you need to know. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] Switch receive.denyCurrentBranch to "refuse" 2009-02-01 2:06 ` Junio C Hamano @ 2009-02-01 3:37 ` Sam Vilain 2009-02-01 21:33 ` Junio C Hamano 0 siblings, 1 reply; 43+ messages in thread From: Sam Vilain @ 2009-02-01 3:37 UTC (permalink / raw) To: Junio C Hamano; +Cc: Nanako Shiraishi, Johannes Schindelin, Jay Soffian, git On Sat, 2009-01-31 at 18:06 -0800, Junio C Hamano wrote: > Nanako Shiraishi <nanako3@lavabit.com> writes: > > > I assume that everybody, including the maintainer who is too heavyweight > > and has too much inertia to accept too sudden a change of the course, > > wants to eventually make the default to deny pushing to the current > > branch. But I think such a change should come at 1.7.0 release at the > > earliest, and a constructive thing to do is to put in a patch to 1.6.2 > > that helps the users with the eventual transition. > > I am not opposed to eventually change the default to refuse at some point, > but I have to say that now would not be the best time to do so. Jeff's > 986e823 (receive-pack: detect push to current branch of non-bare repo, > 2008-11-08) that is v1.6.1-rc1~59^2 was the one we started warning about > this, and we only had one major release since then, and I'd love to see a > solid rc or even the final release by mid February. Personally I think it's worth fast tracking, because I think very few people are actually using push to a checked out branch whereas many people are confused by the behaviour. I just can't understand the resistance to this safety feature. People who encounter the bug can just change the setting and move on... it seems like an argument based on "principles", usually a sign that one has run out of actual arguments.. > By the way, I do not appreciate other people who I have never met > speculate about my body mass very much. I am on the skinner end of the > spectrum, if you need to know. lol. It was a metaphorical use of the term from my reading ;-) Sam. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] Switch receive.denyCurrentBranch to "refuse" 2009-02-01 3:37 ` Sam Vilain @ 2009-02-01 21:33 ` Junio C Hamano 2009-02-02 7:00 ` Sam Vilain 0 siblings, 1 reply; 43+ messages in thread From: Junio C Hamano @ 2009-02-01 21:33 UTC (permalink / raw) To: Sam Vilain; +Cc: Nanako Shiraishi, Johannes Schindelin, Jay Soffian, git Sam Vilain <sam@vilain.net> writes: > I just can't understand the > resistance to this safety feature. People who encounter the bug can > just change the setting and move on... it seems like an argument based > on "principles", usually a sign that one has run out of actual > arguments.. There is no resitance to any safety feature. The resistance is to something entirely different. The change we all share as the desired end result is to introduce a different behaviour, even if it is a better one, that will deliberately break people's working setup. The end result being better does not justify breaking people's setup. You need to help people whose setups will be broken prepare for such a change. Perhaps you already forgot the fiasco after 1.6.0, which moved tons of git-foo scripts out of the users' way. It resulted in a better layout in the end, but we knew it would break people's working setup from the beginning. It was a change that many people argued for, saying that too many commands in the path scared new people, that we thought we planned very carefully, and that we thought we gave ample warning to existing users. Yet it resulted in a huge fallout. You probably forgot about it already, but that is because you weren't the one who had to take the flak. I was, and I haven't forgotten. The resistance is to an irresponsible transition strategy that causes pain unnecessarily. We need to improve the situation incrementally, helping new people a bit in one step while not hurting old people along the way, aiming to help everybody more in the end. One of the concluding comments after the 1.6.0 fiasco was that the old-timers _heard about_ the upcoming change, but were too busy to stop and think to realize that it is any urgent that they need to prepare for it, and we should have warned them more actively. In the end, they didn't mind the change itself per-se because we had an escape hatch (i.e. to prepend the output from "git --exec-path" to the PATH in your script), but the primary pain was having to adjust their setup on _our_ timetable, not theirs. Even k.org, which is one of the early adopters of new releases among the larger sites (with larger proportion of old timers), has started using the version with the "updating the branch you have checked out" warning (which happened in v1.6.1) fairly recently, and during the discussion we noticed that the warning didn't say we will be switching the default to "refuse" any time soon. We haven't yet given them enough advance warning telling them they will have to go running around flipping the bit in their repositories. Dismissing the issue by saying "old-timers can simply flip the configuration once" makes an irresponsible argument for repeating the same mistake of 1.6.0. That is what I am resisting to. I think the plan outlined in this thread would ease the transition in much better way, and the patch I sent yesterday uses a deliberately loooooooong warning message whose primary purpose is to be annoyingly obvious that the users need to adjust their configuration now, so that the eventual change in the default we will make won't inconvenience them. I was reluctant to change the default for new repositories to refuse during 1.6.2 timeframe, but I think with the attached patch on top of the second patch I sent out earlier, it would force people choose before they do any real damange to their repositories, and having it early would make the overall transition plan smoother. builtin-init-db.c | 2 +- builtin-receive-pack.c | 26 ++++++++++++++++++++++++++ 2 files changed, 27 insertions(+), 1 deletions(-) diff --git c/builtin-init-db.c w/builtin-init-db.c index 26c10cc..ea2765c 100644 --- c/builtin-init-db.c +++ w/builtin-init-db.c @@ -251,7 +251,7 @@ static int create_default_files(const char *template_path) git_config_set("core.worktree", work_tree); } if (!reinit) - git_config_set("receive.denyCurrentBranch", "refuse"); + git_config_set("receive.denyCurrentBranch", "refuse-with-insn"); } if (!reinit) { diff --git c/builtin-receive-pack.c w/builtin-receive-pack.c index f2c94fc..82d372f 100644 --- c/builtin-receive-pack.c +++ w/builtin-receive-pack.c @@ -16,6 +16,7 @@ enum deny_action { DENY_IGNORE, DENY_WARN, DENY_REFUSE, + DENY_REFUSE_WITH_INSN, }; static int deny_deletes = 0; @@ -39,6 +40,8 @@ static enum deny_action parse_deny_action(const char *var, const char *value) return DENY_WARN; if (!strcasecmp(value, "refuse")) return DENY_REFUSE; + if (!strcasecmp(value, "refuse-with-insn")) + return DENY_REFUSE_WITH_INSN; } if (git_config_bool(var, value)) return DENY_REFUSE; @@ -236,6 +239,20 @@ static char *warn_unconfigured_deny_msg[] = { "configuration variable set to either 'ignore' or 'warn'." }; +static char *refuse_current_insn_msg[] = { + "By default, updating the current branch in a non-bare repository", + "is denied, because it will make the index and work tree inconsistent", + "with what you pushed, and will require 'git reset --hard' to match", + "the work tree to HEAD.", + "", + "You can set 'receive.denyCurrentBranch' configuration variable to", + "'ignore' or 'warn' in the repository to allow pushing into the", + "current branch of it; this is not recommended unless you really know", + "what you are doing.", + "", + "To squelch this message, you can set it to 'refuse'.", +}; + static void warn_unconfigured_deny(void) { int i; @@ -243,6 +260,12 @@ static void warn_unconfigured_deny(void) warning(warn_unconfigured_deny_msg[i]); } +static void refuse_current_insn(void) +{ + int i; + for (i = 0; i < ARRAY_SIZE(refuse_current_insn_msg); i++) + error(refuse_current_insn_msg[i]); +} static const char *update(struct command *cmd) { @@ -268,7 +291,10 @@ static const char *update(struct command *cmd) warn_unconfigured_deny(); break; case DENY_REFUSE: + case DENY_REFUSE_WITH_INSN: error("refusing to update checked out branch: %s", name); + if (deny_current_branch == DENY_REFUSE_WITH_INSN) + refuse_current_insn(); return "branch is currently checked out"; } } ^ permalink raw reply related [flat|nested] 43+ messages in thread
* Re: [PATCH] Switch receive.denyCurrentBranch to "refuse" 2009-02-01 21:33 ` Junio C Hamano @ 2009-02-02 7:00 ` Sam Vilain 2009-02-02 8:32 ` Junio C Hamano 0 siblings, 1 reply; 43+ messages in thread From: Sam Vilain @ 2009-02-02 7:00 UTC (permalink / raw) To: Junio C Hamano; +Cc: Nanako Shiraishi, Johannes Schindelin, Jay Soffian, git On Sun, 2009-02-01 at 13:33 -0800, Junio C Hamano wrote: > > I just can't understand the > > resistance to this safety feature. People who encounter the bug can > > just change the setting and move on... it seems like an argument based > > on "principles", usually a sign that one has run out of actual > > arguments.. > > There is no resitance to any safety feature. The resistance is to > something entirely different. [...] > Perhaps you already forgot the fiasco after 1.6.0, which moved tons of > git-foo scripts out of the users' way. It resulted in a better layout in > the end, but we knew it would break people's working setup from the > beginning. [...] Yeah sure but the changes are a bit different aren't they. One affected all users who used the previously documented way to access subcommands (and the names that the man pages all still retain). The other affects a small number of users who are doing something which is labeled in many places as a bad thing to want to do. That being said, I think I like the copy and design of the patch you just posted. If the path of caution is to be followed for this, then the way you propose seems a good way to do it. Sam ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] Switch receive.denyCurrentBranch to "refuse" 2009-02-02 7:00 ` Sam Vilain @ 2009-02-02 8:32 ` Junio C Hamano 2009-02-02 10:50 ` Sam Vilain 0 siblings, 1 reply; 43+ messages in thread From: Junio C Hamano @ 2009-02-02 8:32 UTC (permalink / raw) To: Sam Vilain; +Cc: Nanako Shiraishi, Johannes Schindelin, Jay Soffian, git Sam Vilain <sam@vilain.net> writes: > The other affects > a small number of users who are doing something which is labeled in many > places as a bad thing to want to do. Sorry, but I do not agree with this. What is bad is to push into a repository that is used for editing. That is labelled as a bad thing to want to do. It is often the easiest to push and then run "reset --hard" (perhaps from the post-update script) to propagate your change to a repository that is not usually used for editing. E.g. that has always been the way I update my private repository at k.org that I use for final testing before pushing out the results that I built and tested on my personal machine. People who have live web pages served from a checkout do that, too. It is not a bad thing to do at all, and you can find many instructions with google without spending a lot of time to do exactly that. http://kerneltrap.org/mailarchive/git/2008/7/1/2315924 http://utsl.gen.nz/git/post-update http://groups.google.com/group/sl-ugr/browse_thread/thread/04e4c4bd6ce174af ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] Switch receive.denyCurrentBranch to "refuse" 2009-02-02 8:32 ` Junio C Hamano @ 2009-02-02 10:50 ` Sam Vilain 0 siblings, 0 replies; 43+ messages in thread From: Sam Vilain @ 2009-02-02 10:50 UTC (permalink / raw) To: Junio C Hamano; +Cc: Nanako Shiraishi, Johannes Schindelin, Jay Soffian, git On Mon, 2009-02-02 at 00:32 -0800, Junio C Hamano wrote: > > The other affects > > a small number of users who are doing something which is labeled in many > > places as a bad thing to want to do. > > Sorry, but I do not agree with this. > > What is bad is to push into a repository that is used for editing. That > is labelled as a bad thing to want to do. > > It is often the easiest to push and then run "reset --hard" (perhaps from > the post-update script) to propagate your change to a repository that is > not usually used for editing. E.g. that has always been the way I update > my private repository at k.org that I use for final testing before pushing > out the results that I built and tested on my personal machine. People > who have live web pages served from a checkout do that, too. It is not a > bad thing to do at all, and you can find many instructions with google > without spending a lot of time to do exactly that. > > http://kerneltrap.org/mailarchive/git/2008/7/1/2315924 > http://utsl.gen.nz/git/post-update Heh, thanks for referring me to my own script ;-) I think a "repository that is used for editing" can be practically defined as one which does not have any dirty local files. Or, if there are dirty local files then they are none of the files which would be changed by the push, or none of them would be changed by the push. Similar to the check that 'git merge' does. With that definition, if receive.denyCurrentBranch is set to "update" it could be pretty much automagic, perhaps even good enough behaviour to consider making it the default. This kind of behaviour is what my post-update hook tries to achieve, but it really needs a corresponding piece in the update hook, and I didn't code all of the conditions above into it. Sam. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] Switch receive.denyCurrentBranch to "refuse" 2009-01-31 0:56 ` Nanako Shiraishi 2009-02-01 1:27 ` Junio C Hamano 2009-02-01 2:06 ` Junio C Hamano @ 2009-02-01 22:59 ` Johannes Schindelin 2009-02-01 23:56 ` Junio C Hamano 2 siblings, 1 reply; 43+ messages in thread From: Johannes Schindelin @ 2009-02-01 22:59 UTC (permalink / raw) To: Nanako Shiraishi; +Cc: Jay Soffian, git, gitster Hi, On Sat, 31 Jan 2009, Nanako Shiraishi wrote: > Quoting Johannes Schindelin <Johannes.Schindelin@gmx.de>: > > > You cannot just cater for one workflow and fsck the other workflows > > over. > > > > You'll have to devise a method that helps the workflow you are > > interested in, but leaves the others alone. > > I think you'd want to repeat that to yourself when you propose to switch > the default for denyCurrentcurrentBranch config to "true" too hastily > the next time? Nanako, what exactly do you think I did before writing these lines: Granted, we wanted to have a longer grace period for old-timers, but let's face it: [... a discussion on the pros and cons ...] ? Do you think I did that just on a whim, or do you rather assume that I thought long and hard about it? > I don't think your patch matches the tradition of how defaults are > changed in git project. You don't introduce a large change just after > the maintainer hints about going into a freeze for 1.X.Y release when Y > isn't zero. Indeed. That is why I wrote "Granted, we wanted to have a longer grace period"! > I assume that everybody, including the maintainer who is too heavyweight I saw Junio. He is in no way heavyweight. He is actually rather skinny. > and has too much inertia to accept too sudden a change of the course, > wants to eventually make the default to deny pushing to the current > branch. But I think such a change should come at 1.7.0 release at the > earliest, and a constructive thing to do is to put in a patch to 1.6.2 > that helps the users with the eventual transition. So what do you want to achieve? Annoy me? Annoy Git newbies? Annoy Git oldtimers? Eventually, it will boil down to - who - when to annoy. And I have a strong suspicion that it does not help the reputation of Git at all, if we annoy - new Git users - for a long time Rather, I'd like to annoy only - a few oldtimers who should know better by now - just once, when they upgrade to a new minor release and see that they forgot to mark their repository as "bare". If you would think about it as long and hard as I did, you would see that we have to annoy - a few oldtimers - at some stage anyway, but in the meantime, we could avoid to annoy - a lot of new Git users - for a long time at the cost of annoying - a few oldtimers - now, instead of later which cost will come to - us - anyway Frankly, I am surprised that people do not agree with me on this point. > What do people think? Seriously, when it comes to the Git users I interact with, they think "what the bl**dy fsck did the Git people smoke when they made it _so_ hard on new Git users, I am certainly not the only person bitten by this." I know, because they let me in on their thoughts, but are too shy to mention them here on the Git list. And as everybody knows, I am a nice guy, and I listen. Ciao, Dscho ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] Switch receive.denyCurrentBranch to "refuse" 2009-02-01 22:59 ` Johannes Schindelin @ 2009-02-01 23:56 ` Junio C Hamano 0 siblings, 0 replies; 43+ messages in thread From: Junio C Hamano @ 2009-02-01 23:56 UTC (permalink / raw) To: Johannes Schindelin; +Cc: Nanako Shiraishi, Jay Soffian, git, gitster Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > at the cost of annoying > > - a few oldtimers > - now, instead of later Nobody seems to have realized this, but suddenly changing the default to refuse without giving people enough advance warning to adjust will hurt not just the old-timers (a rough definition is people who are from the kernel circle and have been using git since summer of 2005), but people who picked up a recipe from various how-to web pages to push to a live repository and updating the checkout that is otherwise never touched by the humans with its post-update hook running "reset --hard". Old timers may be savvy enough to know what has changed and may be able to grudgingly react, but what is your plans for these recipe following kids? How many times do I have to repeat that it is much worse to break a working setup of people without advance warning and sound transition guidance than having a known breakage that users can be trained to avoid? And realize that I am not saying we need to keep the known breakage forever. The only thing I am saying is that you need to have a smooth transition plan for changing the default, and a mechanism to guide people in place. I'll ignore you if you keep repeating "all it takes is for old timers to flip a switch". Such an argument shows that you didn't learn a thing after the 1.6.0 fallout. ^ permalink raw reply [flat|nested] 43+ messages in thread
end of thread, other threads:[~2010-04-13 17:58 UTC | newest] Thread overview: 43+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <cover.1233275583u.git.johannes.schindelin@gmx.de> 2009-01-30 0:34 ` [PATCH] Switch receive.denyCurrentBranch to "refuse" Johannes Schindelin 2009-01-30 1:28 ` Jay Soffian 2009-01-30 1:32 ` Asheesh Laroia 2010-04-13 16:42 ` [PATCH] Switch receive.denyCurrentBranch to "refuse" Dave Abrahams 2010-04-13 17:57 ` [PATCH] Switch receive.denyCurrentBranch to "refuse" Junio C Hamano [not found] ` <7v4ozhd1wp.fsf@gitster.siamese.dyndns.org> 2009-01-30 2:18 ` Junio C Hamano 2009-01-30 13:24 ` Johannes Schindelin 2009-01-30 16:33 ` Jeff King 2009-01-30 16:55 ` Johannes Schindelin 2009-01-30 2:30 ` Miklos Vajna 2009-01-30 13:28 ` Johannes Schindelin 2009-02-11 0:11 ` Miklos Vajna 2009-02-11 1:04 ` Junio C Hamano 2009-01-30 2:55 ` Jeff King 2009-01-30 14:11 ` Johannes Schindelin 2009-01-30 7:17 ` Johannes Sixt 2009-01-30 7:34 ` Jeff King 2009-01-30 13:23 ` Johannes Schindelin 2009-01-30 14:35 ` Jeff King 2009-01-30 16:17 ` Jay Soffian 2009-01-30 16:28 ` Jeff King 2009-01-30 17:01 ` Johannes Schindelin 2009-01-30 18:50 ` Jay Soffian 2009-01-30 19:03 ` Johannes Schindelin 2009-01-31 0:56 ` Nanako Shiraishi 2009-02-01 1:27 ` Junio C Hamano 2009-02-01 1:39 ` Junio C Hamano 2009-02-02 12:41 ` Jeff King 2009-02-03 4:30 ` Junio C Hamano 2009-02-03 17:45 ` Junio C Hamano 2009-02-06 14:06 ` Jeff King 2009-02-07 7:51 ` Junio C Hamano 2009-02-03 8:01 ` Junio C Hamano 2009-02-03 8:07 ` Jeff King 2009-02-03 9:22 ` Junio C Hamano 2009-02-01 2:06 ` Junio C Hamano 2009-02-01 3:37 ` Sam Vilain 2009-02-01 21:33 ` Junio C Hamano 2009-02-02 7:00 ` Sam Vilain 2009-02-02 8:32 ` Junio C Hamano 2009-02-02 10:50 ` Sam Vilain 2009-02-01 22:59 ` Johannes Schindelin 2009-02-01 23:56 ` Junio C Hamano
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).