{"thread":{"id":"9029","subject":"[PATCH] git-reset: allow --soft in a bare repo","startedAt":"2007-07-14T04:49:16Z","lastAt":"2007-07-15T01:02:15Z","messageCount":5,"participants":["Jeff King","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"47310","messageId":"20070714044916.GA24911@coredump.intra.peff.net","threadId":"9029","inReplyTo":null,"subject":"[PATCH] git-reset: allow --soft in a bare repo","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-07-14T04:49:16Z","receivedAt":"2007-07-14T04:49:16Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"Previously, git-reset always required a work directory. For\n--mixed and --hard resets, this makes sense, as the bare\nrepo doesn't have an index or a working tree. However, for\n--soft, there's no reason to prohibit this behavior.\n\nSigned-off-by: Jeff King <peff@peff.net>\n---\nSomebody asked about this on irc (\"how do I rewind history in a bare\nrepo\"). The only other ways right now are to update the ref manually\n(which involves plumbing), or to \"git-push -f\" from a non-bare\nrepository. I can't think of any good reason why a soft reset shouldn't\nbe allowed.\n\n git-reset.sh |    8 +++++++-\n 1 files changed, 7 insertions(+), 1 deletions(-)\n\ndiff --git a/git-reset.sh b/git-reset.sh\nindex 1dc606f..5450289 100755\n--- a/git-reset.sh\n+++ b/git-reset.sh\n@@ -6,7 +6,6 @@ USAGE='[--mixed | --soft | --hard]  [<commit-ish>] [ [--] <paths>...]'\n SUBDIRECTORY_OK=Yes\n . git-sh-setup\n set_reflog_action \"reset $*\"\n-require_work_tree\n \n update= reset_type=--mixed\n unset rev\n@@ -32,6 +31,13 @@ do\n \tshift\n done\n \n+case \"$reset_type\" in\n+\t--soft)\n+\t\t;;\n+\t*)\n+\t\trequire_work_tree\n+esac\n+\n : ${rev=HEAD}\n rev=$(git rev-parse --verify $rev^0) || exit\n \n-- \n1.5.3.rc1.807.g51fb9-dirty\n"},{"id":"47311","messageId":"7vir8nmujo.fsf@assigned-by-dhcp.cox.net","threadId":"9029","inReplyTo":"20070714044916.GA24911@coredump.intra.peff.net","subject":"Re: [PATCH] git-reset: allow --soft in a bare repo","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-07-14T05:19:23Z","receivedAt":"2007-07-14T05:19:23Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> Previously, git-reset always required a work directory. For\n> --mixed and --hard resets, this makes sense, as the bare\n> repo doesn't have an index or a working tree. However, for\n> --soft, there's no reason to prohibit this behavior.\n>\n> Signed-off-by: Jeff King <peff@peff.net>\n> ---\n> Somebody asked about this on irc (\"how do I rewind history in a bare\n> repo\"). The only other ways right now are to update the ref manually\n> (which involves plumbing), or to \"git-push -f\" from a non-bare\n> repository. I can't think of any good reason why a soft reset shouldn't\n> be allowed.\n\nHow about \"git branch -f this $that\"???\n"},{"id":"47312","messageId":"20070714052405.GA26107@coredump.intra.peff.net","threadId":"9029","inReplyTo":"7vir8nmujo.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] git-reset: allow --soft in a bare repo","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-07-14T05:24:05Z","receivedAt":"2007-07-14T05:24:05Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jul 13, 2007 at 10:19:23PM -0700, Junio C Hamano wrote:\n\n> > Somebody asked about this on irc (\"how do I rewind history in a bare\n> > repo\"). The only other ways right now are to update the ref manually\n> > (which involves plumbing), or to \"git-push -f\" from a non-bare\n> > repository. I can't think of any good reason why a soft reset shouldn't\n> > be allowed.\n> \n> How about \"git branch -f this $that\"???\n\nAh, I hadn't thought of that. It seems a bit of a contortion, though,\nsince git-branch is usually used for _making_ a branch, whereas\ngit-reset is usually used for _changing_ a branch. But maybe that's just\nme.\n\nAt any rate, it might still be worth applying the patch. It should be\nharmless to loosen the restriction, and even if there are several ways\nto accomplish the same thing, why punish people who try git-reset first?\nOn the other hand, this is the first time I've seen it come up, so maybe\nthis isn't confusing people.\n\n-Peff\n"},{"id":"47328","messageId":"7v7ip3jsf8.fsf@assigned-by-dhcp.cox.net","threadId":"9029","inReplyTo":"20070714052405.GA26107@coredump.intra.peff.net","subject":"Re: [PATCH] git-reset: allow --soft in a bare repo","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-07-14T08:33:31Z","receivedAt":"2007-07-14T08:33:31Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> Ah, I hadn't thought of that. It seems a bit of a contortion, though,\n> since git-branch is usually used for _making_ a branch, whereas\n> git-reset is usually used for _changing_ a branch. But maybe that's just\n> me.\n\n\"branch -f\" is very often used to \"reset the branch tip\".  My\ngit day typically begins with \"branch -f pu next\".\n\n> At any rate, it might still be worth applying the patch. It should be\n> harmless to loosen the restriction, and even if there are several ways\n> to accomplish the same thing, why punish people who try git-reset first?\n> On the other hand, this is the first time I've seen it come up, so maybe\n> this isn't confusing people.\n\nActually, after thinking about this a bit more, I have become\nsomewhat reluctant, as this might confuse new users by giving\nthem a wrong mental model of what \"reset\" is about.\n\nTo my mind, as an old time git user, reset (any variant) has\nalways been about reshaping the relationship among the HEAD, the\nindex and the working tree; if there is no index nor the working\ntree (iow, a bare repository), there can be no \"relationship\"\namong them.\n\nWe initially had only --mixed and --hard (and the former was not\neven called --mixed as there were only two kinds).  Then --soft\nwas invented as a stop-gap measure before \"commit --amend\" came.\n\nIn all cases, the user is saying \"I want to make the next commit\nI'll make on top of that commit (which may or may not be\ndifferent from the HEAD), and I'd want to start working towards\nthat goal, starting from such and such index and working tree\nstate\".  And that \"such and such state\" is different among three\nvariants:\n\n * \"reset --mixed\" means \"I like what I have in the working\n   tree, but I'd want to discard the index and start from what\n   is in (possibly updated) HEAD instead\";\n\n * \"reset --hard\" means \"I want to restart both index and\n   working tree from scratch, starting from (possibly updated)\n   HEAD\";\n\n * \"reset --soft\" means \"I like what I have in the index and\n   also I like what I have in the working tree -- do not touch\n   them -- I want the next commit to go on top of that commit\".\n\n\"reset --soft\" happens to be a variant of reset that does not\ntouch index nor working tree, but conceptually, \"not touching\"\nand \"not having either is Ok\" are two quite different things.\n"},{"id":"47391","messageId":"20070715010215.GA20676@sigill.intra.peff.net","threadId":"9029","inReplyTo":"7v7ip3jsf8.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] git-reset: allow --soft in a bare repo","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-07-15T01:02:15Z","receivedAt":"2007-07-15T01:02:15Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Jul 14, 2007 at 01:33:31AM -0700, Junio C Hamano wrote:\n\n> > since git-branch is usually used for _making_ a branch, whereas\n> \"branch -f\" is very often used to \"reset the branch tip\".  My\n> git day typically begins with \"branch -f pu next\".\n\nI think we just have a different perspective of what is \"usual\" here.\n\n> Actually, after thinking about this a bit more, I have become\n> somewhat reluctant, as this might confuse new users by giving\n> them a wrong mental model of what \"reset\" is about.\n\nOK, as I said on irc, I don't think this is a huge issue in the first\nplace, and your argument about encouraging a particular workflow for\ngit-reset makes some sense (even if that hasn't been my approach to\ngit-reset in the past).\n\n-Peff\n"}]}