Re: gitignore design

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



2011/7/30 Jakub Narebski <jnareb@xxxxxxxxx>
> True, it is *assume-unchanged*, not ignore-changes bit; though the latter
> would be also possible to implement, I think... but having some file not
> changing and marking it as such for better performance is saner use case
> than tracking some file but not really tracking it.

If you just want to ignore some files (or paths), then adding
--exclude option to diff machinery may be a better option.
--assume-unchanged is too low-level, and not really convenient to use.

> > No code reference, sorry, because I'm just parrotting what I've read
> > elsewhere on the list, for example,
> > http://thread.gmane.org/gmane.comp.version-control.git/146082/focus=146353
>
> Well, there is hint that there might be problems, but not really says
> that they are, and where (if one is lying about assume unchanged by changing
> assume-unchanged file).

There were problems in the past. See aecda37 (do not overwrite files
marked "assume unchanged" - 2010-05-01)

The only place that relies on checking files uptodate (which can be
faked by assume-unchanged bit) before overwriting them is
unpack-trees.c, verify_update_1(). With that fix in place, I think
assume-unchanged bit is safe now. However, as long as we don't
explicitly state that we will not carelessly overwrite
assume-unchanged files, there are still chances that some
optimizations in future may make it dangerous again.
--
Duy
--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]