really stop "really" commits (really!)

[T.C. Hollingsworth]

On Wed, Dec 18, 2013 at 2:17 AM, Vít Ondruch <vondruch at redhat.com> wrote:
> Sorry, but that is not accidental comment.
>
> First of all, we are working with git. I have local clone of git repository
> and I am free to commit whatever I consider to be committed. And I assume
> that you know that you can later edit/squash/drop these commits as well. The
> question is if I push these changes.
>
> An actually yes, I push such changes into 'private' branch. For example, I
> am working on packaging Ruby 2.1.0 for Fedora and I am doing random updates
> of .spec file to random SVN revisions as time permits. If anybody cares
> enough to build and try Ruby 2.1.0 from such branch, (s)he is free to do so,
> but some level of expertise is expected. Missing source tarball in lookaside
> cache should not be issue in this case. Actually it is good think, because
> it would be just waste of space.

Yeah, topic branches make total sense, and I'd make sure this doesn't
bother those.  I also use `fedpkg` on repos that don't point to real
Fedora packages, so I'd definitely take those into account too.

Personally I just think doing it at push time is bad UX.  I often push
the same change to several branches at once, and I'd rather it yell
when I do the commit to rawhide so I can fix it then rather than
having to go back and amend the commit and resync all the branches.

Also, I prefer to separate the "bump version" commit from unrelated
spec changes (e.g. a simple rebasing of a patch belongs in the same
commit as the version bump, fixing something like unversioned docdirs
does not), and `fedpkg new-sources` doesn't play well with `git rebase
--interactive` so if you forget that and don't get warned till push
time, it's either a giant pain to put it in the same commit or you
have to just do an annoying "bump sources" commit.

But if people are really in love with having this done at push time
instead, I can probably find a way to let packagers pick their poison.

-T.C.