{"thread":{"id":"10854","subject":"[PATCH] revert/cherry-pick: allow starting from dirty work tree.","startedAt":"2007-11-13T21:16:28Z","lastAt":"2007-11-14T01:05:23Z","messageCount":4,"participants":["Junio C Hamano","Johannes Schindelin","Jakub Narebski"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"59732","messageId":"7vd4udsv6b.fsf@gitster.siamese.dyndns.org","threadId":"10854","inReplyTo":null,"subject":"[PATCH] revert/cherry-pick: allow starting from dirty work tree.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-13T21:16:28Z","receivedAt":"2007-11-13T21:16:28Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"There is no reason to forbid a dirty work tree when reverting or\ncherry-picking a change, as long as the index is clean.\n\nThe scripted version used to allow it:\n\n    case \"$no_commit\" in\n    t)\n    \t# We do not intend to commit immediately.  We just want to\n    \t# merge the differences in.\n    \thead=$(git-write-tree) ||\n    \t\tdie \"Your index file is unmerged.\"\n    \t;;\n    *)\n    \thead=$(git-rev-parse --verify HEAD) ||\n    \t\tdie \"You do not have a valid HEAD\"\n    \tfiles=$(git-diff-index --cached --name-only $head) || exit\n    \tif [ \"$files\" ]; then\n    \t\tdie \"Dirty index: cannot $me (dirty: $files)\"\n    \tfi\n    \t;;\n    esac\n\nbut C rewrite tightened the check, probably by mistake.\n\nSigned-off-by: Junio C Hamano <gitster@pobox.com>\n---\n builtin-revert.c |    2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\ndiff --git a/builtin-revert.c b/builtin-revert.c\nindex cef7147..f704197 100644\n--- a/builtin-revert.c\n+++ b/builtin-revert.c\n@@ -272,7 +272,7 @@ static int revert_or_cherry_pick(int argc, const char **argv)\n \t\tif (get_sha1(\"HEAD\", head))\n \t\t\tdie (\"You do not have a valid HEAD\");\n \t\twt_status_prepare(&s);\n-\t\tif (s.commitable || s.workdir_dirty)\n+\t\tif (s.commitable)\n \t\t\tdie (\"Dirty index: cannot %s\", me);\n \t\tdiscard_cache();\n \t}\n-- \n1.5.3.5.1728.g34b3e\n"},{"id":"59771","messageId":"Pine.LNX.4.64.0711132154370.4362@racer.site","threadId":"10854","inReplyTo":"7vd4udsv6b.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] revert/cherry-pick: allow starting from dirty work tree.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-13T23:37:34Z","receivedAt":"2007-11-13T23:37:34Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 13 Nov 2007, Junio C Hamano wrote:\n\n> There is no reason to forbid a dirty work tree when reverting or\n> cherry-picking a change, as long as the index is clean.\n> \n> The scripted version used to allow it:\n> \n>     case \"$no_commit\" in\n>     t)\n>     \t# We do not intend to commit immediately.  We just want to\n>     \t# merge the differences in.\n>     \thead=$(git-write-tree) ||\n>     \t\tdie \"Your index file is unmerged.\"\n>     \t;;\n>     *)\n>     \thead=$(git-rev-parse --verify HEAD) ||\n>     \t\tdie \"You do not have a valid HEAD\"\n>     \tfiles=$(git-diff-index --cached --name-only $head) || exit\n>     \tif [ \"$files\" ]; then\n>     \t\tdie \"Dirty index: cannot $me (dirty: $files)\"\n>     \tfi\n>     \t;;\n>     esac\n> \n> but C rewrite tightened the check, probably by mistake.\n\nProbably.  Thanks.\n\nWhile we're at cherry-pick: Two days ago I had to rebase in a dirty \nworking directory.  Why?  Because one of the submodules was not yet ready \nto be committed to the superproject.\n\nAnd you cannot easily stash away a submodule.\n\nNow, my quick and dirty solution was to hack a GIT_IGNORE_SUBMODULES \npatch: \nhttp://repo.or.cz/w/git/mingw/4msysgit.git?a=commitdiff;h=9ef6b6bff4e368934c4262af13b0a309be19ebd4\n\nBut the more fundamental question is: should we eventually have a mode in \ncherry-pick (or for that matter, apply!) which can change the submodule?  \nAnd if so, how to go about it?\n\nI could imagine that in this case, both apply and cherry-pick should call \nsubmodule with a to-be-created subcommand to reset the named submodule to \na given commit, given the current commit (to avoid races, just as with \nupdate-ref <ref> <newsha1> <oldsha1>).  Of course, this subcommand would \nfail if the submodule's working directory is dirty.\n\nThoughts?\n\nCiao,\nDscho\n"},{"id":"59792","messageId":"fhdf2o$v60$1@ger.gmane.org","threadId":"10854","inReplyTo":"Pine.LNX.4.64.0711132154370.4362@racer.site","subject":"Re: [PATCH] revert/cherry-pick: allow starting from dirty work tree.","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-11-14T00:21:47Z","receivedAt":"2007-11-14T00:21:47Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Johannes Schindelin wrote:\n\n> While we're at cherry-pick: Two days ago I had to rebase in a dirty \n> working directory.  Why?  Because one of the submodules was not yet ready \n> to be committed to the superproject.\n> \n> And you cannot easily stash away a submodule.\n\ngit stash --recursive (to be written)? ;-)\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"59798","messageId":"7vy7d1prfw.fsf@gitster.siamese.dyndns.org","threadId":"10854","inReplyTo":"Pine.LNX.4.64.0711132154370.4362@racer.site","subject":"Re: [PATCH] revert/cherry-pick: allow starting from dirty work tree.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-14T01:05:23Z","receivedAt":"2007-11-14T01:05:23Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> But the more fundamental question is: should we eventually have a mode in \n> cherry-pick (or for that matter, apply!) which can change the submodule?  \n> And if so, how to go about it?\n\nI think that would be handled in exactly the same way as\nswitching between two branches that bind different commits at\nthe submodule path.\n\nYour work tree and index knows commit X is at the path, an\noperation wants to have commit Y at the path as its result.\n\nWhat's next?\n\nIt does not make much difference what that \"an operation\" is.\nIt can be apply, cherry-pick, revert, merge, or branch\nswitching.  I think they can and should follow the same rules.\n\nThe most important rule is not to lose local changes, be they in\nthe index or in the work tree.  So \"an operation\" would error\nout if the index does not match HEAD at such a path, and the\nwork tree does not match the index.\n\nThe implementation of \"work tree does not match the index\" is\ndifferent when you are talking about a regular blob vs a\nsubmodule.  For a blob you know what we do.  For a submodule, I\nwould imagine that we would check if both the index matches the\nHEAD and the work tree matches the index in the submodule\n(this would go recursively).\n\nAnd after making sure we won't lose local changes, we switch the\nsubmodule directory from commit X to commit Y.  Most likely\ndetaching the HEAD with \"cd sub && git checkout Y^0\" or\nsomething like that.\n\nThen probably there will be an option added to loosen that \"work\ntree matches the index\" check and uses \"-m\" option to the\ncheckout in the submodule directory.\n\nMore tricky is what to do with a submodule that would disappear,\nthough.  For that, we would want .git/subprojects/foo.git/ trick\nwe have discussed in the past or something similar.\n"}]}