Re: Xcode git updates
Re: Xcode git updates
- Subject: Re: Xcode git updates
- From: "Pelaia II, Tom" <email@hidden>
- Date: Fri, 15 Apr 2011 08:38:53 -0400
- Acceptlanguage: en-US
- Thread-topic: Xcode git updates
Thank you for the feedback and suggestions. I am new to Git coming from Subversion experience. I want to learn to do it the right way and will follow your suggestions.
It just seems to me that Xcode is making things more difficult than necessary. Why can't it fetch from a remote repository and then display the files that have changed? Also, I find myself moving back and forth between the project and organizer too much. The SCM functionality needs to be fully functional in one place or both.
Thanks,
Tom
On Apr 15, 2011, at 5:28 AM, Rory O'Bryan wrote:
> I found the same problem with Xcode crashing if you switch branches with a project open. I think GIT is completely clearing and replacing your project folder when you switch branches so it's not too surprising that it's best done with the project closed. Xcode should probably force a project to close rather than crashing.
>
> You haven't outlined exactly how your project team is set-up, but maybe you are still using an "SVN mindset" rather that embracing GITs distributed model. The idea with GIT is that you can create branches liberally whenever you need to work on a feature or fix, and then merge them back into a main branch when they are finished. (and many other more complicated, distributed workflows.)
>
> If you've essentially got one central trunk with multiple developers "checking out" and "checking in" their changes many times a day then you're probably doing it wrong. You may find a few more branches on the central repository will help make things flow better. If there are two of you working on the project you should probably have at least three branches on the central repository, yours, theirs, and the master branch. Even better you'd probably have many more branches that represent features and fixes rather than personal branches. (I'm assuming the central repository is acting as a backup solution here as well.)
>
> Xcode doesn't make this easy for you but once set-up I found multiple branches pushing and pulling to a central repository works fine, search the mailing list for "Xcode + GIT (Part 4)" for some setup details.
>
> I found the "Pro GIt" online book really helpful in getting my brain into the GIT mindset. (Apologies if you know all this already and are happily embracing all of GITs wonders but just wish Xcode did things a bit different !!)
>
> I think Xcode causes confusion by trying to make GIT look a bit too much like SVN and frustrating people when it doesn't always make sense.
>
> On 14 Apr 2011, at 14:55, Pelaia II, Tom wrote:
>
>> I am using the two branch technique you proposed as it seems to work, but Xcode is not making it easy for me. It crashes when I switch branches unless I close the project which just adds to the overhead. Here are the steps necessary to work with Git and a remote branch in Xcode assuming you have two local branches (master tied to the remote and working which is strictly local):
>>
>> - Open Organizer and switch to view repositories to verify that you are working in the "working" branch
>> - Open your project
>> - Modify code and commit changes
>> - Close your project
>> - Use Organizer to switch branch to "master"
>> - Open your project
>> - Merge changes from the "working" branch with a perpetual conflict on xib files that have ever been modified since branching
>> - Push changes to the remote
>> - Pull changes from the remote
>> - Close the project
>> - Use organizer to switch branch to "working"
>> - Open the project
>> - Merge changes from the "master" branch
>>
>> Those are a lot of steps to synchronize with the remote repository! Is this really the intended scenario?
>>
>> The opening and closing of the project are necessary to avoid Xcode crashing, and even then sometimes the SCM status gets messed up and it can't seem to identify that some files have modifications and this requires quitting and restarting Xcode (not just the project).
>>
>>
>> On Apr 13, 2011, at 5:11 AM, Rory O'Bryan wrote:
>>
>>> I've been learning about GIT and Xcode over the last few days and I haven't seen a way to do exactly what you want.
>>>
>>> However I think you could get the basic functionality you're after if you used two branches in Xcode.
>>>
>>> One branch would track the branch on the remote repository as it does now, and a new branch would act as your local "working" branch. You can pull the tracking branch to get new changes down to your local repository, and then use the version comparison tools in Xcode to compare the differences. Once you are satisfied with the changes you can then merge them into your "working" branch.
>>>
>>> Later on, when you are ready, you can merge your "working" branch changes back over to the tracking branch and push it all back up to the remote repository.
>>>
>>> I'm not sure how convenient the version comparison options are in Xcode for this workflow. I know you can use the Organiser -> Repositories window to inspect the changes in a branch compared to itself, and then the version editor in the main IDE will compare individual file across branches. So between the two I think you can work out the sum of all the changes that will take place but I don't think there's any way to directly compare entire branches like you get during a merge.
>>>
>>> Of course you could also make use of a third local "test_merge" branch to test the merge and get an overview of what will happen, which may not be as crazy as it sounds, GIt is all about making branching and merging easy. In this case your workflow would be...
>>>
>>> 1) Switch to the "master" branch and pull the changes from remote repository.
>>> 2) Use Organiser -> Repositories to inspect the changes in the "master" branch.
>>> 3) For simple changes just switch to the "working" branch and merge in from "master"
>>>
>>> 4) For complex changes, create a new "test_merge" branch based on the "working" branch.
>>> 5) Switch to the "test_merge" branch and merge from the "master" branch.
>>> 6) Inspect the changes using the merge window and the version editor.
>>> 7) Once you are ready delete the "test_merge" branch.
>>> 8) Switch to "working" branch and merge in from the "master" branch for real.
>>>
>>> It's probably not as complicated as it sounds, and having a separate working branches is standard GIT practice, from what I've read.
>>>
>>> Alternatively perhaps you could just merge as you are now and just roll back from the command line with "git reset" if you didn't like the result.
>>>
>>> A few ideas anyway..
>>>
>>> Regards,
>>>
>>> Rory O'Bryan
>>>
>>> On 12 Apr 2011, at 14:24, Pelaia II, Tom wrote:
>>>
>>>> Is there a way in Xcode to see which files will be updated in a git repository prior to a "Pull" command? When I perform a "Pull" command within Xcode, it simply updates all the files without telling me which ones it will update prior to the update unless there is a conflict. Unlike with SVN, I never see that files are awaiting update. I can only see which files it pulled after the fact by visiting the organizer. _______________________________________________
>>>> Do not post admin requests to the list. They will be ignored.
>>>> Xcode-users mailing list (email@hidden)
>>>> Help/Unsubscribe/Update your Subscription:
>>>>
>>>> This email sent to email@hidden
>>>>
>>>
>>
>>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden