Hi, On Wed, 4 Feb 2009, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > > > On Wed, 4 Feb 2009, Junio C Hamano wrote: > > > >> Johannes Sixt <j.sixt@xxxxxxxxxxxxx> 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. Great! > 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? I removed that change, and added a few words why it makes sense to check that. Thanks, Dscho -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
