Re: [PATCH] Make the gem usable as a git gem

[Eric Wong <e@80x24.org>]

Jean Boussier <jean.boussier@gmail.com> wrote:
> Ok, so I’m sorry, but I’ve now tried for hours and
> I can’t for the life of me figure out how to send a patch
> cleanly with the tools I have available.

Ugh, I guess your employer doesn't want you fixing Linux kernel bugs,
either :<

> So you can download the patch here:
> https://github.com/byroot/unicorn/commit/e7f49852875de54cce974c7cbdd5540ddc5e4eeb.patch

OK, I suggest setting up mirrors on repo.or.cz or somewhere
else, as well, for redundancy and accessibility behind
blockades/firewalls.

> —— 
> 
> Bundler allow to install arbitrary revision
> of a gem via its git repository, e.g.
> 
> ```ruby
> gem "unicorn", git: "https://yhbt.net/unicorn.git"
> ```
> 
> But this currently doesn't work with unicorn because
> some files are not committed, and they are only generated
> by the makefile.
> 
> This change would make it much easier to test
> unreleased versions.

Understood; but I'm not in favor of having generated files in
version control due to noise from needless diffs/dirty-states.

And I just had problems in another project because of generated
hunks the other day.

I suggest pointing the gemfile towards your own repo and
rebasing this patch on top of upstream, instead.

> NB: I didn't commit ext/unicorn_http/unicorn_http.c
> because I think you might as well generate it and commit
> it yourself so that you don't have to review it.

Minor changes to the .rl files (or Ragel itself) can lead noisy
comment/whitespace changes; and a constant dirty index if two
contributors are using different revisions of Ragel[1].

I encounter constant dirty index with autotools and gnulib-using
projects across different systems, too; and it's a PITA to deal
with when trying to fix platform-specific bugs.

> --- /dev/null
> +++ b/lib/unicorn/version.rb
> @@ -0,0 +1 @@
> +Unicorn::Const::UNICORN_VERSION = '6.1.0.dirty'

That's a regression, a version based on `git describe'
can be quite informative, especially when somebody isn't
sure if they've loaded the correct version or not.



[1] on a side note, I started getting rid of the Ragel dependency
    last year (replacing with vendored picohttpparser), but got
    sidetracked with Real-Life crap which I'm still dealing with.
    The problem is Ragel 7 (experimental) won't be compatible with
    6, and FreeBSD only packages 7 while Debian-based is staying
    with 6 for now.  There were nasty incompatibilities going from
    Ragel 5->6 back in the Mongrel days, too; so I'd rather just go
    with a standalone C parser I've been abusing elsewhere.