BlackBox Framework Center

Ivan Denisov wrote:

DGDanforth wrote:What I don't understand is 'conflict resolution'. If two people make changes to the same file (on their local versions) and then PUSH those changes back to the remote server then who wins? Is there a forced negotiation process that is automated?

Before push your commit you should make Remote/Fetch from/origin, if there is a conflict you will get the notification about it and can resolve this conflict manually. For plain text conflict git can make automated merge of files, however for BlackBox odc automated merge is not possible. You can use Dos or F9 for solve conflicts manually.

" if there is a conflict" => What constitutes a conflict?

I can think of two interpretations:
(1) Someone changed the code of the module since the time I pulled it to my local repository.
(2) There is some magical git process that detects conflicts ("get notification about it").

"git can make automated merge" => What constitutes a merge?
Do you mean that file A and file A' are combined into a single file A"?
If A is a set and A' is a set then one can combine those in several ways: INTERSECTION, UNION, DIFFERENCE
(with one set taking preference over the other). What do you mean by merge (yes these are sequences
of characters and not sets, I just used set as an illustration).

It appears to me (still as a novice playing this game) that there is no real gain from git when it comes down to the nitty gritty of technical code. Two people still need to cooperate with back and forth email to come to an agreement of how the code should look.

The benefit, as I see it, is in the automation of differencing files AND the automation of keeping a history of sets of files (versions) that work correctly together, committed sets.

Automatic merge is an intricate task and to be used with care.
In most cases, however, it works just fine, but only for plain texts, of course.
The existing merge tool in git is fairly smart about guessing the intentions
by starting from a common root of the documents to be merged.
From that point on the change operations in each branch can be reconstructed and applied
to the result as long as no merge conflict arises.
A merge conflict arises if both branches make changes to the same lines of code.

For us it is not a topic anyway, because we use binary files, which are not merged automatically,
unless, in a local repository, you install a specialized merge tool for that particular file type.
Such tools exist for example for Microsoft Office document types.

- Josef

The conflict is two branches with changes in the same file. Of cause Git does not check interfaces matching... so in real the conflict can be if some interfaces changed.

However two branches often can be automatically merged if changes are in different files. It should be done with care in case if some system modules changed and if changes are in one subsystem. If changes are in files from different components and do not touch system files mostly two branches can be merged automatically and tested.

Ivan Denisov wrote:The conflict is two branches with changes in the same file. Of cause Git does not check interfaces matching... so in real the conflict can be if some interfaces changed.

However two branches often can be automatically merged if changes are in different files. It should be done with care in case if some system modules changed and if changes are in one subsystem. If changes are in files from different components and do not touch system files mostly two branches can be merged automatically and tested.

Folks,
I am still struggling to understand what a 'branch' is and why it is needed.
Naively I would think that code splitting and following two different 'branches'
could be handled by creating a new project: one for each 'branch'.

Just have patient while I learn the rules of git.

DGDanforth wrote:I am still struggling to understand what a 'branch' is and why it is needed.
Naively I would think that code splitting and following two different 'branches'
could be handled by creating a new project: one for each 'branch'.

Branch is an deviation form the main trunk of the project. It takes little space of hard disk to make branch, because Git stores only binary difference between branches. Branches created usually for testing some bug fix solution or to explore new functionality and side effects of some code changes.

There is the good article of how developers use branches:
http://nvie.com/posts/a-successful-git-branching-model/

We made two branches now:
master — for stable releases;
development — for unstable releases.

Your local copy of repository and remote repository is also two branches: 'master' and 'origin/master', when you make some changes in you local 'master' it will be later merged with 'origin/master'. If there are no changes in 'origin/master' the merge will be trivial.

"There is the good article of how developers use branches:
http://nvie.com/posts/a-successful-git-branching-model/"

That document (which was also sent to me privately) was very helpful.
Thank you.