home
products
contribute
download
documentation
forum
Home
Forums
New posts
Search forums
What's new
New posts
All posts
Latest activity
Members
Registered members
Current visitors
Donate
Log in
Register
What's new
Search
Search
Search titles only
By:
New posts
Search forums
Search titles only
By:
Menu
Log in
Register
Navigation
Install the app
Install
More options
Contact us
Close Menu
Forums
General Forums
News and Announcements
MediaPortal 1.2.1 final released!
Contact us
RSS
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="Oxan" data-source="post: 807153" data-attributes="member: 97484"><p><strong>Re: AW: MediaPortal 1.2.1 final released!</strong></p><p></p><p></p><p>With your build system it should be quite easy to integrate that. Just run git.exe symbolic-ref HEAD and put the output of that somewhere in a global file. Maybe strip the refs/heads/ part when printing it in the logs, but that's also quite easy. Given that you already use batch scripts for building it shouldn't have been much work. </p><p></p><p>Yeah, I saw that and that was the main reason for my comment. I don't really get why all these tricks are done here. It seems to be like git describe but then only to follow the branch line on the first parent of the merge. This shouldn't be really necessary: not only is the order of parents in a merge not guaranteed afaik, I also can't think of a case where searching all ancestors would lead into a problem. The current code will probably go wrong when you branch off 1.2.0, then do some commits and then merge 1.2.1. It will use the 1.2.0 tag instead of the 1.2.1, which your branch is really based upon. (Some might argue that rebasing is better in this scenario and on some level I agree with that, but that isn't always an option for long-living branches). </p><p></p><p></p><p>Sure, that's true for your builds. But consider this scenario a not very experienced (non-MP) developer who clones the git repository, does some changes on his master branch, and sees that something apparantly totally unrelated is broken (because of his changes but he doesn't know that). He posts the logs to the MP forum, in which is only the branch name (master), so the support people think it's a build from the official repository. If you add the commit hash to the logs, they can see that it's a local build with changes and explain to him that he should use a build from official sources if he wants support. </p><p>One of the things that usually happen when you switch to a distributed VCS is that a lot more people are going to use local builds. (Here, I'm one of them. Now do I know that you can't support my local builds and I should try the offical builds when reporting bugs, but there are a lot of people who don't).</p></blockquote><p></p>
[QUOTE="Oxan, post: 807153, member: 97484"] [b]Re: AW: MediaPortal 1.2.1 final released![/b] With your build system it should be quite easy to integrate that. Just run git.exe symbolic-ref HEAD and put the output of that somewhere in a global file. Maybe strip the refs/heads/ part when printing it in the logs, but that's also quite easy. Given that you already use batch scripts for building it shouldn't have been much work. Yeah, I saw that and that was the main reason for my comment. I don't really get why all these tricks are done here. It seems to be like git describe but then only to follow the branch line on the first parent of the merge. This shouldn't be really necessary: not only is the order of parents in a merge not guaranteed afaik, I also can't think of a case where searching all ancestors would lead into a problem. The current code will probably go wrong when you branch off 1.2.0, then do some commits and then merge 1.2.1. It will use the 1.2.0 tag instead of the 1.2.1, which your branch is really based upon. (Some might argue that rebasing is better in this scenario and on some level I agree with that, but that isn't always an option for long-living branches). Sure, that's true for your builds. But consider this scenario a not very experienced (non-MP) developer who clones the git repository, does some changes on his master branch, and sees that something apparantly totally unrelated is broken (because of his changes but he doesn't know that). He posts the logs to the MP forum, in which is only the branch name (master), so the support people think it's a build from the official repository. If you add the commit hash to the logs, they can see that it's a local build with changes and explain to him that he should use a build from official sources if he wants support. One of the things that usually happen when you switch to a distributed VCS is that a lot more people are going to use local builds. (Here, I'm one of them. Now do I know that you can't support my local builds and I should try the offical builds when reporting bugs, but there are a lot of people who don't). [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
General Forums
News and Announcements
MediaPortal 1.2.1 final released!
Contact us
RSS
Top
Bottom
