git commit doesn’t commit? (GitPython bug)

Mostly posting this to remind myself of the fix the next time I run into this but htis might help some other people as well.

Every once in a while I’ll be working on a git repo in the fedora packages repository and when I git commit -a it, I’ll end up with an empty commit and the files with changes aren’t actually committed. Other intuitive variations of this like git add FILE && git commit have the same buggy behaviour.

The reason this is occurring has something to do with the GitPython library which is used by fedpkg to add some changes to your clone of the git repo when you add new source files. It’s somehow changing the index in a way that causes this behaviour. To get out of this there’s a few simple but non-intuitive things you can try:

git reset FILE && git add FILE

git stash && git stash pop

After running one of those pairs of commands you should once more be able to git commit -a.

Details in this GitPython bug report

Fix it Clientside

In Addicted to Updates, poelcat writes that he feels a compulsion to update even though he usually doesn’t see any benefit from doing so.  In explaining this need he writes:

The only answer I can come up with is that it is tied to an unvalidated hope that “running the latest and greatest” software will result in fewer problems.

I would add that I don’t update my system frequently just because I want to have fixes for bugs; I also want additional features that will make me more productive.  When something doesn’t work for me — whether because of a bug or because a missing feature gets in the way of my workflow, I really want an upgrade in order to fix it. When something is working fine for me, I don’t care one way or the other whether an upgrade comes out. When an upgrade breaks something that was previously working, I am upset by the change. This satisfaction or lack of satisfaction is very much driven by what I, as an individual, need. The problem we have in Fedora is that we have many individuals with different needs. I think getting updates available from Fedora repositories but being able to filter them clientside would be great. skvidal’s idea of extra metadata that tells why an update was generated seems like a good starting point. With that, someone can write a yum plugin to include (or exclude) a certain class of updates by default. So the default Fedora install might only install security and bug fixes and their dependencies when yum upgrade is run. But a user who has a need for drivers for his new printer could yum update to a newer gutenprint package because the package is available in the repositories… just not updated because it is an enhancement rather than a security fix.

As for target audience for Fedora which poelcat also brings up, I’m coming to believe more and more that we’ve painted ourselves into a sticky corner. In an ideal world, Fedora the Project and Fedora the Distribution would exist separately (and likely under different names). Fedora the Project’s target audience is people who want to build Linux Distributions (and possibly people who want to build Operating Systems that don’t follow the Unix philosophy as well). In this ideal, the distributions that are created from Fedora the Project’s package set can then grow more individual identities that allow them to address individual target audiences.

The problem we are faced with is that Fedora the Project and Fedora the Distribution(s) currently share the same name and same brand and do not have an easy way to disentangle themselves.  People come to the Fedora Project website expecting to find a Linux Distribution.  Depending on who you talk to Fedora means the Project that people can contribute to, the distribution that is our default spin, or the package set that is used to compose all of the Fedora Spins.

  • Should either the Project or the Distribution rebrand to separate these two aspects?
  • Which rebranding will cause the least confusion?