Re: [escet-dev] GitLab

["Hofkamp, A.T." <A.T.Hofkamp@xxxxxx>]

Hai,

> Seems it is not yet possible to change the default names: https://gitlab.com/gitlab-org/gitlab/-/issues/21243

Pity.

> We can change the name manually when we create a branch, but I would probably forget that most of the time.

The alternative is not to have strict branch naming rules.

If you use gitlab to create the branch, you need to first visit gitlab, find the issue, click a button, then pull or fetch with a possible fast-forward, select the branch again, checkout, and start doing things.

I typically just make a new branch label, switch to it, and and start hacking.

> Personally I don't need autocomplete.

Otherwise you'd have the same problem as me, wouldn't you? ��

> A benefit of starting with the number is that branches can be sorted on the numbers (more or less).

You mean most tools fail to have configurable sort criteria.

I don't know about you, but I prefer "add-synthesis-tool" above "242354" any day. To me the numbers are mostly noise, except in rare occasions where you have to link a branch back to an issue. It's also somewhat overkill, as every commit is supposed to have an  issue number as I understood (which I am definitely also going to forget or not know at the time, no idea yet how to manage that).

> all in the same environment as where development itself takes place.

I see Linux desktop as my dev environment. I also use it 100% of the time.

> original post about GitFlow: "We consider origin/master to be the main branch where the source code of HEAD always reflects a production-ready state."

I know. I have read it in the past.

Like I said, they renamed "releases" branch to "master".

That quote only states what they did. It does not explain why they violate standard git convention of master being the bleeding edge development branch. Why is the thing named "develop" rather than "master"?

I understand feature branches and release branches and fix branches. It's a heavy model. We may need all those branch types at some point.

So yeah, something more heavy than Github flow is good.

> Our Oomph setup will check out 'develop' by default, so that will be our 'default' branch in that sense

Why do you start discussions about a model if the ship already sailed?

> I'm not sure if we can change the default to 'develop' in GitLab

There are default branches and protected branches that you can configure afaik.

> GitFlow seems rather standard these days and would be familiar to many contributors.

GitFlow is heavily outnumbered by Github flow or even simpler "do everything in master" would be my guess. It heavily depends on the kind of contributors.

GitFlow is however the only more-or-less common model that's more complete than the Github model though as far as I know, so we have a singleton set to choose from ��

> Note however, that the blog post talks about the possibility of sub teams, which share work, but don't push that to 'origin' (yet). It also talks of feature branches that exist only locally on a developers PC and not on 'origin'.

Makes sense, with a heavy model you aim to cover all possible needs. I don't think we'll do sub-teams anywhere near soon.

I typically use "project" as alias for the project repository rather than "origin", to keep things consistent between github projects, local projects, and now gitflow-ish projects.

---

From: escet-dev-bounces@xxxxxxxxxxx <escet-dev-bounces@xxxxxxxxxxx> on behalf of Dennis Hendriks <dh_tue@xxxxxxxxxxx>
Sent: Thursday, October 22, 2020 17:51
To: escet developer discussions <escet-dev@xxxxxxxxxxx>
Subject: Re: [escet-dev] GitLab

 

> According to https://nvie.com/posts/a-successful-git-branching-model/, the original post about GitFlow [...]

Note however, that the blog post talks about the possibility of sub teams, which share work, but don't push that to 'origin' (yet). It also talks of feature branches that exist only locally on a developers PC and not on 'origin'. This is in principle not allowed at the Eclipse Foundation. Don't develop for a long time locally and/or with multiple people outside of the view of the community. The Eclipse Foundation principles require that we are open and transparent. As such, commit and push often to GitLab, which is 'origin', such that the community can see what is being worked on. Also, collaborate together on branches that are visible in GitLab.

Dennis

---

Van: escet-dev-bounces@xxxxxxxxxxx <escet-dev-bounces@xxxxxxxxxxx> namens Dennis Hendriks <dh_tue@xxxxxxxxxxx>
Verzonden: donderdag 22 oktober 2020 17:32
Aan: escet developer discussions <escet-dev@xxxxxxxxxxx>
Onderwerp: Re: [escet-dev] GitLab

 

> [...] As such, I'd prefer the issue number at the end, don't know if that's possible.

Seems it is not yet possible to change the default names: https://gitlab.com/gitlab-org/gitlab/-/issues/21243

We can change the name manually when we create a branch, but I would probably forget that most of the time.

Personally I don't need autocomplete. I use the Eclipse IDE with EGit for 99.9% of all Git related stuff, not a console. It is then very easy to switch branches, commit, push, pull, see history, look at diffs, etc, all in the same environment as where development itself takes place. Took a little bit of time to get used to the first time, but I wouldn't want to use a separate application anymore. Some super advanced stuff is not possible, but that's the stuff one hardly ever uses, and for that you can obviously still use the command line.

A benefit of starting with the number is that branches can be sorted on the numbers (more or less).

> Gitflow will likely do all we want, the one problem I have with it is that it breaks standard git semantics of "master". For no good reason, they renamed "master" to "develop", and renamed "releases" to "master" to confuse everybody. Why?

According to https://nvie.com/posts/a-successful-git-branching-model/, the original post about GitFlow: "We consider origin/master to be the main branch where the source code of HEAD always reflects a production-ready state." I should probably use this to refer to GitFlow instead of the other link I used (which was Google's first hit). The original post has more explanation and explains the reasoning behind the flow.

Our Oomph setup will check out 'develop' by default, so that will be our 'default' branch in that sense, and we can make multiple streams for master/develop/etc branches.

I'm not sure if we can change the default to 'develop' in GitLab, as otherwise it would be very irritating. We may have to ask the admin to do that if we can't do it.

We could opt for GitHub Flow (https://guides.github.com/introduction/flow/), but that is just master and branches, which seems too simple. GitFlow seems rather standard these days and would be familiar to many contributors.

Dennis

---

Van: escet-dev-bounces@xxxxxxxxxxx <escet-dev-bounces@xxxxxxxxxxx> namens Hofkamp, A.T. <A.T.Hofkamp@xxxxxx>
Verzonden: donderdag 22 oktober 2020 16:13
Aan: escet developer discussions <escet-dev@xxxxxxxxxxx>
Onderwerp: Re: [escet-dev] GitLab

 

> I suggest the following for milestones:

Seems fine.

Epics are indeed topic oriented as far as I know. Mostly anything bigger than a few issues, where you need an overview ticket about purpose, plans, and progress. Never worked with proper Epics though, until now I just used a ticket labeled "[epic] <topic>".

> I suggest the following for issues:

Not many surprises, 2 points:

•  "... it will create a branch named '2-test'."   The numeric prefix breaks auto-completion at the command-line, since at the same point you can also use a commit hash, and there are a zillion commits that start with a 2. If you type "2-", autocompletion works, but we'll soon have more than 10 or 100 issues. As such, I'd prefer the issue number at the end, don't know if that's possible.
• Gitflow will likely do all we want, the one problem I have with it is that it breaks standard git semantics of "master". For no good reason, they renamed "master" to "develop", and renamed "releases" to "master" to confuse everybody. Why?

---

From: escet-dev-bounces@xxxxxxxxxxx <escet-dev-bounces@xxxxxxxxxxx> on behalf of Dennis Hendriks <dh_tue@xxxxxxxxxxx>
Sent: Monday, October 19, 2020 13:02
To: escet developer discussions <escet-dev@xxxxxxxxxxx>
Subject: [escet-dev] GitLab

 

Hi all,

In another discussion, Albert mentioned:

> [...] should we discuss gitlab configuration?

> Issue tags and milestones at least I think, and probably branch usage/names/conventions?

> [...]

> In general, I think less is more here.

I suggest the following for milestones:

• Create a milestone for every release. I created one for Release 0.1.
• Associate every issue with the release milestone where we fix/address it. This way, we have an overview for the release log for a release. Also, we see what work is still planned for a release.

We have both epics and milestones. Both seem to group issues. Epics seem to be meant to group by functionality while milestones seem more focussed on what you address/finish/release together. You could thus have funcionality in an epic that you release partly as part of one milestone and the rest as part of a next milestone. Maybe if we later have releases with multiple topics (groups of functionality) epics may become handy as well.

I suggest the following for issues:

• Create an issue for everything that we work on.
• Keep issues relatively small. This keeps merging easier as we will merge often. Also, it makes reviewing easier, as it will not be too much code.
• Always work in a branch for the issue.
• Let GitLab create the branch for the issue. For an issue with number #2 named 'Test', it will create a branch named '2-test'. So that includes the issue number.
• Adopt GitFlow, see https://datasift.github.io/gitflow/IntroducingGitFlow.html

For commits:

• The first line must be a short single line summary of max 72 characters I think, as is the Git standard.
• Prefix the first line with the issue number, e.g. '#1 commit summary', to link the commit to the issue.
• Adhere to Eclipse requirements, see https://www.eclipse.org/projects/handbook/#resources-commit

These are my first thoughts. Let me know what you think about them and whether you have other ideas.

Dennis