Currently Online

Latest Posts

Topic: Move Widelands to GitHub

GunChleoc
Avatar
Joined: 2013-10-07, 15:56
Posts: 3057
Ranking
One Elder of Players
Location: RenderedRect
Posted at: 2019-09-15, 11:56

kaputtnik wrote:

Thanks GunChleoc, that worked. Now i have one directory in which i change the branches with git checkout. This seems to me the main difference to bazaar, where you have each branch in its own directory, whereas with git you have only ONE directory (except the workflow described by Nordfriese). Is this true?

Yes, this is true.

The thing with linking other documentation is fine, but i think we should at least provide a full working example. If a new developer want to propose a change of one line in a lua file and he has no experience with git, he won't do that (propose the line change) if he has to read a lot of documentation on different sites, imho.

We should definitely go over the documentation again once we have established our workflow. I have already added the instructions for the workflow that you just used.


Busy indexing nil values

Top Quote
Nordfriese
Avatar
Joined: 2017-01-17, 18:07
Posts: 481
Ranking
Tribe Member
Location: 0x55555d3a34c0
Posted at: 2019-09-15, 13:47

Will launchpad merge requests also be imported automatically or do I need to manually open pull requests for branches I had in review?


Top Quote
GunChleoc
Avatar
Joined: 2013-10-07, 15:56
Posts: 3057
Ranking
One Elder of Players
Location: RenderedRect
Posted at: 2019-09-15, 16:23

You will have to create new pull requests. If you still need to access the discussion on Launchpad, I have linked the branches in the first post of this thread, and you can still access the deactivated merge requests via their branches.


Busy indexing nil values

Top Quote
stonerl
Avatar
Joined: 2018-07-30, 00:03
Posts: 221
Ranking
Widelands-Forum-Junkie
Location: Earth
Posted at: 2019-09-15, 16:49

@hessenfarmer if you use git just with GitHub. Give the official Github Desktop tool a try.


Top Quote
hessenfarmer
Avatar
Joined: 2014-12-11, 23:16
Posts: 739
Ranking
One Elder of Players
Location: Bavaria
Posted at: 2019-09-15, 19:59

ok I Think I am getting there. I did a test commit to my fork at the balancing branch.
I cloned my branch and then I added upstream as remote. at commit I created the remote branch in my fork and pushed it. If this is not correct please tell me.
However I realized that all appveyor builds of the merged branches have gone. So we need to setup a windows integration environment soon, som that f.e. people like King of nowhere get test builds to test changes. Although I could build myself I appreciated the convenience of appveyor as well.


Top Quote
GunChleoc
Avatar
Joined: 2013-10-07, 15:56
Posts: 3057
Ranking
One Elder of Players
Location: RenderedRect
Posted at: 2019-09-15, 20:09

Very glad to hear that you are figuring it out. Your strategy is good face-grin.png face-grin.png

Please let us know if you need any more help, and if you have any ideas about improving the instructions in the wiki.

AppVeyor and Travis are already up and running. I have configured them to run a build on Pull Requests, just like we used to have for Merge Requests. In addition to that, they will create a build each time somebody pushes to a branch in https://github.com/widelands/widelands

Since I am migrating a lot of branches right now, we have a bit of a backlog, but things should be back to normal for Travis & AppVeyor after a week or so. I'm already pushing most of my branches to my fork rather than the official one to reduce the load on the builds.

Travis has a separate tab for Pull requests: https://travis-ci.org/widelands/widelands/pull_requests

And the branch builds are listed here: https://travis-ci.org/widelands/widelands/branches

AppVeyor ist unchanged, with branches and pull requests on one page: https://ci.appveyor.com/project/widelands-dev/widelands/history


Busy indexing nil values

Top Quote
stonerl
Avatar
Joined: 2018-07-30, 00:03
Posts: 221
Ranking
Widelands-Forum-Junkie
Location: Earth
Posted at: 2019-09-17, 11:37

How do we want to version builds from GitHub?

The bzr based builds looked like this:

bzr<revison>[<branch>]

e.g.

bzr6169[make-widelands-greater]

How do we want to use this with git? Currently, it looks like this:

git-unofficial-<hash-short>
git-unofficial-959ce7a578

There are at least 3 possible schemes

1: git<hash-short>[<branch>]
2: git<hash-short=5>[<branch>]
3: git<revision>[<branch>]

This would look like this:

1: git959ce7a578[adapt-build_app.sh-for-GitHub]
2: git959ce[adapt-build_app.sh-for-GitHub]
3: git24200[adapt-build_app.sh-for-GitHub]

What do you think?


Top Quote
GunChleoc
Avatar
Joined: 2013-10-07, 15:56
Posts: 3057
Ranking
One Elder of Players
Location: RenderedRect
Posted at: 2019-09-17, 12:52

I'd go for 2 or 3. If we use the hash, keep the dash, because hashed can start with a letter.

The revision looks like it's sequential, which is more intuitive - can it also be used to easily find the commit both in the GitHub UI and in the git client?


Busy indexing nil values

Top Quote
stonerl
Avatar
Joined: 2018-07-30, 00:03
Posts: 221
Ranking
Widelands-Forum-Junkie
Location: Earth
Posted at: 2019-09-17, 13:35

GunChleoc wrote:

The revision looks like it's sequential, which is more intuitive - can it also be used to easily find the commit both in the GitHub UI and in the git client?

You get this by using: git rev-list --count HEAD It just counts the number of commits. To get to a specific revision one has to subtract the rev-list count of a specific version from the current HEAD count. I don't know how intuitive this is, though. For that matter I would go with option 2.

git-<hash-short=5>[<branch>]
git-959ce[adapt-build_app.sh-for-GitHub]

Another way could be, having both. This references the commit and a sequential number so it is easy to so how many commits versions differ from each other.

git<revision>[<hash-short=5>@<branch>]
git24200[959ce@adapt-build_app.sh-for-GitHub]

Top Quote
GunChleoc
Avatar
Joined: 2013-10-07, 15:56
Posts: 3057
Ranking
One Elder of Players
Location: RenderedRect
Posted at: 2019-09-17, 13:49

Having both will make the string too long in the UI. Let's go with option 2 with the dash face-smile.png

On another note, most of the issues in Widelands-media were also issues in Widelands itself, so I moved the few remaining ones to the Widelands bug tracker. They all carry the media label.


Busy indexing nil values

Top Quote