On 29/03/2017 17:59 , Christian Beer wrote: > If the Client/Manager was built from one of the commits above then every > commit in master is part of the history of this version.
That's precisely my point. There's no point in thinking/guessing about what might be part of a given release. That's approach is just bound to fail as you will miss things - things do change over time. One way of doing this manually now might be incomplete tomorrow. One thing is a *fact* though: any time a release is build the *whole* repo state will be the basis for that build, regardless of what you think might play an active role in it. This is simply *not* a matter of opinion. Git is tailored for exactly this purpose, represent a coherent state of a whole source code base with an unambiguous identifier, the SHA1. Thus you only need to know two things in order to build a new release: 1) Decide on the state the whole repo should be in 2) Have a clean repo (no uncommitted changes) #1 can be achieved by either using the already established release branch or by creating a new one. That is, branch it off from master. I described that workflow before. #2 can be achieved by using a dedicated build tree that's not used for development purposes. Alternatively you just (temporarily) "git stash" your local changes away. Cheers, Oliver _______________________________________________ boinc_dev mailing list [email protected] https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
