Re: Question about possible git races

[Radoslaw Szkodzinski <astralstorm@o2.pl>]

[-- Attachment #1: Type: text/plain, Size: 3120 bytes --]

On Thursday 23 March 2006 00:28, Andreas Ericsson wrote yet:
> However, feeling  slightly tipsy and in a distinctly good mood, I shall try 
to answer your questions anyway.

The golden liquid works for me, great. Thank you.

>
> > so I'd like to see if
> > there are any races:
> >
> > - push vs pull
> > One thread pushes to the repository while another is pulling from it at
> > the same time. I should get the older commit.
>
> You will. Git atomizes (atomicizes? atomicifies?) pushes by updating the
> branch head being pushed to after all the commit-, tree- and
> blob-objects are written. 

Just as I expected. Good.

> Tags are handled separately but equally 
> atomically.

Good too.

>
> > - fetch vs fetch
> > I mean that two threads try to fetch from different repositories to a
> > single one. Possibly those two aren't fast-forward of each other.
> > Any good way to merge those fetches?
> > (I have full access to both repos)
>
> git help octopus
>
> You can fetch those two remote branch heads to local branches
> simultaneously and then do the octopus in the master-thread while no
> other updates are happening.

I could slurp the unrelated commits with an octopus of course...
But the others pose a problem.

> Doing several simultanous merges to a 
> single branch is quite frankly so insane I have to go get myself a drink
> just from thinking about it.

It's a rare situation in the app, but not impossible. (I want to avoid 
locking) That's why I was asking about it.

>
> > I'm meaning really bare git there, w/o bash+perl scripts.
>
> I don't think you can do it without Python. The default merge strategy
> is written in python, so.

You've hit it, the app is written in Python (as of yet).

The default merge strategy is simply... calling merge and also detecting 
naming/existence conflicts with a simple scalar merge.

The only bit more complicated thing is detecting the LCA for 3-way merge.


I'd like to build a decentralised collaborative web application, as scalable 
as it gets. (I expect a lot of traffic)
I also need to only check out parts of the tree. (many SCMs can't do that)
Git, with its speed, seems well-suited to the task.
Merging will be uncommon in the workload, so can be slow, but shouldn't break 
or present weird conflicts to the users.

Unless the accidental case starts to dominate - then I'll have a problem.

Sorry for spam and cutting out major questions, then answering at the end of 
the post.


> Btw. I'm assuming you're aware you'll have to GPL this app of yours,
> since git is GPL and you'll be using the git produce in a way that makes
> it vital to your app.

It will be, but not because of git (it's execve()ing it), but rather because 
of the principle.

Intermediate results will probably be:
- a good Python object interface to git
- another porcelain, portable, coded in Python
- maybe a new merge strategy
- later yet another porcelain, written in C

-- 
GPG Key id:  0xD1F10BA2
Fingerprint: 96E2 304A B9C4 949A 10A0  9105 9543 0453 D1F1 0BA2

AstralStorm

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]