There is no reason to forbid a dirty work tree when reverting or
cherry-picking a change, as long as the index is clean.
The scripted version used to allow it:
case "$no_commit" in
t)
# We do not intend to commit immediately. We just want to
# merge the differences in.
head=$(git-write-tree) ||
die "Your index file is unmerged."
;;
*)
head=$(git-rev-parse --verify HEAD) ||
die "You do not have a valid HEAD"
files=$(git-diff-index --cached --name-only $head) || exit
if [ "$files" ]; then
die "Dirty index: cannot $me (dirty: $files)"
fi
;;
esac
but C rewrite tightened the check, probably by mistake.
Signed-off-by: Junio C Hamano <redacted>
---
builtin-revert.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-revert.c b/builtin-revert.c
index cef7147..f704197 100644
--- a/builtin-revert.c
+++ b/builtin-revert.c
@@ -272,7 +272,7 @@ static int revert_or_cherry_pick(int argc, const char **argv)
if (get_sha1("HEAD", head))
die ("You do not have a valid HEAD");
wt_status_prepare(&s);
- if (s.commitable || s.workdir_dirty)
+ if (s.commitable)
die ("Dirty index: cannot %s", me);
discard_cache();
}--
1.5.3.5.1728.g34b3e
Hi,
On Tue, 13 Nov 2007, Junio C Hamano wrote:
There is no reason to forbid a dirty work tree when reverting or
cherry-picking a change, as long as the index is clean.
The scripted version used to allow it:
case "$no_commit" in
t)
# We do not intend to commit immediately. We just want to
# merge the differences in.
head=$(git-write-tree) ||
die "Your index file is unmerged."
;;
*)
head=$(git-rev-parse --verify HEAD) ||
die "You do not have a valid HEAD"
files=$(git-diff-index --cached --name-only $head) || exit
if [ "$files" ]; then
die "Dirty index: cannot $me (dirty: $files)"
fi
;;
esac
but C rewrite tightened the check, probably by mistake.
Probably. Thanks.
While we're at cherry-pick: Two days ago I had to rebase in a dirty
working directory. Why? Because one of the submodules was not yet ready
to be committed to the superproject.
And you cannot easily stash away a submodule.
Now, my quick and dirty solution was to hack a GIT_IGNORE_SUBMODULES
patch:
http://repo.or.cz/w/git/mingw/4msysgit.git?a=commitdiff;h=9ef6b6bff4e368934c4262af13b0a309be19ebd4
But the more fundamental question is: should we eventually have a mode in
cherry-pick (or for that matter, apply!) which can change the submodule?
And if so, how to go about it?
I could imagine that in this case, both apply and cherry-pick should call
submodule with a to-be-created subcommand to reset the named submodule to
a given commit, given the current commit (to avoid races, just as with
update-ref <ref> <newsha1> <oldsha1>). Of course, this subcommand would
fail if the submodule's working directory is dirty.
Thoughts?
Ciao,
Dscho
Johannes Schindelin wrote:
While we're at cherry-pick: Two days ago I had to rebase in a dirty
working directory. Why? Because one of the submodules was not yet ready
to be committed to the superproject.
And you cannot easily stash away a submodule.
git stash --recursive (to be written)? ;-)
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git