Re: Wishlist for a bundle-only transport mode

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Nov 21, 2007, 17:26 UTC
Message-ID: <Pine.LNX.4.64.0711211719330.27959@racer.site>
In-Reply-To: <200711211811.34391.jnareb@gmail.com>

Hi,

On Wed, 21 Nov 2007, Jakub Narebski wrote:

Show 15 quoted lines

> Johannes Schindelin wrote:
> > On Wed, 21 Nov 2007, Jakub Narebski wrote:
> >
> >> That has the disadvantage of pushing to bundle when you make an error 
> >> in the lastpart of path to existing repository.
> > 
> > As I wrote in another reply, I would not allow overwriting an existing 
> > file.
> 
> > Specifying a non-existing file should be good enough.
> 
> What I meant here that if you do "git push /some/path/to/rpeo.git", with 
> mistake in the last part of path to repository, you would end up with a 
> bundle, and you would have to really watch what happened to catch the 
> error.

I use tab completion all the time, so this would not happen to me. IMHO that is a lesser issue than to introduce a "protocol".

Show 5 quoted lines

> I'd rather use "git push bundle:///some/path/to/bundle" or "git push 
> --bundle bundlename" to catch errors better.
> 
> Besides it should be IMHO be possible to overwrite bundle if you are 
> doing fast-forward push...

Not as far as I can see. A push there would see what the bundle has already, and put them into the new bundle as _prerequisites_. So the bundle would lose information.

BTW this was my gripe (that I decided not to make public earlier) with Santi's proposal to begin with: a push would not have any way to specify what the other side has already. So I think "git push <bundle>" is the wrong way of creating a bundle.

Except if we add some cunning strategy not to overwrite, ever, but to create <bundle>.<n> with an incrementing <n>. But that might be too much.

Ciao, Dscho