Junio C Hamano <gitster@xxxxxxxxx> writes:
> Local changes in git do not belong to any particular branch. They belong
> to the work tree and the index. Hence you (1) can switch from branch A to
> branch B iff the branches do not have difference in the path with local
> changes, and (2) have to stash save, switch branches and then stash pop if
> you have local changes to paths that are different between branches you
> are switching between.
>
> How should assume-unchanged play with this philosophy?
>
> I'd say that assume-unchanged is a promise you make git that you won't
> change these paths, and in return to the promise git will give you faster
> response by not running lstat on them. Having changes in such paths is
> your problem and you deserve these chanegs to be lost. At least, that is
> the interpretation according to the original assume-unchanged semantics.
Having said that, we could (re)define assume-unchanged to mean "I may or
may not have changes to these paths, but I do not mean to commit them, so
do not show them as modified when I ask you for diff. But the changes are
precious nevertheless".
I think the writeout codepath pays attention to assume-unchanged bit
already for that reason (CE_MATCH_IGNORE_VALID is all about this issue).
So with that, how should assume-unchanged play with the "local changes
belong to the index and the work tree"?
- When adding to the index, the changes should be ignored;
- When checking out of the index? I.e. the user tells "git checkout
path" when path is marked as assume-unchanged. Such an explicit
request should probably lose the local changes in the work tree.
- When checking out of a commit? The same deal.
- When switching branches?
- If the branches do not touch assume-unchanged paths, we should keep
changes _and_ assume-unchanged bit. I do not know if that is what
the current code does.
- If the branches do touch assume-unchanged paths, what should happen?
We shouldn't blindly overwrite the local changes, so at least we
should change the code to error out if we do not already do so. But
then what? How does the user deal with this? Perhaps...
- Drop assume-unchanged temporarily;
- Stash save;
- Switch;
- Stash pop;
- Add assume-unchanged again.
???
Is such an updated (or "corrected") assume-unchanged any different from a
sparse checkout? After all, paths that are not to be checked out in a
sparse checkout are "pretend that the lack of these paths are illusion--they
are logically there. I do not intend to commit their removal, and I do not
want to lose the sparseness across branch switch".
There is one nit about this. If a path is outside the checkout area,
should it unconditionally stay outside the checkout area when you switch
branches? I may be interested in not checking out Documentation/
subdirectory and that may hold true for all _my_ branches, and it is a
sane thing not to complain "Oops, you actually removed Makefile in
Documentation/ in your work tree in reality, and you are switching to
another branch that has a different Makefile --- it is a delete-modify
conflict you need to resolve, and we won't let you switch branches" in
such a case.
But is that generally true in all "sparse checkout" settings?
It is unfortunate that this message raises more questions than it answers,
but I think a sparse checkout will have to answer them, whether it uses a
bit separate from assume-unchanged or it reuses the assume-unchanged bit.
--
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