<div dir="ltr">One other thing:<div><br></div><div> At least on Github, using the button on the site to merge a request always creates a proper merge (not a rebase), so the history won't be straight if we do things that way. I believe the reasoning is that in this way, you have record of who did the merging. </div><div> I am not sure if this holds for Gitlab, but we should look into it, if we want to keep the straight history.</div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Jan 8, 2019 at 10:44 AM Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com">simonpj@microsoft.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div lang="EN-GB">
<div class="gmail-m_228505185310178936WordSection1">
<p class="MsoNormal"><span>I like your notes. I’ll add them.<u></u><u></u></span></p>
<p class="MsoNormal"><span><u></u> <u></u></span></p>
<p class="MsoNormal"><span>I think that ideally<u></u><u></u></span></p>
<ul style="margin-top:0cm" type="disc">
<li class="gmail-m_228505185310178936MsoListParagraph" style="margin-left:0cm"><span>We’d keep a straight-line history for master<u></u><u></u></span></li><li class="gmail-m_228505185310178936MsoListParagraph" style="margin-left:0cm"><span>And hence we have to accept force-push to user branches.<u></u><u></u></span></li><li class="gmail-m_228505185310178936MsoListParagraph" style="margin-left:0cm"><span>Surely we can treat the user branches much as we do HEAD today? That is, always pull before pushing; and only force push if you know that
you have just pulled; and then rebased, squashed or whatever.<u></u><u></u></span></li><li class="gmail-m_228505185310178936MsoListParagraph" style="margin-left:0cm"><span>In any case the common case is that only one person is pushing to a user branch<u></u><u></u></span></li></ul>
<p class="MsoNormal"><span><u></u> <u></u></span></p>
<p class="MsoNormal"><span>It would be good to agree our normal protocol here.<u></u><u></u></span></p>
<p class="MsoNormal"><span><br>
Simon<u></u><u></u></span></p>
<p class="MsoNormal"><span><u></u> <u></u></span></p>
<div style="border-top:none;border-right:none;border-bottom:none;border-left:1.5pt solid blue;padding:0cm 0cm 0cm 4pt">
<div>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> Iavor Diatchki <<a href="mailto:iavor.diatchki@gmail.com" target="_blank">iavor.diatchki@gmail.com</a>>
<br>
<b>Sent:</b> 08 January 2019 18:10<br>
<b>To:</b> Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>><br>
<b>Cc:</b> ghc-devs <<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a>><br>
<b>Subject:</b> Re: Gitlab notes<u></u><u></u></span></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">Hello,<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">a couple of notes about the use of `git` here, which are probably more relevant if you collaborate with other people on a branch:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"> 1. In general, I think that the model is that you create the branch when you start working on something, and you don't really need<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> to do a merge request until later, when you are ready for review.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"> 2. when you are pushing your branch to the remote (i.e., git-lab), you probably want to say that you branch should "track" the remote by providing the `-u` flag:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"> git push -u origin wip/spj-wibbles<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> This makes `git` remember the association between your local branch, and the one that lives on git-lab, so later if you can just say `git pull` and `git push` and<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> `git` will know what remote you are talking about.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"> 3. You shouldn't really force push to a remote, especially if you are collaborating with other people.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> If you want to integrate your changes with the current HEAD (aka `master`), you may want to merge it into your working branch.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"> 4. Once you are finished with the changes and they are ready for review, you can prepare them by doing any of these as needed:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> a) rebasing to a more relevant starting point (perhaps even the current `master`),<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> b) squashing commits as necessary---for simple changes, one should probably end up with a single commit.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> Since those "rewrite history", you are essentially making a new branch, and you could submit *that* for review. Alternatively,<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> you could reuse your working branch (a bit of a hack), and then you'd have to "force" push.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"> 5. When everything is ready for review, then you create the MR for the appropriate branch (either the new review one, or<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> your working one, if you chose to reuse it)<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"> 6. You can continue evolving the branch as usual based on feedback from the reviews.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"> 7. Once all the reviewers are happy, you can prepare the branch for merging with `master` as in 4.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"> I believe in the past GHC has tried to maintain a "straight line" history model, where changes are always made<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> on top of the current `master` branch (i.e., there are no visible merges). If we are still doing that, then you'd<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> have to rebase your reviewed changes on top of `master` in preparation for merging.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I didn't add this to the wiki, as they are subjective, but they reflect my understanding of how systems like `git-lab`<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">are intended to be used.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">-Iavor<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Tue, Jan 8, 2019 at 8:30 AM Simon Peyton Jones via ghc-devs <<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0cm 0cm 0cm 6pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<p class="MsoNormal">Friends<u></u><u></u></p>
<p class="MsoNormal">I’ve added a Wiki page to summarise things I’ve learned about Gitlab. Please do correct any errors I’ve made!<u></u><u></u></p>
<p class="MsoNormal"><a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fghc.haskell.org%2Ftrac%2Fghc%2Fwiki%2FWorkingConventions%2FGitLabSPJ&data=02%7C01%7Csimonpj%40microsoft.com%7C0f8493cdde724d53f26b08d675948b0f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636825678183117730&sdata=uwK3NS%2BkQ9RSPRSdzxW1Xm19DsKHlQp2GzV3P6OSODU%3D&reserved=0" target="_blank">https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/GitLabSPJ</a><u></u><u></u></p>
<p class="MsoNormal">Thanks<u></u><u></u></p>
<p class="MsoNormal">Simon<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal">_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=02%7C01%7Csimonpj%40microsoft.com%7C0f8493cdde724d53f26b08d675948b0f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636825678183127722&sdata=3GEN3BxHQzF6s6gv43QYpUu06cjsTxKvOJNgUhdNGxA%3D&reserved=0" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><u></u><u></u></p>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote></div>