Louis-Philippe Véronneau - githttps://veronneau.org/2020-11-17T00:00:00-05:00A better git diff2020-11-17T00:00:00-05:002020-11-17T00:00:00-05:00Louis-Philippe Véronneautag:veronneau.org,2020-11-17:/a-better-git-diff.html<p>A few days ago I wrote a quick patch and missed a dumb mistake that made the
program crash. When reviewing the merge request on Salsa, the problem became
immediately apparent; Gitlab's diff is much better than what <code>git diff</code> shows by
default in a terminal.</p>
<p>Well, it turns out …</p><p>A few days ago I wrote a quick patch and missed a dumb mistake that made the
program crash. When reviewing the merge request on Salsa, the problem became
immediately apparent; Gitlab's diff is much better than what <code>git diff</code> shows by
default in a terminal.</p>
<p>Well, it turns out <a href="https://github.blog/2016-06-13-git-2-9-has-been-released/">since version 2.9</a>, git bundles a better pager,
<code>diff-highlight</code>. <em>À la</em> Gitlab, it will highlight what changed in the line.</p>
<p><img src="/media/blog/2020-11-17/diff.png" width="70%" style="margin-left:15%" title="The output of git diff using diff-highlight" alt="The output of git diff using diff-highlight"></p>
<p>Sadly, even though <code>diff-highlight</code> comes with the git package in Debian, it is
not built by default <a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925288">(925288)</a>. You will need to:</p>
<pre>
$ sudo make --directory /usr/share/doc/git/contrib/diff-highlight
</pre>
<p>You can then add this line to your <code>.gitconfig</code> file:</p>
<pre>
[core]
pager = /usr/share/doc/git/contrib/diff-highlight/diff-highlight | less --tabs=4 -RFX
</pre>
<p>If you use <code>tig</code>, you'll also need to add this line in your <code>tigrc</code>:</p>
<pre>
set diff-highlight = /usr/share/doc/git/contrib/diff-highlight/diff-highlight
</pre>Trying out Sourcehut2019-10-10T00:00:00-04:002019-10-10T00:00:00-04:00Louis-Philippe Véronneautag:veronneau.org,2019-10-10:/trying-out-sourcehut.html<p><a href="https://github.com/isbg/isbg/issues/131">Last month</a>, I decided it was finally time to move a project I maintain
from Github<sup id="fnref:migrating"><a class="footnote-ref" href="#fn:migrating">1</a></sup> to another git hosting platform.</p>
<p>While polling other contributors (I proposed moving to gitlab.com), someone
suggested moving to <a href="https://sourcehut.org/">Sourcehut</a>, a newish git hosting platform written
and maintained by Drew DeVault. I've been …</p><p><a href="https://github.com/isbg/isbg/issues/131">Last month</a>, I decided it was finally time to move a project I maintain
from Github<sup id="fnref:migrating"><a class="footnote-ref" href="#fn:migrating">1</a></sup> to another git hosting platform.</p>
<p>While polling other contributors (I proposed moving to gitlab.com), someone
suggested moving to <a href="https://sourcehut.org/">Sourcehut</a>, a newish git hosting platform written
and maintained by Drew DeVault. I've been following Drew's work for a while now
and although I had read a few blog posts on Sourcehut's development, I had
never really considered giving it a try. So I did!</p>
<p>Sourcehut is still in alpha and I'm expecting a lot of things to change in the
future, but here's my quick review.</p>
<h2>Things I like</h2>
<h3>Sustainable FOSS</h3>
<p>Sourcehut is 100% Free Software. Github is proprietary and I dislike Gitlab's
Open Core business model.</p>
<p>Sourcehut's business model also seems sustainable to me, as it relies on people
paying a monthly fee for the service. You'll need to pay if you want your code
hosted on <a href="https://sr.ht">https://sr.ht</a> once Sourcehut moves into beta. As I've written
previously, <a href="/paying-for-the-internet.html">I like that a lot</a>.</p>
<p>In comparison, Gitlab is mainly funded by venture capital and I'm afraid of the
long term repercussions this choice will have.</p>
<h3>Continuous Integration</h3>
<p>Continuous Integration is very important to me and I'm happy to say Sourcehut's
CI is pretty good! Like Travis and Gitlab CI, you declare what needs to happen
in a YAML file. The CI uses real virtual machines backed by QEMU, so you can
run many different distros and CPU archs!</p>
<p>Even nicer, you can actually SSH into a failed CI job to debug things. In
comparison, Gitlab CI's <a href="https://docs.gitlab.com/ce/ci/interactive_web_terminal/">Interactive Web Terminal</a> is ... web
based and thus not as nice. Worse, it seems it's still somewhat buggy as Gitlab
still hasn't enabled it on their gitlab.com instance.</p>
<p>Here's what the instructions to SSH into the CI look like when a job fails:</p>
<div class="highlight"><pre><span></span><code><span class="n">This</span><span class="w"> </span><span class="n">build</span><span class="w"> </span><span class="n">job</span><span class="w"> </span><span class="n">failed</span><span class="p">.</span><span class="w"> </span><span class="n">You</span><span class="w"> </span><span class="n">may</span><span class="w"> </span><span class="nf">log</span><span class="w"> </span><span class="k">into</span><span class="w"> </span><span class="n">the</span><span class="w"> </span><span class="n">failed</span><span class="w"> </span><span class="n">build</span><span class="w"> </span><span class="n">environment</span><span class="w"> </span><span class="k">within</span><span class="w"> </span><span class="mi">10</span>
<span class="n">minutes</span><span class="w"> </span><span class="k">to</span><span class="w"> </span><span class="n">examine</span><span class="w"> </span><span class="n">the</span><span class="w"> </span><span class="n">results</span><span class="w"> </span><span class="k">with</span><span class="w"> </span><span class="n">the</span><span class="w"> </span><span class="n">following</span><span class="w"> </span><span class="nl">command</span><span class="p">:</span>
<span class="n">ssh</span><span class="w"> </span><span class="o">-</span><span class="n">t</span><span class="w"> </span><span class="n">builds</span><span class="nv">@foo</span><span class="p">.</span><span class="n">bar</span><span class="w"> </span><span class="k">connect</span><span class="w"> </span><span class="n">NUMBER</span>
</code></pre></div>
<p>Sourcehut's CI is not as feature-rich or as flexible as Gitlab CI, but I feel
it is more powerful then Gitlab CI's default docker executor. Folks that run
integration tests or more complicated setups where Docker fails should
definitely give it a try.</p>
<p>From the few tests I did, Sourcehut's CI is also pretty quick (it's definitely
faster than Travis or Gitlab CI).</p>
<h3>No JS</h3>
<p>Although Sourcehut's web interface does bundle some Javascript, all features
work without it. Three cheers for that!</p>
<h2>Things I dislike</h2>
<h3>Features division</h3>
<p>I'm not sure I like the way features (the issue tracker, the CI builds, the git
repository, the wikis, etc.) are subdivided in different subdomains.</p>
<p>For example, when you create a git repository on <code>git.sr.ht</code>, you only get a git
repository. If you want an issue tracker for that git repository, you have to
create one at <code>todo.sr.ht</code> with the same name. That issue tracker isn't visible
from the git repository web interface.</p>
<p>That's the same for all the features. For example, you don't see the build
status of a merged commit when you look at it. This design choice makes you feel
like the different features aren't integrated to one another.</p>
<p>In comparison, Gitlab and Github use a more "centralised" approach: everything
is centered around a central interface (your git repository) and it feels more
natural to me.</p>
<h3>Discoverability</h3>
<p>I haven't seen a way to search <code>sr.ht</code> for things hosted there. That makes it
hard to find repositories, issues or even the Sourcehut source code!</p>
<h3>Merge Request workflow</h3>
<p>I'm a sucker for the Merge Request workflow. I really like to have a big green
button I can click on to merge things. I know some people prefer a more manual
workflow that uses <code>git merge</code> and stuff, but I find that tiresome.</p>
<p>Sourcehut chose a workflow based on sending patches by email. It's neat since
you can submit code without having an account. Sourcehut also provides mailing
lists for projects, so people can send patches to a central place.</p>
<p>I find that workflow harder to work with, since to me it makes it more
difficult to see what patches have been submitted. It also makes the review
process more tedious, since the CI isn't ran automatically on email patches.</p>
<h2>Summary</h2>
<p>All in all, I don't think I'll be moving ISBG to Sourcehut (yet?). At the
moment it doesn't quite feel as ready as I'd want it to be, and that's OK. Most
of the things I disliked about the service can be fixed by some UI work and I'm
sure people are already working on it.</p>
<p>Github was bought by MS for 7.5 billion USD and Gitlab is currently valued at
2.7 billion USD. It's not really fair to ask Sourcehut to fully compete just
yet :)</p>
<p>With Sourcehut, Drew DeVault is fighting the good fight and I wish him the most
resounding success. Who knows, maybe I'll really migrate to it in a few years!</p>
<div class="footnote">
<hr>
<ol>
<li id="fn:migrating">
<p>Github is a proprietary service, <a href="/lets-migrate-away-from-github.html">has been bought by Microsoft</a>
and gosh darn do I hate Travis CI. <a class="footnote-backref" href="#fnref:migrating" title="Jump back to footnote 1 in the text">↩</a></p>
</li>
</ol>
</div>Let's migrate away from GitHub2018-06-03T00:00:00-04:002018-06-03T00:00:00-04:00Louis-Philippe Véronneautag:veronneau.org,2018-06-03:/lets-migrate-away-from-github.html<p>As many of you heard today, <a href="https://www.bloomberg.com/news/articles/2018-06-03/microsoft-is-said-to-have-agreed-to-acquire-coding-site-github">Microsoft is acquiring GitHub</a>. What
this means for the future of GitHub is not yet clear, but <a href="https://about.gitlab.com/2018/06/03/microsoft-acquires-github/">the folks at
Gitlab</a> think Microsoft's end goal is to integrate GitHub in their
Azure empire. To me, this makes a lot of sense.</p>
<p>Even though I …</p><p>As many of you heard today, <a href="https://www.bloomberg.com/news/articles/2018-06-03/microsoft-is-said-to-have-agreed-to-acquire-coding-site-github">Microsoft is acquiring GitHub</a>. What
this means for the future of GitHub is not yet clear, but <a href="https://about.gitlab.com/2018/06/03/microsoft-acquires-github/">the folks at
Gitlab</a> think Microsoft's end goal is to integrate GitHub in their
Azure empire. To me, this makes a lot of sense.</p>
<p>Even though I still reluctantly use GitHub for some projects, I migrated all
my personal repositories to Gitlab instances a while ago<sup id="fnref:1"><a class="footnote-ref" href="#fn:1">1</a></sup>. Now is time for
you to do the same and ditch GitHub.</p>
<p><img src="/media/blog/2018-06-03/ms-lovent-linux.png" title="Microsoft loven't Linux" alt="Microsft loven't Linux" height="25%" width="25%" style="float:right"></p>
<p>Some people might be fine with Microsoft's takeover, but to me it's the straw
that breaks the camel's back. For a few years now, MS has been running a large
marketing campaign on how they love Linux and suddenly decided to embrace Free
Software in all of its forms. More like MS BS to me.</p>
<p>Let us take a moment to remind ourselves that:</p>
<ul>
<li>Windows is still a huge proprietary monster that rips billions of people from
their privacy and rights every day.</li>
<li>Microsoft is known for spreading FUD about "the dangers" of Free Software in
order to keep governments and schools from dropping Windows in favor of FOSS.</li>
<li>To secure their monopoly, Microsoft hooks up kids on Windows by giving out
"free" licences to primary schools around the world. Drug dealers use the same
tactics and give out free samples to secure new clients.</li>
<li>Microsoft's Azure platform - even though it can run Linux VMs - is still a
giant proprietary hypervisor.</li>
</ul>
<p>I know moving git repositories around can seem like a pain in the ass, but the
folks at Gitlab are riding the wave of people leaving GitHub and made the the
migration easy <a href="https://docs.gitlab.com/ee/user/project/import/github.html">by providing a GitHub importer</a>.</p>
<p>If you don't want to use Gitlab's main instance (<a href="https://gitlab.org">gitlab.org</a>), here
are two other alternative instances you can use for Free Software projects:</p>
<ul>
<li>The <a href="https://salsa.debian.org">Debian Gitlab instance</a> is available for every FOSS project and
not only for Debian-related ones<sup id="fnref:2"><a class="footnote-ref" href="#fn:2">2</a></sup>. As long as the project respects the
<a href="https://en.wikipedia.org/wiki/Debian_Free_Software_Guidelines">Debian Free Software Guidelines</a>, you can use the instance and its CI
runners.</li>
<li>Riseup maintains a Gitlab instance for radical projects named <a href="https://0xacab.org">0xacab</a>. If
your <a href="https://riseup.net/en/about-us/politics">ethos aligns with Riseup's</a>, chances are they'll be happy to host
your projects there.</li>
</ul>
<p>Friends don't let friends use GitHub anymore.</p>
<div class="footnote">
<hr>
<ol>
<li id="fn:1">
<p>Gitlab is pretty good, but it should not be viewed as a panacea: it's
still an open-core product made by a for-profit enterprise that could one
day be sold to a large corp like Oracle or Microsoft. <a class="footnote-backref" href="#fnref:1" title="Jump back to footnote 1 in the text">↩</a></p>
</li>
<li id="fn:2">
<p>See the <a href="https://wiki.debian.org/Salsa/FAQ#What_can_be_hosted_on_salsa">Salsa FAQ</a> for more details. <a class="footnote-backref" href="#fnref:2" title="Jump back to footnote 2 in the text">↩</a></p>
</li>
</ol>
</div>