How to ignore deleted files

How to ignore deleted files

[Andreas Hildebrandt]

Dear all,

our git repository contains a number of .tar.gz - files that are
automatically extracted and then deleted during the build process.
Unfortunately, commiting any changes after that step will mark those
files as deleted and try to commit that to the repository. Is there any
way to tell git to ignore those files automatically (apart from changing
our build process not to use or not to delete those files)?

Sorry if I overlooked something obvious,

Andreas Hildebrandt

Re: How to ignore deleted files

[Jakub Narebski]

Andreas Hildebrandt <anhi@bioinf.uni-sb.de> writes:

> Dear all,
> 
> our git repository contains a number of .tar.gz - files that are
> automatically extracted and then deleted during the build process.
> Unfortunately, commiting any changes after that step will mark those
> files as deleted and try to commit that to the repository. Is there any
> way to tell git to ignore those files automatically (apart from changing
> our build process not to use or not to delete those files)?

I don't quite understand: are those .tar.gz files stored in _source_
repository? That would be a bit strange...

I guess that you have tried adding "*.tar.gz" to either .gitignore or
.git/info/excludes file?

Another solution would be (if they are truly needed to reside in
repository) to re-checkout them as a last part of build process /
after-build process.

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: How to ignore deleted files

[Andreas Hildebrandt]

Dear Jakub!

Jakub Narebski schrieb:
>> our git repository contains a number of .tar.gz - files that are
>> automatically extracted and then deleted during the build process.
>> Unfortunately, commiting any changes after that step will mark those
>> files as deleted and try to commit that to the repository. Is there any
>> way to tell git to ignore those files automatically (apart from changing
>> our build process not to use or not to delete those files)?
>>     
>
> I don't quite understand: are those .tar.gz files stored in _source_
> repository? That would be a bit strange...
>
>   

I absolutetly agree that it's strange. The main reason for this is that
we have some collections of data files (some of them pretty large) that
can be compressed pretty effectively. At compilation time, it is decided
if the files are needed or not. If so, they are extracted. In the end,
the .tar.gz files are deleted since they are no longer needed. In
addition, once a user obtained a checkout, the whole thing is supposed
to work without a further net connection, so downloading the files
during build is not really an option.

> I guess that you have tried adding "*.tar.gz" to either .gitignore or
> .git/info/excludes file?
>   
I did, but as far as I understand it, these only work for untracked
files, and the files themselves are tracked (from time to time, they
change and the idea was to track those changes). Or am I missing
something here?

btw: I just noted that

git-commit $(git-ls-files -m --exclude-from=.git/info/exclude)

with the correct entries in the exclude file seems to do pretty much
what I want it to do, namely finding all modifications apart from those
mentioned in the exclude file and commiting them. Would this be a sane
strategy to handle things before we can maybe some day re-structure our
build process?


Thanks a lot for your help!

Andreas Hildebrandt

Re: How to ignore deleted files

[Santi Béjar]

On Tue, Mar 11, 2008 at 3:53 PM, Andreas Hildebrandt
<anhi@bioinf.uni-sb.de> wrote:
>
>  I absolutetly agree that it's strange. The main reason for this is that
>  we have some collections of data files (some of them pretty large) that
>  can be compressed pretty effectively. At compilation time, it is decided
>  if the files are needed or not. If so, they are extracted. In the end,
>  the .tar.gz files are deleted since they are no longer needed. In
>  addition, once a user obtained a checkout, the whole thing is supposed
>  to work without a further net connection, so downloading the files
>  during build is not really an option.

Maybe you can have a look to pristine-tar. From:

http://kitenet.net/~joey/code/pristine-tar/

pristine-tar can regenerate a pristine upstream tarball using only a
small binary delta file and a copy of the source which can be a
revision control checkout.

The package also includes a pristine-gz command, which can regenerate
a pristine .gz file.

The delta file is designed to be checked into revision control
along-side the source code, thus allowing the original tarball to be
extracted from revision control.

---------------------

So you can recreate the tar from files in a git branch.

Santi

Re: How to ignore deleted files

[David Tweed]

On Tue, Mar 11, 2008 at 2:53 PM, Andreas Hildebrandt
<anhi@bioinf.uni-sb.de> wrote:
>  I absolutetly agree that it's strange. The main reason for this is that
>  we have some collections of data files (some of them pretty large) that
>  can be compressed pretty effectively. At compilation time, it is decided
>  if the files are needed or not. If so, they are extracted. In the end,
>  the .tar.gz files are deleted since they are no longer needed. In

This is probably a silly questions: why are you actually deleting the
tar.gz files? If they compress the data files well, then any storage
requirement for keeping them is dwarfed by the size of the unpacked
data files (presumably). If a minor tweak to your build process avoids
more complicated git scripting, that sounds a reasonable trade-off.

-- 
cheers, dave tweed__________________________
david.tweed@gmail.com
Rm 124, School of Systems Engineering, University of Reading.
"while having code so boring anyone can maintain it, use Python." --
attempted insult seen on slashdot

Git and pristine-tar

[Sergio Callegari]

> Maybe you can have a look to pristine-tar. From:
> 
> http://kitenet.net/~joey/code/pristine-tar/
> 

I have just given a look to pristine tar.  If I understand correctly what it
does, I believe it would be very nice to have a pristine zip too. That should
do the job nicely with all opendocument files, making openoffice document
management with git very parsimonious on storage.

Am I correct?