Re: gitignore design

From: Piotr Krukowiecki <piotr.krukowiecki@gmail.com>
Date: Jul 30, 2011, 06:45 UTC
Message-ID: <CAA01Cspv4yShnKBKFFrf8K1tbARahyYf7KZPqbiDFrvFsX9hwg@mail.gmail.com>
In-Reply-To: <CACsJy8CurvKd_=hdRQyjjzWLvKF0jbWOQhbLSsmk1BqB_dK3og@mail.gmail.com>

On Sat, Jul 30, 2011 at 5:10 AM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:

Show 9 quoted lines

> 2011/7/30 Jakub Narebski <jnareb@gmail.com>
>> 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.

I want to have "exclude tracked" feature too, for the same reason as llucianf wrote. I have project files which are tracked but when I use them locally they might get changed (if I modify some options).

The template project files are some solution, but they need changes to the build process, which might not always be possible. Also, with templates you won't have updates (like new project options) in your local copy automatically.

The project files are updated very rarely so handling updates should not be a big problem.

I think the "exclude tracked" option might work like this (all of this
with "unless asked explicitly" assumption):
- diff, stat do not show differences
- add, commit do not add changes
- stash do not stash changes
- merge tries to merge changes from upstream. If there's a conflict
you'll have to resolve it. OR
- merge does not touch your locally unchanged files if they have
changes - if upstream have changes you'll have to make your local
changes disappear (copy file, checkout orig file, merge, analyze what
changed, copy your local changed file back)
- checkout (different branch) - probably same as merge

Show 18 quoted lines

>> > 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.

I was using assume-unchanged for some time but stopped after some weird problems during updates. I'm not sure if this was caused by this or by sparse-checkout (and I use git-svn too). Anyway, after stopping using assume-unchanged and sparse-checkout mysterious problems disappeared.

-- 
Piotr Krukowiecki