[James Ross]

I've started writing a specification for the Git proposal, which is mostly the introduction to Git stuff and details of how I believe the process will work.

I would appreciate it if you could comment on the document (requires a Microsoft account) or in this thread. In particular, I will be looking to answer any questions raised by editing the document, so that it provides the best information for the switch.

[wacampbell]

This is good to see. We have had the kind cooperation of a 3rd party to manage our SVN server for many years, but its time that we offload that task. A server change at the very least is in order, but now that OR is open source, we have the option to use Git services from Launchpad or others and that makes sense.

I am not familiar with Git, although I know it is widely praised. I am curious about its ability to pull and push changes. Is there magic here in fixing up coding conflicts that usually come with a merge, or is it just a line by line text merge of the code as we might have seen in SVN?

[Csantucci]

James,
first of all thank you very much for your document. It's exactly what I - that never used git - needed. I hope I will able to replicate the full flow.
Personally I was comfortable with Tortoise, but I understand there can be advantages here.

[James Ross]

wacampbell, on 27 March 2016 - 06:44 AM, said:

I am curious about its ability to pull and push changes. Is there magic here in fixing up coding conflicts that usually come with a merge, or is it just a line by line text merge of the code as we might have seen in SVN?

The pushing and fetching do not involve any merging themselves, as they're simply replicating one set of commits/history in to another repository. If you and I both make commits on branch A, when I get your commits locally I will have a divergent history. Git provides multiple options for resolving that:

• If my changes have not yet been shared, I have the option to "rebase" - which is effectively replaying my work on top of yours, so it becomes linear.
  
• In all cases, I have the option to "merge" - which is much the same as in Subversion, taking both histories and trying to reconcile their unique differences.

In both cases, conflicts can (and do occasionally) arise. Resolution is identical to Subversion, and if you use TortoiseGit you'll have exactly the same UI for it too. :)

I believe that Git can avoid merging and do better at it when it does happen for two reasons:

• Its history of commits and their parents is very precise and correct, where as Subversion has been lacking quite badly in this area - so Git has better information about the ancestry available.
  
• Its default merge algorithm can cope with multiple common ancestors, using the "recursive" merge strategy (the default), for when you've already done some merging and are re-merging branches and that kind of thing.

Git can also use other merge strategies and even has a few diff algorithms that can be selected in cases where the default "myers" is not working well. That flexibility is something I've not yet exploited, but is probably good to have in the toolkit.

[disc]

When will the switch happen?

[James Ross]

disc, on 01 April 2016 - 01:38 AM, said:

When will the switch happen?

Not until everyone is happy, as outlined over here. I expect it will be a few months.

[cjakeman]

James Ross, on 26 November 2015 - 01:36 PM, said:

Switching to a distributed version control system will enable developers to more easily create, share and collaborate on new features.

I've been collaborating with a colleague recently (using Microsoft Team Explorer) and being able to try things out and share is so much more productive. I never learned how to do that in the SVN that OR uses.

Hopefully, with Git we can work together much more easily.

[cjakeman]

James Ross, on 27 March 2016 - 05:07 AM, said:

I would appreciate it if you could comment on the document (requires a Microsoft account).

Can't find any option to comment when I'm logged in through my Microsoft account. Sorry about that.

[cjakeman]

James Ross, on 27 March 2016 - 05:07 AM, said:

I've started writing a specification for the Git proposal, which is mostly the introduction to Git stuff and details of how I believe the process will work.

I worked through your Git workflow example so here is some feedback. As a newcomer to Git, I found a few sticking points in following the example.

Step 1: New repository
It wasn't clear that I should create a branch "develop" at this stage as I would need it in Step 4.

Step 2: Create a branch for doing some work
I puzzled over "feature/example" wondering if "/" was a command parameter. I've since confirmed that branches can contain "/" characters and form a hierarchy.

Step 3: Make changes
After making a change, my commit failed as no files had been added.
I fixed this by including the -a attribute but is that best practice?
git commit -a -m “This is an example commit”

Step 4: Combine with work from others
After switching back to the branch "develop", "git pull" failed with
"There is no tracking information for the current branch."

I tried a few things but without success.
How do I fix this?

Thanks

[Serana]

cjakeman, on 11 June 2016 - 06:46 AM, said:

Step 3: Make changes
After making a change, my commit failed as no files had been added.
I fixed this by including the -a attribute but is that best practice?
git commit -a -m “This is an example commit”

I think this is not the best practice.
Best practice would be :
1) Add the files you want to include in the repository : git add <file name list>
This allows you to control what you want to include. For example, you don't want to include build files (not the best example : build files can be ignored using a .gitignore file).
2) Then commit : git commit -m <commit message>