Petr Baudis <[EMAIL PROTECTED]> said:
[...]
> The way to work around that is to setup separate rsync URIs for each of
> the trees. ;-) I think I will make git-pasky (Cogito) accept also URIs
> in form
>
> rsync://host/path!branchname
>
> which will allow you to select the particular branc
Petr Baudis <[EMAIL PROTECTED]> writes:
Still, why would you escape it? My shell will not take # as a
comment start if it is immediately after an alphanumeric character.
I guess there MIGHT be some command shell implementation
that stupidly _DID_ accept "#" as a comment character,
even immediately
> Petr Baudis <[EMAIL PROTECTED]> writes:
> Remember that it's an URL (so you can't use '%'), and '#' is the
> canonical URL fragment identifier delimiter. (And fragments are
> perfect for this kind of thing, if you look at the RFC, BTW.)
Ouch, true--rule out %...
> Still, why would you esca
Dear diary, on Fri, Apr 22, 2005 at 03:48:35AM CEST, I got a letter
where Inaky Perez-Gonzalez <[EMAIL PROTECTED]> told me that...
> > Petr Baudis <[EMAIL PROTECTED]> writes:
>
> > I've just added to git-pasky a possibility to refer to branches
> > inside of repositories by a fragment identifi
> Petr Baudis <[EMAIL PROTECTED]> writes:
> I've just added to git-pasky a possibility to refer to branches
> inside of repositories by a fragment identifier:
> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6.git#testing
> will refer to your testing branch in that repository
Dear diary, on Fri, Apr 22, 2005 at 01:01:13AM CEST, I got a letter
where [EMAIL PROTECTED] told me that...
> But now I need a way to indicate to consumers of the public shared object
> data base which HEAD to use.
>
> Perhaps I should just say "merge 821376bf15e692941f9235f13a14987009fd0b10
> fro
In article <[EMAIL PROTECTED]> you wrote:
> Why? Because I'm still using the stupid "get all objects" thing when I
> pull.
one could do a symlink/hardlink parallel tree for a specific snapshot with
GIT tools, and then only poll that with git-unaware copy tools.
I guess this would make sense for t
Dear diary, on Fri, Apr 22, 2005 at 01:19:47AM CEST, I got a letter
where Linus Torvalds <[EMAIL PROTECTED]> told me that...
> So in the long run this issue goes away - we'll just have synchronization
> tools that won't get any unnecessary pollution. But in the short run I
> actually check my git
On Thu, 21 Apr 2005 [EMAIL PROTECTED] wrote:
>
> I want to have one "shared objects database" which I keep locally and
> mirror publicly at kernel.org/pub/scm/...
Ahh, ok. That's easy.
Just set up one repository. Then, make SHA1_FILE_DIRECTORY point to that
repository, and everybody will auto
> It's mainly a clue to bad practice, in my opinion. I personally like the
> "one repository, one head" approach, and if you want multiple heads you
> just do multiple repositories (and you can then mix just the object
> database - set your SHA1_FILE_DIRECTORY environment variable to point to
>
Dear diary, on Fri, Apr 22, 2005 at 12:29:07AM CEST, I got a letter
where Linus Torvalds <[EMAIL PROTECTED]> told me that...
> On Thu, 21 Apr 2005 [EMAIL PROTECTED] wrote:
> >
> > I can't quite see how to manage multiple "heads" in git. I notice that in
> > your tree on kernel.org that .git/HEAD
Dear diary, on Thu, Apr 21, 2005 at 11:55:43PM CEST, I got a letter
where [EMAIL PROTECTED] told me that...
> I can't quite see how to manage multiple "heads" in git. I notice that in
> your tree on kernel.org that .git/HEAD is a symlink to heads/master ...
> perhaps that is a clue.
>
> I'd like
On Thu, 21 Apr 2005 [EMAIL PROTECTED] wrote:
>
> I can't quite see how to manage multiple "heads" in git. I notice that in
> your tree on kernel.org that .git/HEAD is a symlink to heads/master ...
> perhaps that is a clue.
It's mainly a clue to bad practice, in my opinion. I personally like th
Adding linux-kernel to Cc: list, as I'm sure Linus wants to hear from
all maintainers, not just those that hang out on the linux-ia64 list.
>On Thu, 21 Apr 2005, Linus Torvalds wrote:
>Btw, just in case it wasn't obvious anyway: I based pretty much _all_ of
>the git design on three basic goals: pe
14 matches
Mail list logo
