davidbgk
/
larlet-fr-david-cache


			
							123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218
							<!doctype html><!-- This is a valid HTML5 document. -->
<!-- Screen readers, SEO, extensions and so on. -->
<html lang="fr">
<!-- Has to be within the first 1024 bytes, hence before the `title` element
  See: https://www.w3.org/TR/2012/CR-html5-20121217/document-metadata.html#charset -->
<meta charset="utf-8">
<!-- Why no `X-UA-Compatible` meta: https://stackoverflow.com/a/6771584 -->
<!-- The viewport meta is quite crowded and we are responsible for that.
  See: https://codepen.io/tigt/post/meta-viewport-for-2015 -->
<meta name="viewport" content="width=device-width,initial-scale=1">
<!-- Required to make a valid HTML5 document. -->
<title>Git email flow vs Github flow (archive) — David Larlet</title>
<meta name="description" content="Publication mise en cache pour en conserver une trace.">
<!-- That good ol' feed, subscribe :). -->
<link rel="alternate" type="application/atom+xml" title="Feed" href="/david/log/">
<!-- Generated from https://realfavicongenerator.net/ such a mess. -->
<link rel="apple-touch-icon" sizes="180x180" href="/static/david/icons2/apple-touch-icon.png">
<link rel="icon" type="image/png" sizes="32x32" href="/static/david/icons2/favicon-32x32.png">
<link rel="icon" type="image/png" sizes="16x16" href="/static/david/icons2/favicon-16x16.png">
<link rel="manifest" href="/static/david/icons2/site.webmanifest">
<link rel="mask-icon" href="/static/david/icons2/safari-pinned-tab.svg" color="#07486c">
<link rel="shortcut icon" href="/static/david/icons2/favicon.ico">
<meta name="msapplication-TileColor" content="#f7f7f7">
<meta name="msapplication-config" content="/static/david/icons2/browserconfig.xml">
<meta name="theme-color" content="#f7f7f7" media="(prefers-color-scheme: light)">
<meta name="theme-color" content="#272727" media="(prefers-color-scheme: dark)">
<!-- Documented, feel free to shoot an email. -->
<link rel="stylesheet" href="/static/david/css/style_2021-01-20.css">
<!-- See https://www.zachleat.com/web/comprehensive-webfonts/ for the trade-off. -->
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<script>
    function toggleTheme(themeName) {
        document.documentElement.classList.toggle(
            'forced-dark',
            themeName === 'dark'
        )
        document.documentElement.classList.toggle(
            'forced-light',
            themeName === 'light'
        )
    }
    const selectedTheme = localStorage.getItem('theme')
    if (selectedTheme !== 'undefined') {
        toggleTheme(selectedTheme)
    }
</script>

  <meta name="robots" content="noindex, nofollow">
  <meta content="origin-when-cross-origin" name="referrer">
  <!-- Canonical URL for SEO purposes -->
  <link rel="canonical" href="https://blog.brixit.nl/git-email-flow-versus-github-flow/">

<body class="remarkdown h1-underline h2-underline h3-underline em-underscore hr-center ul-star pre-tick" data-instant-intensity="viewport-all">


<article>
  <header>
    <h1>Git email flow vs Github flow</h1>
  </header>
  <nav>
    <p class="center">
      <a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home">
        <use xlink:href="/static/david/icons2/symbol-defs.svg#icon-home"></use>
      </svg> Accueil</a> •
      <a href="https://blog.brixit.nl/git-email-flow-versus-github-flow/" title="Lien vers le contenu original">Source originale</a>
    </p>
  </nav>
  <hr>
  <p>So I've been using the Github flow for some years now from both the maintainer side and contributor side to open source projects. I've also been using the email workflow for git from both sides for about a year now. Using email for git sounded quite horrible before I actually started using it. Now I prefer it so I thought I would document my experience here.</p>
<h2>The Github flow</h2>
<p>This isn't strictly for Github, it's the flow many developers are accustomed to:</p>
<ol>
<li>Fork the project repo</li>
<li>Make a change on your fork</li>
<li>Create a pull request from a branch on your fork to the main repository</li>
<li>Get comments on the pull request</li>
<li>Force-push to the same branch to update the state of the pull request</li>
<li>Somebody clicks merge</li>
</ol>
<p>Basically the same flow is also used on Gitlab and the other smaller git hosting services. This flow works reasonably well. It gets slightly more annoying after the first pull request because you actually have to keep your own local branch up to date.</p>
<p>In theory this also gives some nice discoverability of people working on the project by looking at the forks of the project. In practice this is a bunch of outdated copies of the project by people who have mistaken the fork button for a like button.</p>
<p>From a maintainer point of view this flow also works alright, unless your project starts to grow. For example when postmarketOS was still on Github we ran into the issue that the merge button isn't really useful. Once you have a reasonable volume of  pull requests the branches of those pull requests get outdated quickly meaning they have to be rebased before merging or every change will have an extra merge commit in the history.</p>
<p>In the postmarketOS case it was decided that merge commits are extra noise in the git history we'd like to avoid so we'd need to rebase things, and to properly rebase we have to do it from the command line because Github can't deal at all with conflicts. Rebasing from the command line also gives a lot more flexibility with squashing and having a nice commit message.</p>
<p>The only reason that merge button was used on Github was because Github can't seem to mark the pull request as merged if it isn't done by the button.
The all-knowing button from Github</p>
<p>The old workflow documentation postmarketOS had when Github was used can be read in the wiki history: <a href="https://wiki.postmarketos.org/index.php?title=Merge_Workflow&amp;oldid=3441">https://wiki.postmarketos.org/index.php?title=Merge_Workflow&amp;oldid=3441</a></p>
<p>Now we've moved to Gitlab we're basically dealing with the same issue, we have to mess with the commits before merging so we're always force-pushing to the git fork of the author of the pull request (which they have to enable on the merge request, if they don't we first have to tell them to enable that checkbox) and then finally merge them with the button in the web UI so Gitlab doesn't lose track of what happened.</p>
<h2>The git-send-email flow</h2>
<p>The flow for pull requests in github isn't the original way to make pull requests. Since git was originally written for the development of the Linux kernel it has been designed with the workflow of the kernel in mind. The kernel uses mailing lists.</p>
<p>[insert image of horrified developers here]</p>
<p>The first patch I emailed was with the assistence of <a href="https://git-send-email.io/">https://git-send-email.io/</a>, I needed to learn how to use the email flow because at the time I was working on my very first kernel patch. This was quite a daunting task involing triple-checking everything against the <a href="https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html">patch submission documentation</a> for Linux which describes the easy 16 step process.</p>
<p>Then after the final step the email gets sent out and you wait... for response emails.</p>
<p>Since then I've made contributions to projects hosted on Sourcehut, which also uses the email workflow, and now I also maintain some projects on this platform. For example <a href="https://git.sr.ht/~martijnbraam/megapixels">Megapixels</a>.</p>
<p>This is the workflow for submitting a patch to a project using the email flow:</p>
<ol>
<li>Clone the repository locally</li>
<li>Make your changes on your local checkout</li>
<li>Run git send-email with a ref pointing to one or a range of commits</li>
<li>Get comments as response to the patch as emails, mirrored on the webpage of the mailing list</li>
<li>Fix up your previous mistakes, run git send-email again with the -v2 argument to send an updated version</li>
<li>The maintainer applies the patch from the email.</li>
</ol>
<p>As a maintainer getting the patches like this is quite nice since unless there's a conflict you don't have to merge branches or rebase things, the patches is just ... a patch, it only has the changes from the author, not the full git history.</p>
<p>Also, one thing to note about the process above is that, except for receiving the feedback, it will never touch your mail client. Git does SMTP itself and make sure the emails you send out are up-to-spec so maintainers can apply the changes directly by feeding the email into git am</p>
<p>If your main complaint is that email is horrible to work with, the issue is most likely not email, it's probably your mail client.</p>
<p>One of the other main issues with the email workflow is that you can't just see the full state of the "pull request" because there's no nice pull request page to see what's happening. This is one of the main reasons I like the mailing lists on Sourcehut, the patch view fixes most of the visibility issues, for example this simple patch: <a href="https://lists.sr.ht/~martijnbraam/public-inbox/patches/14382">https://lists.sr.ht/~martijnbraam/public-inbox/patches/14382</a>
The overview of a patch submitted to a Sourcehut mailing list</p>
<p>There you see the patch description in the first block, which is in this case didn't have any extra text added in the git send-email stage, so it only shows a summary of the changes in this patch.</p>
<p>Below that is the actual patch, with the subject of the patch as header and then showing the full commit message below that if there were more lines and then the full diff. This patch can also be exported directly as a .patch file using the link right of the subject.</p>
<p>Finally, below the diff is a comment from Eyal who applied this patch to the development branch and thanked the author; the mailing list will generate a nice threaded view here if there's more discussion.</p>
<p>The block on the right will show the status of the patch, APPLIED in this case and gives some extra tools to get a copy of the full patchset that can be applied using git am</p>
<h2>Conclusion</h2>
<p>I personally prefer the e-mail workflow now, it saves me from keeping branches/forks up to date as with this workflow only diffs are sent around. Also after working in Gitlab for most of the things I do on postmarketOS I really like how quickly sourcehut pages load and that I just can get all info from the patch without clicking on tabs to switch between comments, diffs and commit messages with loading times in between.</p>
<p>Also one nice improvement is that instead of doing half the maintainer flow in the browser by clicking things and half by patching stuff up in my local git branch and force pushing that, it just lets me do everything in the shell and then just send an email back telling the author their patch got merged.</p>
<p>All together people are most likely already used to having all the comments and info emailed to them as notifications, it's just that in the gitlab/hub case it will send you a link to continue on their website and in the sourcehut/email flow case the email is everything you need to continue without ever opening the browser.</p>
</article>


<hr>

<footer>
  <p>
    <a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home">
        <use xlink:href="/static/david/icons2/symbol-defs.svg#icon-home"></use>
      </svg> Accueil</a> •
    <a href="/david/log/" title="Accès au flux RSS"><svg class="icon icon-rss2">
        <use xlink:href="/static/david/icons2/symbol-defs.svg#icon-rss2"></use>
      </svg> Suivre</a> •
    <a href="http://larlet.com" title="Go to my English profile" data-instant><svg class="icon icon-user-tie">
        <use xlink:href="/static/david/icons2/symbol-defs.svg#icon-user-tie"></use>
      </svg> Pro</a> •
    <a href="mailto:david%40larlet.fr" title="Envoyer un courriel"><svg class="icon icon-mail">
        <use xlink:href="/static/david/icons2/symbol-defs.svg#icon-mail"></use>
      </svg> Email</a> •
    <abbr class="nowrap" title="Hébergeur : Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33184162340"><svg class="icon icon-hammer2">
        <use xlink:href="/static/david/icons2/symbol-defs.svg#icon-hammer2"></use>
      </svg> Légal</abbr>
  </p>
  <template id="theme-selector">
      <form>
          <fieldset>
              <legend><svg class="icon icon-brightness-contrast">
                <use xlink:href="/static/david/icons2/symbol-defs.svg#icon-brightness-contrast"></use>
              </svg> Thème</legend>
              <label>
                  <input type="radio" value="auto" name="chosen-color-scheme" checked> Auto
              </label>
              <label>
                  <input type="radio" value="dark" name="chosen-color-scheme"> Foncé
              </label>
              <label>
                  <input type="radio" value="light" name="chosen-color-scheme"> Clair
              </label>
          </fieldset>
      </form>
  </template>
</footer>
<script src="/static/david/js/instantpage-5.1.0.min.js" type="module"></script>
<script>
    function loadThemeForm(templateName) {
        const themeSelectorTemplate = document.querySelector(templateName)
        const form = themeSelectorTemplate.content.firstElementChild
        themeSelectorTemplate.replaceWith(form)

        form.addEventListener('change', (e) => {
            const chosenColorScheme = e.target.value
            localStorage.setItem('theme', chosenColorScheme)
            toggleTheme(chosenColorScheme)
        })

        const selectedTheme = localStorage.getItem('theme')
        if (selectedTheme && selectedTheme !== 'undefined') {
            form.querySelector(`[value="${selectedTheme}"]`).checked = true
        }
    }

    const prefersColorSchemeDark = '(prefers-color-scheme: dark)'
    window.addEventListener('load', () => {
        let hasDarkRules = false
        for (const styleSheet of Array.from(document.styleSheets)) {
            let mediaRules = []
            for (const cssRule of styleSheet.cssRules) {
                if (cssRule.type !== CSSRule.MEDIA_RULE) {
                    continue
                }
                // WARNING: Safari does not have/supports `conditionText`.
                if (cssRule.conditionText) {
                    if (cssRule.conditionText !== prefersColorSchemeDark) {
                        continue
                    }
                } else {
                    if (cssRule.cssText.startsWith(prefersColorSchemeDark)) {
                        continue
                    }
                }
                mediaRules = mediaRules.concat(Array.from(cssRule.cssRules))
            }

            // WARNING: do not try to insert a Rule to a styleSheet you are
            // currently iterating on, otherwise the browser will be stuck
            // in a infinite loop…
            for (const mediaRule of mediaRules) {
                styleSheet.insertRule(mediaRule.cssText)
                hasDarkRules = true
            }
        }
        if (hasDarkRules) {
            loadThemeForm('#theme-selector')
        }
    })
</script>
</body>
</html>