Gitlab notes

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Gitlab notes

GHC - devs mailing list

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

Thanks

Simon


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Gitlab notes

Iavor Diatchki
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 <[hidden email]> 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

Thanks

Simon

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

RE: Gitlab notes

GHC - devs mailing list

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 <[hidden email]>
Sent: 08 January 2019 18:10
To: Simon Peyton Jones <[hidden email]>
Cc: ghc-devs <[hidden email]>
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 <[hidden email]> 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

Thanks

Simon

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Gitlab notes

Iavor Diatchki
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 <[hidden email]> 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 <[hidden email]>
Sent: 08 January 2019 18:10
To: Simon Peyton Jones <[hidden email]>
Cc: ghc-devs <[hidden email]>
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 <[hidden email]> 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

Thanks

Simon

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Gitlab notes

Steven Shaw
On Wed, 9 Jan 2019 at 05:07, Iavor Diatchki <[hidden email]> wrote:
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.

For GitLab, you can configure 'Fast Forward Merges'. This will then only allow fast forward merges from the UI.


I'm not sure if that's been configured for https://gitlab.haskell.org/ghc/ghc/ as I don't have permission to look at that.

GitHub also has various options for merging PRs. You might have worked on a project that only allowed merge commits but you can enable/disable merge-commit, squash-commits and rebase-commits on GitHub.

Cheers,
Steve.

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Gitlab notes

Ben Gamari-2
In reply to this post by Iavor Diatchki
Iavor Diatchki <[hidden email]> writes:

> 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 agree with Simon that the best model for a project like GHC is to
maintain a linear history. Bisection becomes incredibly difficult otherwise.

>     I am not sure if this holds for Gitlab, but we should look into it, if
> we want to keep the straight history.
>
Our GitLab instance is configured to only allow fast-forward merges.
GitLab prompts you to rebase if this isn't possible (even allowing
trivial rebases to be done via the web interface).

- Ben

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Gitlab notes

Alec Theriault
Hi all,

Could someone sketch out somewhere roughly what the steps are two getting something merged on Gitlab?
Here’s my current understanding:

1. You’ve implemented something and open a MR, CI starts running
2. Looking both at passing CI and at your code, someone with commit bits eventually decides to accept the MR
3. You rebase onto latest master (since we want a linear git history)
4. CI passes again, and your MR ends up in master

However, if someone else finishes step 4 after you start step 3, you’ll need to rebase again (and CI needs to run again), right?
IIRC, Rust solves this with a merge queue (where CI rebases and tests each dequeued PRs, one at a time, merging into master only on successful CI).

I’m all a bit muddled and I’d prefer not to waste the very helpful CI resources. How are things supposed to work?

Thanks,

Alec

> On Jan 8, 2019, at 8:51 PM, Ben Gamari <[hidden email]> wrote:
>
> Iavor Diatchki <[hidden email]> writes:
>
>> 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 agree with Simon that the best model for a project like GHC is to
> maintain a linear history. Bisection becomes incredibly difficult otherwise.
>
>>    I am not sure if this holds for Gitlab, but we should look into it, if
>> we want to keep the straight history.
>>
> Our GitLab instance is configured to only allow fast-forward merges.
> GitLab prompts you to rebase if this isn't possible (even allowing
> trivial rebases to be done via the web interface).
>
> - Ben
> _______________________________________________
> ghc-devs mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs