Re: Question about possible git races

From: Radoslaw Szkodzinski <astralstorm@o2.pl>
Date: Mar 23, 2006, 01:24 UTC
Message-ID: <200603230224.54736.astralstorm@o2.pl>
In-Reply-To: <4421DD9E.7030201@op5.se>

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.

Show 11 quoted lines

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

Show 12 quoted lines

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

Show 5 quoted lines

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