Re: [PATCH] filter-branch: do not consider diverging submodules a 'dirty worktree'

[Junio C Hamano <gitster@pobox.com>]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> On Wed, 4 Feb 2009, Junio C Hamano wrote:
>
>> Johannes Sixt <j.sixt@viscovery.net> writes:
>> 
>> > Because if the repository is non-bare, then filter-branch updates the
>> > work-tree at the end of the run; we don't want to overwrite uncommitted
>> > work in this case.
>> >
>> > This behavior is a relic from cg-admin-rewritehist, I think. I've never
>> > found it useful.
>> 
>> Ok, I think "read-tree -m -u HEAD" at the end sort of makes sense, if you
>> filtered the branch you are currently sitting on.  Does that mean we do
>> not have to barf on dirtyness if we can tell if the filter-branch will not
>> touch the current branch at all?  Again, I am not suggesting it as an
>> improvement, but I am trying to see if I am talking a total nonsense.
>
> That's correct.  Checking if we would touch the current branch is too 
> expensive here, that's why we don't do it.

Ok, so these exchange suggests that the commit log message needs a bit
more explanation why the check matters before describing why submodules
should not be checked.  Something like this, perhaps?

    At the end of filter-branch in a non-bare repository, the work tree is
    updated with "read-tree -m -u HEAD", to carry the change forward in
    case the current branch was rewritten.  In order to avoid losing any
    local change during this step, filter-branch refuses to work when
    there are local changes in the work tree.

    This "read-tree -m -u HEAD" operation does not affect what commit is
    checked out in a submodule (iow, it does not touch .git/HEAD in a
    submodule checkout), and checking if there is any local change to the
    submodule is not useful.

While I think it makes sense to ignore submodules for the diff-files
check, I do not think it is correct to do so in the check to see if you
have staged changes.  If you updated what commit should be checked out in
your index, and if you run "read-tree -m -u HEAD", it can conflict the
same way as a staged change to a regular blob.  The most trivial example
would be if your filtering were to remove any submodule.  Your work tree
change wanted to modify while the branch switching is to remove and you
have a modify/remove conflict right there.  Or am I again confused?