Re: [PATCH 0/4] Pulling refs files

From: Petr Baudis <pasky@ucw.cz>
Date: May 17, 2005, 21:45 UTC
Message-ID: <20050517214533.GP7136@pasky.ji.cz>
In-Reply-To: <Pine.LNX.4.21.0505171645130.30848-100000@iabervon.org>

Dear diary, on Tue, May 17, 2005 at 11:20:54PM CEST, I got a letter where Daniel Barkalow <barkalow@iabervon.org> told me that...

Show 13 quoted lines

> On Tue, 17 May 2005, Petr Baudis wrote:
> > Anything that gets eventually wound up in the info/ directory. (The name
> > of the ignore file saved in info/ignore is the current hit.)
> 
> Hmm... maybe the right thing is to make the implementation-provided
> transfer code handle arbitrary things in GIT_DIR, but have code for
> updating reference files atomically and using a reference file to start
> from use "refs/"? Certainly, there's nothing special about reference files
> in transit.
> 
> Certainly the things in the info/ directory shouldn't be treated a head
> that you're going to pull, so that has to be different above the protocol
> level anyway.

*confused* :) I'm sorry, I have trouble understanding this. Could you rephrase, please?

Show 5 quoted lines

> > Well, it'd be again nice to have some generic mechanism for this so that
> > the user could theoretically push over rsync too or something (although
> > that'll be even more racy, it is fine for single-user repository).
> 
> Hmm; I'm not sure what would be good for interfacing with rsync.

I've been thinking about writing some FTP-like client for rsync, where you could "interactively" tell it what files to download etc.

Show 8 quoted lines

> > I think the remote file to write the value inside should be porcelain
> > business.
> 
> Certainly it's porcelain business what remote file to write; but I think
> it has to be core business doing the lock, test, and update. I think it
> would be inconvenient to go back to the porcelain layer in the middle of
> the operation, particularly since it would have to go back to the core,
> which is what has the connection to the remote host.

Of course. The porcelain file would just provide the filename.

Show 13 quoted lines

> > What you should always check though is that before the pull
> > (and after the locking) the value in that file is the same as the "push
> > base". This way you make sure that you are still following a single
> > branch and in case of multiuser repositories that you were fully merged
> > before pushing.
> 
> So the remote receiver should get an instruction: change X from OLD to NEW
> and pull NEW. It should:
> 
>  - lock the file against further updates
>  - check that the current value is the provided OLD
>  - pull the necessary objects
>  - write NEW to the file

- unlock the file ;-))

>  - report success
> 
> On failure of any step, it should unlock the file without changing it.

Sounds right.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor