Johannes Schindelin [off-list ref] writes:
The scenario is this: the repository contains a file that users are
supposed to change, but not commit to (only the super-intelligent inventor
of this scenario is allowed to). As this repository is originally a
subversion one, there is no problem: people just do not switch branches.
But this guy uses git-svn, so he does switch branches, and to avoid
committing the file by mistake, he marked it assume-unchanged. Only that
a branch switch overwrites the local changes.
If it is a problem that a branch switch overwrites the local changes in
assume-unchanged file, perhaps that is what this person needs to change?
Let's step back a bit and think.
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.
If some paths should not be committed, I'd say it should be handled by a
pre commit hook, and not assume-unchanged.
Is checking with "diff --cached" on the paths and either erroring out (or
better yet resetting the problematic paths in the index) an option?
On Mon, Aug 17, 2009 at 10:41 PM, Junio C Hamano[off-list ref] wrote:
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.
But commit 5f73076 ("Assume unchanged" git) says [1] it favors safety
over performance? Otherwise I'd need to resurrect no-checkout bit.
[1] excerpt from the mentioned commit:
--<--
Index entries marked with CE_VALID bit are assumed to be
unchanged most of the time. However, there are cases that
CE_VALID bit is ignored for the sake of safety and usability:
- while "git-read-tree -m" or git-apply need to make sure
that the paths involved in the merge do not have local
modifications. This sacrifices performance for safety.
- when git-checkout-index -f -q -u -a tries to see if it needs
to checkout the paths. Otherwise you can never check
anything out ;-).
- when git-update-index --really-refresh (a new flag) tries to
see if the index entry is up to date. You can start with
everything marked as CE_VALID and run this once to drop
CE_VALID bit for paths that are modified.
--<--
--
Duy
Hi,
On Mon, 17 Aug 2009, Junio C Hamano wrote:
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.
That's why I did not suggest using assume-unchanged (which the guy did
previously, and was burnt, deservedly, as you say).
However, my illustration of the scenario was only to one end, namely to
convince all of you that assume-changed != sparse.
And maybe to the end to explain that sparse checkout could help this guy.
Ciao,
Dscho