easier way to keep CHANGES up to date

Discussions for core devs and contributors. Read only for normal forum members to keep the noise low

easier way to keep CHANGES up to date

Postby NateS » Sun Jan 26, 2014 12:31 pm

https://coderwall.com/p/5cv5lg

TLDR; we add #changes (or whatever tag) to a commit so we can automate generating CHANGES.

The build server could generate CHANGES. What do you say, oh master build server guru Mario? :mrgreen:

Note git uses the part of a commit message as the commit title. When committing you should write a short title, then two newlines, then more descriptive text if you think it's needed. The #changes would go somewhere after the two newlines.

Also a GitHub tip, you can use "closes #1234" to have your commit close an issue or PR (which are actually the same thing) on GitHub. You can also use "#1245" to reference an issue, which so your commit shows up on that issue without closing it.
NateS
 
Posts: 1980
Joined: Fri Nov 12, 2010 11:08 am

Re: easier way to keep CHANGES up to date

Postby NateS » Tue Jan 28, 2014 11:27 pm

Code: Select all
git log --pretty=format:'<li><a href="http://github.com/libgdx/libgdx/commit/%H">%s</a><br>%b</li>' | grep '#changes'
NateS
 
Posts: 1980
Joined: Fri Nov 12, 2010 11:08 am

Re: easier way to keep CHANGES up to date

Postby jrenner » Sat Feb 15, 2014 4:03 am

Well the problem with CHANGES is that we sometimes forget to add changes to it. I think we would still forget to add the #changes line to the commit message. Also, new comitters are not likely to know they should be adding this to the commit message.
Superior Tactics - tactical spaceship battles RTS
Google Play: https://play.google.com/store/apps/deta ... r.superior
jrenner
 
Posts: 520
Joined: Sun Apr 14, 2013 5:09 am

Re: easier way to keep CHANGES up to date

Postby NateS » Thu Feb 20, 2014 3:42 am

Aye, it is mostly for us to more easily add changes, should we remember when we type the git log message.

Mario reports he doesn't want to dork with the build. We could still use #changes at the end of a release, but without generating a changes webpage from the git log there isn't a place for people to look for why their stuff is broken. That plus the lack of enthusiasm in this thread, I guess the idea dies.
NateS
 
Posts: 1980
Joined: Fri Nov 12, 2010 11:08 am


Return to Libgdx Development

Who is online

Users browsing this forum: No registered users and 0 guests