Topic: Move Widelands to GitHub

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

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

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

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 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