Re: [PATCH] revert/cherry-pick: allow starting from dirty work tree.

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