On 4/21/2011 2:35, Invisible wrote:
>>> 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.

That's exactly how git works, workflow-wise, if you want.

http://book.git-scm.com/5_git_and_email.html

You *also* have the option of telling the other guy the URL of your 
repository and having him suck it in, or an option of pushing to a (possibly 
bare and unattended) repository your changes.

> 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.

Uh, no. Not if you're doing it manually. If you're automating it by cloning 
the repository or pulling and pushing changes over git protocols without 
human intervention, then yes. But since your repository tracks what you got 
from other people, you already know about changes you made that they don't have.

> 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.

Wow. Advice: Don't talk to anyone about how git works, since even if you 
think you've figured it out, you haven't.

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

Ah, thank you.

Yes. You're thinking that you can't add a commit to a repository without 
merging it in. You're still thinking there's one authoritative set of files. 
There aren't. There's bunches of snapshots.

So when you send your change to the maintainers, you're sending them new 
files. There are no merge conflicts, because there is no merge. Every 
changed file has a new sha-1, so it's a new file. git can look at the 
repository and know where in your working directory each file belongs 
(because some of the files in the repository are directories), but in the 
repository itself it's all just a big flat bag of sha-1 files.

So sending your changes to someone else doesn't cause merge conflicts, and 
there's no need to back them out.

When I want to put your changes into *my* version of the files, I have to 
merge it, just like Darcs.

The equivalent description would be that if you changed something in Darcs 
nd I made a change in my working directory, you could no longer send me 
patches until I threw away all my working-directory changes, in case there 
was a conflict.

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message