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

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Nov 13, 2007, 23:37 UTC
Message-ID: <Pine.LNX.4.64.0711132154370.4362@racer.site>
In-Reply-To: <7vd4udsv6b.fsf@gitster.siamese.dyndns.org>

Hi,

On Tue, 13 Nov 2007, Junio C Hamano wrote:

Show 23 quoted lines

> 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