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

> 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?