>> Given that it's the repository format used by Linux developers, I think
>> it's safe to say it works adequately for multiple people editing the
>> file in parallel.
>
> This boggles my mind. Apparently I /don't/ understand how Git works at
> all...

Perhaps I can summarise:

The Darcs workflow. I download the source code, make a small edit to it, 
ask Darcs to record that, and send the changes to the developers. They 
add it to the central repo, which checks whether the bit I just edited 
has changed since I got my copy. If not [which is quite likely], the 
change is added to the central repo. Done.

The Git workflow. I download the source code, make a small edit to it, 
and ask Git to record that. Git takes a complete record of every file in 
the entire repo. I send that to the developers, and they try to add it 
to the central repo, which makes Git check whether any unrelated changes 
have happened anywhere in the entire repo since I made my change. Since 
it is 100% guaranteed that this will have happened, the merge fails. I 
now have to download the latest version of the source code, do a bunch 
of work on my end to incorporate my 3-line edit into the newly updated 
source tree, record a completely new commit object, and send that plus 
the previous one back to the developers. They try to merge, find the 
exact same problem, and I have to repeat all the above steps. We repeat 
this endlessly until, by some fluke, I manage to execute the entire 
download / merge / commit / send / have the developers merge cycle 
without anybody else successfully merging to the central repo in 
between. When this happens, instead of the 3-line change being added to 
the central repo, we get a 25-mile string of merge commits plus the 
actual 3-line edit at the beginning.

FTW, people?

Obviously this model cannot possibly work, so there must be something 
I'm misunderstanding about how Git works.

Post a reply to this message