Re: [PATCH 0/4] Pulling refs files

From: Daniel Barkalow <barkalow@iabervon.org>
Date: May 17, 2005, 22:20 UTC
Message-ID: <Pine.LNX.4.21.0505171802570.30848-100000@iabervon.org>
In-Reply-To: <20050517214533.GP7136@pasky.ji.cz>

On Tue, 17 May 2005, Petr Baudis wrote:

Show 14 quoted lines

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

If you want to get info/ignore, you want to get it and save it, not download a set of objects it refers to. So it's different from specifying that you want to use refs/heads/master as the starting point for a pull.

There would be a separation between transfering whatever file you specify and treating the specified (remote) file from refs/ as the starting point for pulling objects.

Also, you don't need to do the same kind of careful update, since the desired value of info/ignore isn't going to depend on the previous value.

Show 8 quoted lines

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

The way I'm actually doing things is to write NEW into the lock file at some arbitrary point, and "writing to the file" is actually renaming the lock file to the normal filename. So writing unlocks the file automatically.

Show 5 quoted lines

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

I think I'll get to implementing it Wednesday night. I might be able to get the first step done tonight (my previous patch, except with the transfer applying to arbitrary files).

	-Daniel
*This .sig left intentionally blank*