From: Petr Baudis <pasky@suse.cz>
To: Junio C Hamano <junkio@cox.net>
Cc: git@vger.kernel.org
Subject: Re: Pushing vs. alternates
Date: Tue, 24 Oct 2006 19:23:11 +0200 [thread overview]
Message-ID: <20061024172311.GT18879@pasky.or.cz> (raw)
In-Reply-To: <7vzmblhc3y.fsf@assigned-by-dhcp.cox.net>
On Tue, Oct 24, 2006 at 07:12:17PM CEST, Junio C Hamano wrote:
> Petr Baudis <pasky@suse.cz> writes:
>
> > Dear diary, on Tue, Oct 24, 2006 at 07:29:45AM CEST, I got a letter
> > where Junio C Hamano <junkio@cox.net> said that...
> >> Petr Baudis <pasky@ucw.cz> writes:
> >>
> >> > I don't have time to code that myself right now, so I'm just tossing
> >> > an idea around - pushing to a directory with alternates set up should
> >> > avoid sending objects that are already in the alternate object database.
> >>
> >> That is probably only relevant for the first time, since
> >> subsequent pushes have refs from its own repository that tracks
> >> the tips of branches that was pushed for the last time.
> >
> > Well, I would send haves for the alternate repository anyway,...
>
> While I agree it would be an optimization if it worked, there is
> one conceptual problem here though, coming from old warts. It's
> not alternate "repository" but it is alternate object store.
Yes. Which is ugly but it may make sense in case of really having things
like "portable objects database" on your usbflash or whatever else
insane. ;-) Still,
> There is no guarantee that refs/ directory that is next to the
> objects/ alternate points at is related to that object store,
> for historical reasons (i.e. we have separate GIT_DIR and
> GIT_OBJECT_DIRECTORIES). So unless we declare that objects that
> are reachable from the refs/ *must* be fully connected in
> objects/ when objects/ has refs/ next to it, sending HAVEs from
> that refs/ can break the push, since that refs/ you are looking
> at may not be related to the alternate objects/ at all. I do
> not think it is a big restriction at all, but it is a new
> restriction you are adding to the repository layout.
I think this situation (having something that looks like a Git
repository with objects/ inside that does *not* belong to this
repository) _is_ totally insane and such a restriction is fine. Who
thinks otherwise?
If this really bothers anyone (I can't see why), we could have something
like [ -e objects/info/standalone ] to prohibit receive-pack from ever
thinking of checking if the object database belongs to a repository. We
could of course keep the behaviour as is and make the new one optional,
but I believe that the new one is more sensible.
> > ... You can only push if your login access is reduced to
> > git-shell, and something external could've set up your alternates.
>
> Ok, I was not thinking about "something external".
Also, if you can push, that does not imply at all that you can fetch as
well. In plenty of situations you can't; most UNIX machines do have ssh
running, but that's not very useful when they're behind a NAT or just a
restrictive firewall. And with my notebook, I'm almost always behind a
NAT.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
next prev parent reply other threads:[~2006-10-24 17:23 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-24 3:53 Pushing vs. alternates Petr Baudis
2006-10-24 5:29 ` Junio C Hamano
2006-10-24 5:46 ` Shawn Pearce
2006-10-24 11:20 ` Petr Baudis
2006-10-24 17:12 ` Junio C Hamano
2006-10-24 17:23 ` Petr Baudis [this message]
2006-10-24 17:33 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20061024172311.GT18879@pasky.or.cz \
--to=pasky@suse.cz \
--cc=git@vger.kernel.org \
--cc=junkio@cox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).