update-index --really-refresh unsets assume-unchanged bit
- From
Clemens Buchacher <drizzd@aon.at>
- Date
- May 4, 2010, 08:57 UTC
- Message-ID
- <20100504085722.GA32217@localhost>
- In-Reply-To
- <20100501092720.GB15941@localhost>
On Sat, May 01, 2010 at 11:27:20AM +0200, Clemens Buchacher wrote:
Show 5 quoted lines
> --really-refresh:: > Like '--refresh', but checks stat information unconditionally, > - without regard to the "assume unchanged" setting. > + without regard to the "assume unchanged" setting. The "assume > + unchanged" bit is unset for all paths.
Scratch that latter part, please. I just noticed the bit is unset only for modified files. If the file matches the index, or even if it has been deleted in the work tree, the bit is _not_ unset.
So the current behavior is quite strange. I see several possible interpretations of --really-refresh:
Update index for specified paths, disregarding the assume-unchanged bit,
a) ... and do not ignore work tree changes for tracked files any more.
I.e., unset the assume-unchanged bit for all files. b) ... and do not ignore work tree changes for the specified paths any more.
I.e., unset assume-unchanged bit only for specified paths. c) ... but continue ignoring work tree changes as before.
I.e., do not unset the assume-unchanged bit for any paths.(and the current behavior)
d) ... and do not ignore work tree changes for modified files any more.
I.e., unset assume-unchanged bit for modified paths.I believe c) is the most useful, since it allows the user to deactivate the assume-unchanged bit temporarily. All other options potentially change the assume-unchanged bit, which the user may or may not want. In my opinion, it makes no sense to bundle the two operations "update index disregarding the assume-unchanged bit" and "(conditionally) unset assume-unchanged bit."
Clemens