Re: integration and master divergence

On Jul 18, 2012, at 1:19 PM, Chuck Hill wrote:

> Hi Kieran,
> 
> Can you clarify something for me:
> 
> 
> On 2012-07-18, at 1:10 PM, Kieran Kelleher wrote:
> 
>> Good point, nevertheless, it is just a workflow. Branches and tags are very similar in the sense that they are both generally just "post-it note" references to commits in the object graph, however it is easier for less adventurous users who want to work with source code and still want stable source to have a stable "master" since checking out a tag (detached HEAD and warning message) is not a good user experience, especially for those not living on bleeding edge.
>> 
>> So, IMHO, we can keep everyone happy by continuing with two branches (just labels on commits) and someone (anyone with commit access) can periodically make a release candidate branch based on master, integrate one-month+ old integration, push it and announce the release candidate via pull request of it to master.
> 
> What about the case where that point in time had a bug that was fixed in a later commit, perhaps the next week?  Merging a point in time does not guarantee a working version, just that any bugs in that merge were fixed in a subsequent commit.  Addressing that seems to lead us back to cherry picking the commit.  What am I missing?
> 
> 
> Chuck

Just another branch of course! We shall call it hotfix :3

http://nvie.com/posts/a-successful-git-branching-model/

See, everything can be fixed by a new branch... except the part where it takes half my day managing them all ;-)

Ramsey


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/