[PATCH] Make the gem usable as a git gem

[PATCH] Make the gem usable as a git gem

[Jean Boussier]

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.

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

—— 

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.

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.
---
 .gitignore             | 2 --
 lib/unicorn/version.rb | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)
 create mode 100644 lib/unicorn/version.rb

diff --git a/.gitignore b/.gitignore
index ad92808..9aa3cad 100644
--- a/.gitignore
+++ b/.gitignore
@@ -11,7 +11,6 @@
 /test/rbx-*
 /test/ruby-*
 ext/unicorn_http/Makefile
-ext/unicorn_http/unicorn_http.c
 log/
 pkg/
 /vendor
@@ -21,5 +20,4 @@ pkg/
 /man
 /tmp
 /LATEST
-/lib/unicorn/version.rb
 /*_1
diff --git a/lib/unicorn/version.rb b/lib/unicorn/version.rb
new file mode 100644
index 0000000..f456bdd
--- /dev/null
+++ b/lib/unicorn/version.rb
@@ -0,0 +1 @@
+Unicorn::Const::UNICORN_VERSION = '6.1.0.dirty'
-- 
2.11.0

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

[Eric Wong]

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.

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

[Jean Boussier]

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


Yes, that’s what I’ve been doing so far, I was just hopping
to upstream this to avoid the hassle.

No big deal, I’ll continue to rebase.

Thanks.