Re: [git-users] Git branch merge strategies

2017-07-26 Thread Igor Djordjevic
Hi Mark, On Thursday, July 27, 2017 at 12:48:25 AM UTC+2, Mark Waite wrote: > > Yes, your simplification expresses what I was trying to achieve. > Good, then we understood each other, thanks for confirming :) > I specifically merged from master to one so that one could be tested with > the

Re: [git-users] Git branch merge strategies

2017-07-26 Thread Mark Waite
Yes, your simplification expresses what I was trying to achieve. I specifically merged from master to one so that one could be tested with the merge from master. The subsequent merge from one to master was to have master include a commit which shows one merged into it. Same pattern for master

Re: [git-users] Git branch merge strategies

2017-07-26 Thread Igor Djordjevic
Hi JNickVA, On Wednesday, July 26, 2017 at 8:44:13 PM UTC+2, JNickVA wrote: > 3. and 4. I don't even have enough information to know the state of the > master when each of the 2 branches were created > What do you mean here? Isn`t Git history showing you the exact state of "master" when each

Re: [git-users] Git branch merge strategies

2017-07-26 Thread Igor Djordjevic
Hi Mark, On Tuesday, July 25, 2017 at 2:58:21 PM UTC+2, Mark Waite wrote: > > You might consider a series of steps to perform the merge. Some of the > steps might include: > >1. Merge from master to branch one so that the diffs between branch >one and master are only changes on branch

Re: [git-users] Git branch merge strategies

2017-07-26 Thread JNickVA
Michael, 1. At this stage I am not sure that what is in production is represented by the master branch, and if it was at one time, when that might have been. 2. I am taking over the project from a group of developers who have been working remotely with little ort no supervision. I have 2 weeks