A useful shell safety helper sq_expand() was hidden as a static
function in diff.c. Extract it out and make it available as
sq_quote().
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---
> "JCH" == Junio C Hamano <[EMAIL PROTECTED]> writes:
JCH> I am not going to do it myself immediately
A useful shell safety helper sq_expand() was hidden as a static
function in diff.c. Extract it out and make it available as
sq_quote().
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---
> "JCH" == Junio C Hamano <[EMAIL PROTECTED]> writes:
JCH> I am not going to do it myself immediately
On Thu, 7 Jul 2005, Junio C Hamano wrote:
>
> However it does not automatically mean that the avenue I have
> been pursuing would not work; the server side preparation needs
> to be a bit more careful than what I sent, which unconditionally
> runs "prune-packed". It instead should leave the fil
On Thu, 7 Jul 2005, Kevin Smith wrote:
>
> Absolutely. For the kernel it might not make sense, but I view it as a
> really important feature for tiny projects around the world. Even a CGI
> requirement makes it impossible to serve a project from free or really
> cheap web hosts. Plain HTTP is
> "LT" == Linus Torvalds <[EMAIL PROTECTED]> writes:
LT> However, I really don't think it's a very useful option in
LT> the first place. Any dumb web-based thing that depends on
LT> "--whole-trees" would suck horribly.
I agree with these two sentences now.
However it does not automatically
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On Thu, 7 Jul 2005, Eric W. Biederman wrote:
>>
>> For optimizing network bandwidth that sounds like the way to go. For
>> adhoc development I don't know. For a central sever you still need
>> an authenticated way to push content, which makes it anoth
Eric W. Biederman wrote:
Linus Torvalds <[EMAIL PROTECTED]> writes:
That said, I really think the dumb protocols are useless anyway. No other
system supports pure static object pulling anyway, and as far as I'm
concerned, I want "rsync" to kind of work (but it won't be optimal, since
re-pack
On Thu, 7 Jul 2005, Junio C Hamano wrote:
>
> When --full-objects is specified instead of usual "--objects",
> rev-list shows all objects reachable from trees associated with
> the commits in its output. This can be used to ensure that a
> single pack can be used to recreate the tree associated
On Thu, 7 Jul 2005, Junio C Hamano wrote:
>
> Again you are right. How about --full-objects instead?
I don't mind the "--objects=xxx" format per se, but it would need to
verify that the "=xxx" was either valid or wasn't there at all. So what I
objected to was not that it was easy to mis-spel
> "PO" == Peter Osterlund <[EMAIL PROTECTED]> writes:
PO> I think it would be good if it was possible to include diffstat output
PO> in exported patches, something like this:
PO> Added possibility to include diffstat output in exported patches.
And you wuold want to do things similarly to wh
Catalin Marinas <[EMAIL PROTECTED]> writes:
> A new StGIT release is available from http://procode.org/stgit/
I think it would be good if it was possible to include diffstat output
in exported patches, something like this:
Added possibility to include diffstat output in exported patches.
Signe
> "LT" == Linus Torvalds <[EMAIL PROTECTED]> writes:
LT> This is nasty - if you mis-spell "self-sufficient" (easy enough to do)
LT> you'll never know the end result isn't what you expected. It won't warn
LT> you in any way, it will just make a non-self-sufficient pack..
Again you are right.
> "LT" == Linus Torvalds <[EMAIL PROTECTED]> writes:
LT> This is nasty - if you mis-spell "self-sufficient" (easy enough to do)
LT> you'll never know the end result isn't what you expected. It won't warn
LT> you in any way, it will just make a non-self-sufficient pack..
To match the change
On Thu, 7 Jul 2005, Tony Luck wrote:
>
> This is what happens ("linus" is a local branch just pulled from kernel.org,
> so it just contains one pack file and its index).
>
> $ cg-update linus
> `/home/aegl/GIT/linus/.git/refs/heads/master' -> `.git/refs/heads/linus'
> does not exist
> /home/ae
On Thu, 7 Jul 2005, Linus Torvalds wrote:
> >
> > cg-update from a local repo that contains packs is broken though :-(
>
> Is this with cg-0.12? The most recent release should be happy with packs.
Ahh, I see it. It's because it uses "git-local-pull", and yes,
git-local-pull does the old filen
> > cg-update from a local repo that contains packs is broken though :-(
>
> Is this with cg-0.12? The most recent release should be happy with packs.
Yes ... I pulled, built and installed the latest cogito this afternoon
before trying
to touch anything involving packs. cg-version says:
cogito-
On Thu, 7 Jul 2005, Tony Luck wrote:
>
> > > So, what _is_ then the way to pull now, actually? If we use rsync, won't
> > > we end up with having the objects we previous had twice now?
> >
> > Rsync works fine. You can either unpack the pack you get, or, if you
> > prefer, just run
> >
> >
On Thu, 7 Jul 2005, Junio C Hamano wrote:
>
> - if (!strcmp(arg, "--objects")) {
> + if (!strncmp(arg, "--objects", 9)) {
> + if (!strcmp(arg+9, "=self-sufficient"))
> + objects_self_sufficient = 1;
This is nasty - if you mi
> "TL" == Tony Luck <[EMAIL PROTECTED]> writes:
TL> Also "git-fsck-cache" in a repo that is fully packed complains:
TL>fatal: No default references
"git-fsck-cache --full", perhaps?
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTE
> > So, what _is_ then the way to pull now, actually? If we use rsync, won't
> > we end up with having the objects we previous had twice now?
>
> Rsync works fine. You can either unpack the pack you get, or, if you
> prefer, just run
>
> git-prune-packed
cg-update from a local repo that
When --objects=self-sufficient is specified instead of usual
"--objects", rev-list shows all objects reachable from trees
associated with the commits in its output. This can be used to
ensure that a single pack can be used to recreate the tree
associated with every commit in it.
Signed-off-by: Ju
This adds --self-sufficient flag to git-repack-script, and uses
it when preparing the dumb server material.
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---
*** This makes things easier for the dumb puller because
*** self-sufficient pack means less falling back on traditional
*** http-pull.
The git-update-dumb-server-script command statically prepares
additional information to describe what the server side has, so
that a smart client can pull things efficiently even via a
transport such as static-file-only HTTP.
The files prepared by the command is $GIT_DIR/info/server, which
is a ta
Hello,
I have problems with Cogito-0.12 when trying to clone a "local" tree:
My "original" tree is in /git/u-boot-denx (imported from CVS); "/git"
is a directory mounted over NFS; all this is under Fedora Core 4 in
case it matters:
-> cd /git/u-boot-denx
-> cg-tag-ls
/g
On Fri, 8 Jul 2005, Petr Baudis wrote:
> Let me join the sceptics camp. :-)
>
> Dear diary, on Thu, Jul 07, 2005 at 09:04:58PM CEST, I got a letter
> where Linus Torvalds <[EMAIL PROTECTED]> told me that...
> > Note that I just re-packed the kernel archive on kernel.org, and removed
> > _all_
Ack - sorry I didn't notice that side effect.
jon.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 7 Jul 2005, Eric W. Biederman wrote:
>
> For optimizing network bandwidth that sounds like the way to go. For
> adhoc development I don't know. For a central sever you still need
> an authenticated way to push content, which makes it another dimension
> of the problem.
I'm convinced th
Linus Torvalds <[EMAIL PROTECTED]> writes:
> That said, I really think the dumb protocols are useless anyway. No other
> system supports pure static object pulling anyway, and as far as I'm
> concerned, I want "rsync" to kind of work (but it won't be optimal, since
> re-packing will delete all
> "LT" == Linus Torvalds <[EMAIL PROTECTED]> writes:
>> (2) When "showing --objects", it lists the top-level tree node
>> with no name, which makes it indistinguishable from commit
>> objects by pack-objects, probably impacting the delta logic.
>> Would something like the following patch make
The current error message does not make any sense.
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---
pack-check.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
c3818dc056d1a603e15fe3f862849eddaee2a7c3
diff --git a/pack-check.c b/pack-check.c
--- a/pack-check.c
+++ b/pack-check
Let me join the sceptics camp. :-)
Dear diary, on Thu, Jul 07, 2005 at 09:04:58PM CEST, I got a letter
where Linus Torvalds <[EMAIL PROTECTED]> told me that...
> Note that I just re-packed the kernel archive on kernel.org, and removed
> _all_ unpacked files. Once that percolates to the mirrors, t
On Thu, 7 Jul 2005, Junio C Hamano wrote:
>
> (1) Would it make sense to have an extra flag to "rev-list
> --objects" to make it list all the objects reachable from
> commits listed in its output, even when some of them are
> unchanged from UNINTERESTING commits? Right now, a pack
>
On Thu, 2005-07-07 at 21:17 +0200, Peter Osterlund wrote:
> I've found an unrelated problem. If I export patches with "stg export
> dirname", there are no diffs included in the patches. The patch
> description is all that is generated. If I omit the dirname parameter,
> the export works correctly t
On Wed, 2005-07-06 at 21:48 -0700, Tony Luck wrote:
> Groan ... as well you should.
>
> My tree has re-appeared now. Thanks to whoever fixed it.
I noticed similar effects recently. Its related to the mirroring of
master.kernel.org to the public server. At some point you have only the
half of upd
On Thu, 7 Jul 2005, Junio C Hamano wrote:
>
>- X.git/objects/pack can have packed GIT archives. I
> envision that this will be a series of 5 to 20 MB packs,
> occasionally adding a new incremental pack when
> X.git/objects/??/ directories accumulate enough standalone
> S
Linus,
You'll find the necessary infrastructure for doing an rpm build here:
kernel.org/pub/scm/linux/kernel/git/chrisw/git.git
The diff is below:
diff-tree a9db297485a7b8c641d3cf686d03cb63b774e530 (from
dd7ba8b4949535c24e604a37709db0e3be9ccbbc)
Author: Chris Wright <[EMAIL PROTECTED]>
I have two questions on "rev-list --objects".
(1) Would it make sense to have an extra flag to "rev-list
--objects" to make it list all the objects reachable from
commits listed in its output, even when some of them are
unchanged from UNINTERESTING commits? Right now, a pack
produ
> "LT" == Linus Torvalds <[EMAIL PROTECTED]> writes:
LT> ... No other
LT> system supports pure static object pulling anyway,...
That is true, but on the other hand, no other system is easier
to be deployed by mere mortals on barebone ISP accounts.
-
To unsubscribe from this list: send the l
Catalin Marinas <[EMAIL PROTECTED]> writes:
> On Mon, 2005-07-04 at 14:32 +0200, Peter Osterlund wrote:
> > I agree with the other comments, it's probably not wise to rely on
> > wiggle, and wiggle sometimes makes a mess. However, it often does the
> > right thing, and with a configurable merge pr
The Makefile in the test suite directory considers any file
matching t[0-9][0-9][0-9][0-9]-*.sh as the top-level test script
to be executed. Unfortunately this was not documented, and the
common test library, t6000-lib.sh was named to match that
pattern. This caused t6000-lib.sh to be called from
Update cogito.spec.in to current. This uses .gz instead of .bz2 for source
target as suggested by John Ellson, as well as some assorted minor changes.
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
---
diff --git a/cogito.spec.in b/cogito.spec.in
--- a/cogito.spec.in
+++ b/cogito.spec.in
@@ -6,
* John Ellson ([EMAIL PROTECTED]) wrote:
> So now I have to ask, where does that come from if its not created by
> "make dist" ?
It's automated by kernel.org mirroring (along with signature
generation). So .gz is built, uploaded, the rest is automatic.
> Is what I'm asking to do in the above se
> "PB" == Petr Baudis <[EMAIL PROTECTED]> writes:
PB> It won't happen. Or rather, I hope the HTTP pulls become more efficient
PB> soon. Actually, perhaps Linus has something done already, my workstation
PB> is a bit derailed now so I couldn't pull from him in the last few days
PB> (hopefully w
Chris Wright wrote:
* John Ellson ([EMAIL PROTECTED]) wrote:
But:
cd cogito
cg-update
make dist
rpmbuild -ta cogito-0.12.tar.gz
still doesn't work.Do you have a different process for generating
the initial cogito-0.12-1src.rpm ?
I start from the bz2 from kernel.org.
tha
* John Ellson ([EMAIL PROTECTED]) wrote:
> But:
>cd cogito
>cg-update
>make dist
>rpmbuild -ta cogito-0.12.tar.gz
>
> still doesn't work.Do you have a different process for generating
> the initial cogito-0.12-1src.rpm ?
I start from the bz2 from kernel.org.
thanks,
-chris
-
Chris Wright wrote:
* John Ellson ([EMAIL PROTECTED]) wrote:
"rpmbuild -ta cogito-0.12.tar.gz" fails because cogito.spec.in refers to
".bz2" in its "Source:" line, instead of to ".gz".
Just grab the .bz2, or the SRPM http://kernel.org/pub/software/scm/cogito/RPMS
(still mirroring, I j
Dear diary, on Wed, Jul 06, 2005 at 08:40:00PM CEST, I got a letter
where John Ellson <[EMAIL PROTECTED]> told me that...
> "rpmbuild -ta cogito-0.12.tar.gz" fails because cogito.spec.in refers to
> ".bz2" in its "Source:" line, instead of to ".gz".
(FYI, cogito.spec.in is Chris' sole teritorry in
Dear diary, on Wed, Jul 06, 2005 at 02:01:38PM CEST, I got a letter
where Brian Gerst <[EMAIL PROTECTED]> told me that...
> Petr Baudis wrote:
> > Also, I've deprecated rsync, as I explained in another mail. Use
> >cg-branch-chg to change the branch URLs to some more sensible scheme -
> >most like
On Saturday 25 June 2005 02:20, Linus Torvalds wrote:
> On Wed, 22 Jun 2005, Alexander Y. Fomichev wrote:
> > I've been trying to switch from 2.6.12-rc3 to 2.6.12 on Dual EM64T 2.8
> > GHz [ MoBo: Intel E7520, intel 82801 ]
> > but kernel hangs on boot right after records:
> >
> > Booting processor
49 matches
Mail list logo
