After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 678192 - Dirty .gitignore after building
Dirty .gitignore after building
Status: RESOLVED FIXED
Product: pygobject
Classification: Bindings
Component: general
Git master
Other Linux
: Low trivial
: ---
Assigned To: Nobody's working on this now (help wanted and appreciated)
Python bindings maintainers
Depends on:
Blocks:
 
 
Reported: 2012-06-16 01:12 UTC by Daniel Narvaez
Modified: 2012-07-24 13:22 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
gitignore diff (800 bytes, text/plain)
2012-06-16 01:13 UTC, Daniel Narvaez
  Details
Drop git.mk (9.77 KB, patch)
2012-07-24 11:57 UTC, Daniel Narvaez
none Details | Review

Description Daniel Narvaez 2012-06-16 01:12:23 UTC
After building, my git tree is dirty. I'll attach the diff of the .gitignore which the changes which are being made.
Comment 1 Daniel Narvaez 2012-06-16 01:13:17 UTC
Created attachment 216546 [details]
gitignore diff
Comment 2 Martin Pitt 2012-06-20 09:32:17 UTC
I don't get a dirty .gitignore after building. Sounds like a bug in ./git.mk; it should really not touch an existing .gitignore.
Comment 3 Daniel Narvaez 2012-07-23 15:35:12 UTC
Are you sure git.mk is supposed to not touch  an existing .gitignore? I don't see any code that would cause that.

This is why it is rebuilt

  Considering target file `.gitignore'.
    Pruning file `Makefile.am'.
    Pruning file `git.mk'.
   Finished prerequisites of target file `.gitignore'.
   Prerequisite `Makefile.am' is newer than target `.gitignore'.
   Prerequisite `git.mk' is newer than target `.gitignore'.
  Must remake target `.gitignore'.

In a clean clone, Makefile.am has the same timestamp of the .gitignore. Maybe on my system that results in the file being remade, in your system it doesn't. I suppose if you touch Makefile.am it will remake the .gitignore for you too?

If we really need a manual .gitignore, I suppose we could modify git.mk to check if there is a .gitignore in the git repository before trying to generate it.
Comment 4 Daniel Narvaez 2012-07-23 16:00:33 UTC
Could you explain why we need this "manual" .gitignore? Is it because of the so files that are not ignored by the automatically generated ignores?
Comment 5 Dieter Verfaillie 2012-07-23 16:27:38 UTC
Looks like we're still using an old version of git.mk. What happens
with an updated copy from https://github.com/behdad/git.mk/blob/master/git.mk ?
Comment 6 Daniel Narvaez 2012-07-23 16:34:38 UTC
No changes with latest git.mk
Comment 7 Daniel Narvaez 2012-07-23 16:35:07 UTC
Gah, I mean, nothing changes, same problem as the current one.
Comment 8 Dieter Verfaillie 2012-07-23 17:18:17 UTC
Hmmm, looking at the history of our .gitignore file on
http://git.gnome.org/browse/pygobject/log/.gitignore
and other projects using git.mk (gtk+ & pango), I don't
think we're supposed to have a .gitignore file tracked
in the repo?
Comment 9 Martin Pitt 2012-07-24 04:05:45 UTC
I've "grown up" with manually maintained .gitignore/.bzrignore/etc. files, as usually automatic heurististics are never good enough to automatically generate one. If git.mk is good enough for pygobject (i. e. it does not ignore any file which should be manually maintained, but "git status" shows no new files after a full build), but right now it still does. After removing .gitignore and building I get with "git status":

# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#	gi/__pycache__/
#	gi/_gi.so
#	gi/_gi_cairo.so
#	gi/_glib/__pycache__/
#	gi/_glib/_glib.so
#	gi/_gobject/__pycache__/
#	gi/_gobject/_gobject.so
#	gi/overrides/__pycache__/
#	gi/repository/__pycache__/
#	tests/__pycache__/
#	tests/libgimarshallingtests.so
#	tests/libregress.so
#	tests/testhelper.so
Comment 10 Daniel Narvaez 2012-07-24 11:57:41 UTC
Created attachment 219574 [details] [review]
Drop git.mk

The autogenerated gitignores was missing several files. So we
was using a manual .gitignore at the root. But since it's
enough to add a couple of entries to it to cover the whole
tree, there is no much point in using git.mk at all.

Fixes
Comment 11 Daniel Narvaez 2012-07-24 12:18:52 UTC
Using git.mk seems pointless to me (see the patch).

Alternatively I could make a patch to add *.so and __pycache__ to GITIGNOREFILES. Though I don't like git.mk in general (it seems more trouble than time saved) and especially in the pygobject case it seems overkill.
Comment 12 Martin Pitt 2012-07-24 13:22:19 UTC
Thanks, I applied your patch to remove git.mk. I also prefer maintaining it by hand, it's so little work and avoids problems like this.