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.diatc...@gmail.com>
Sent: 08 January 2019 18:10
To: Simon Peyton Jones <simo...@microsoft.com>
Cc: ghc-devs <ghc-devs@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@haskell.org<mailto:ghc-devs@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@haskell.org<mailto:ghc-devs@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>
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
