On Nov 21, 2007 6:26 PM, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > Hi, > > On Wed, 21 Nov 2007, Jakub Narebski wrote: > > > 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". > > > I'd rather use "git push bundle:///some/path/to/bundle" or "git push > > --bundle bundlename" to catch errors better. I would vote for the later, and a way to configure this in the config. > > > > 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. I prefer not to overwrite an existing bundle. > > 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. Sorry but I do not understand this. I think this two lines could be equivalent: git push --bundle bundle.bdl "refs/heads/master:refs/remotes/bundle/master" git bundle create bundle.bdl refs/heads/master ^refs/remotes/bundle/master > > 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. That make sense. Santi - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
