Gitlab notes

Tue Jan 8 19:07:30 UTC 2019

One other thing:

    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.
    I am not sure if this holds for Gitlab, but we should look into it, if
we want to keep the straight history.

On Tue, Jan 8, 2019 at 10:44 AM Simon Peyton Jones <simonpj at microsoft.com>
wrote:

> I like your notes.  I’ll add them.
>
>
>
> I think that ideally
>
>    - We’d keep a straight-line history for master
>    - And hence we have to accept force-push to user branches.
>    - 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.
>    - In any case the common case is that only one person is pushing to a
>    user branch
>
>
>
> It would be good to agree our normal protocol here.
>
>
> Simon
>
>
>
> *From:* Iavor Diatchki <iavor.diatchki at gmail.com>
> *Sent:* 08 January 2019 18:10
> *To:* Simon Peyton Jones <simonpj at microsoft.com>
> *Cc:* ghc-devs <ghc-devs at haskell.org>
> *Subject:* Re: Gitlab notes
>
>
>
> Hello,
>
>
>
> a couple of notes about the use of `git` here, which are probably more
> relevant if you collaborate with other people on a branch:
>
>
>
>    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
>
>       to do a merge request until later, when you are ready for review.
>
>
>
>    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:
>
>
>
>        git push -u origin wip/spj-wibbles
>
>
>
>      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
>
>      `git` will know what remote you are talking about.
>
>
>
>     3. You shouldn't really force push to a remote, especially if you are
> collaborating with other people.
>
>        If you want to integrate your changes with the current HEAD (aka
> `master`), you may want to merge it into your working branch.
>
>
>
>     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:
>
>         a)  rebasing to a more relevant starting point (perhaps even the
> current `master`),
>
>         b) squashing commits as necessary---for simple changes, one should
> probably end up with a single commit.
>
>       Since those "rewrite history", you are essentially making a new
> branch, and you could submit *that* for review.  Alternatively,
>
>       you could reuse your working branch (a bit of a hack), and then
> you'd have to "force" push.
>
>
>
>     5. When everything is ready for review, then you create the MR for the
> appropriate branch (either the new review one, or
>
>         your working one, if you chose to reuse it)
>
>
>
>      6. You can continue evolving the branch as usual based on feedback
> from the reviews.
>
>
>
>      7. Once all the reviewers are happy, you can prepare the branch for
> merging with `master` as in 4.
>
>
>
>          I believe in the past GHC has tried to maintain a "straight line"
> history model, where changes are always made
>
>          on top of the current `master` branch (i.e., there are no visible
> merges).  If we are still doing that, then you'd
>
>          have to rebase your reviewed changes on top of `master` in
> preparation for merging.
>
>
>
> I didn't add this to the wiki, as they are subjective, but they reflect my
> understanding of how systems like `git-lab`
>
> are intended to be used.
>
>
>
> -Iavor
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Tue, Jan 8, 2019 at 8:30 AM Simon Peyton Jones via ghc-devs <
> ghc-devs at haskell.org> wrote:
>
> Friends
>
> I’ve added a Wiki page to summarise things I’ve learned about Gitlab.
> Please do correct any errors I’ve made!
>
> https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/GitLabSPJ
> <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>
>
> Thanks
>
> Simon
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> <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>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190108/e32ef45c/attachment.html>