Paul Jackson wrote:
David wrote:
It's a trade-off, I know.
So where do you recommend we make that trade-off?
I'd look at some of the more constraining, yet still
common cases, and make sure it worked reasonably
well without requiring magic. My list would be:
ext2, ext3, NFS, and Windows' NTFS (stu
Hi,
after playing a while with git-pasky it is a crap to interpret the date of
commit logs. Though it was a good idea to put the date in a parseable format
(seconds since), but the format of the commit itself is not good parseable.
For easy converting the commit log header in readable format it s
Linus Torvalds wrote:
On Sat, 16 Apr 2005, Paul Jackson wrote:
Morten wrote:
It makes some sense in principle, but without storing what they mean
(i.e., group==?) it certainly makes no sense.
There's no "they" there.
I think Martin's proposal, to which I agreed, was to store a _single_
bit. If an
> "LT" == Linus Torvalds <[EMAIL PROTECTED]> writes:
>> - When merging two trees, i.e. "read-tree -m A B", shouldn't
>> we collapse identical stage-1/2 into stage-0?
LT> How do you actually intend to merge two trees?
How silly of me. *BLUSH*
-
To unsubscribe from this list: send the line
When update-cache --remove is run, resolve unmerged state for
the path. This is consistent with the update-cache --add
behaviour. Essentially, the user is telling us how he wants to
resolve the merge by running update-cache.
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---
read-cache.c |
The patch to introduce shell safety to show-diff has an
off-by-one error. Here is an fix.
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---
show-diff.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
show-diff.c: 8a24ff62b85a6e23469e3f0e7a20170dfe543ebf
--- show-diff.c
+++ sh
This is a fairly trivial addition, but if users are adding remote repositories
with git addremote, then those users should be able to list out the remote
list without having to know the details of where the remotes file is kept.
Steven
Adds lsremote command to list remotes.
Signed-Off-By: Steven
This is my bad. I added #include to the file,
which I ended up not using and failed to remove it.
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---
show-diff.c: d85d79b97a59342390bd34da09049dd58d56900f
--- show-diff.c
+++ show-diff.c 2005-04-16 22:37:29.0 -0700
@@ -4,7 +4,6 @@
* C
On Sat, 16 Apr 2005, Linus Torvalds wrote:
>
> Anybody want to send a patch to do this?
Actually, I just did it. Seems to work for the only test-case I tried,
namely I just committed it, and checked that the permissions all ended up
being recorded as 0644 in the tree (if it has the -x bit set,
Linus wrote:
> It might be ok to just change the "compare cache" check to only care
> about a few bits, though: S_IXUSR and S_IFDIR. And then ...
I think I agree. But since I am reluctant to take enough time to
understand the code well enough to write this patch, I'll shut up now ;).
--
When checkout-cache -a is run, currently it attempts to extract
each existing unmerged stage to the same destination and
complains to what it itself has done. This is nonsensical.
Presumably, the user is running checkout-cache -a in order to
verify the result of the part that has cleanly been mer
On Sat, 16 Apr 2005, Junio C Hamano wrote:
>
> I am wondering if you have a particular reason not to do the
> same for the removing half.
No. Except for me being silly.
Please just make it so.
> Also do you have any comments on this one from the same message?
>
> * read-tree
>
>- When
Linus,
earlier I wrote [*R1*]:
- An explicit "update-cache [--add] [--remove] path" should
be taken as a signal from the user (or Cogito) to tell the
dircache layer "the merge is done and here is the result".
So just delete higher-order stages for the path and record
th
I have nothing further to contribute to this subtopic.
Good luck with it.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373,
1.925.600.0401
-
To unsubscribe from this list: se
Paul Jackson wrote:
Junio wrote:
Sounds like svn
I have no idea what svn is.
svn = common abbreviation for "Subversion", a
widely-used centralized SCM tool intentionally
similar to CVS.
--- David A. Wheeler
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message
* Daniel Barkalow <[EMAIL PROTECTED]> wrote:
> Still leaks a bit of memory due to bug copied from read-tree.
Linus, should i resend the 18 fixes i sent the other day? (as a GIT
repository perhaps?) I found roughly 6 common memory leaks, 8
theoretical memory leaks, 2 overflows and did a couple
On Sat, 16 Apr 2005, Paul Jackson wrote:
>
> Morten wrote:
> > It makes some sense in principle, but without storing what they mean
> > (i.e., group==?) it certainly makes no sense.
>
> There's no "they" there.
>
> I think Martin's proposal, to which I agreed, was to store a _single_
> bit. I
> "LT" == Linus Torvalds <[EMAIL PROTECTED]> writes:
LT> I've seen this patch now three times, and it's been wrong every single
LT> time. Maybe we should add a comment?
I found out the previous two just after I sent it out. Sorry
about that.
-
To unsubscribe from this list: send the line
> "Tkil" == Tkil <[EMAIL PROTECTED]> writes:
Tkil> but the chance of any collision at all wigs me out.
> "Paul" == Paul Jackson <[EMAIL PROTECTED]> writes:
Paul> Guess you're just going to get wigged out then.
Wig wig. :)
I didn't mean "wigs me out to the point I won't use it" but mo
Paul Jackson wrote:
what I'm talking about is the chance that somewhere, sometime there will
be two different documents that end up with the same hash
I have vastly greater chance of a file colliding due to hardware or
software glitch than a random message digest collision of two legitimate
docume
On Sat, 16 Apr 2005, Paul Jackson wrote:
> Daniel wrote:
> > I'm working off of Linus's tree when not working on scripts, and it
> > doesn't have that section at all.
>
> Ah so - nevermind my README comments then.
Well, actually, I suspect that something like this should go to Pasky. I
really
On Thu, 14 Apr 2005, H. Peter Anvin wrote:
Linus Torvalds wrote:
Even something as simple as "ls -l" has been known to have O(n**2)
behaviour for big directories.
For filesystems with linear directories, sure. For sane filesystems, it
should have O(n log n).
note that default configs of ext2 an
> but the chance of any collision at all wigs me out.
Guess you're just going to get wigged out then.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373,
1.925.600.0401
-
To u
Fixed.
Randy.Dunlap wrote:
On Sat, 16 Apr 2005 20:12:56 -0700 Mike Taht wrote:
| commit b0550573055abcf8ad19dcb8a036c32dd00a3be4
| tree b77882b170769c07732381b9f19ff2dd5c9f1520
| parent 866b4aea9313513612f2b0d66814a2f526d17f21
| author Mike Taht <[EMAIL PROTECTED]> 1113704772 -0700
| committer Mike
David wrote:
> It's a trade-off, I know.
So where do you recommend we make that trade-off?
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373,
1.925.600.0401
-
To unsubscribe
Paul Jackson wrote:
Earlier, hpa wrote:
The base64 version has 2^12 subdirectories instead of 2^8 (I just used 2
characters as the hash key just like the hex version.)
Later, hpa wrote:
Ultimately the question is: do we care about old (broken) filesystems?
I'd imagine we care a little - just not
On Sat, 16 Apr 2005 20:12:56 -0700 Mike Taht wrote:
| commit b0550573055abcf8ad19dcb8a036c32dd00a3be4
| tree b77882b170769c07732381b9f19ff2dd5c9f1520
| parent 866b4aea9313513612f2b0d66814a2f526d17f21
| author Mike Taht <[EMAIL PROTECTED]> 1113704772 -0700
| committer Mike Taht <[EMAIL PROTECTED]>
On Sat, 16 Apr 2005, Junio C Hamano wrote:
>
> When update-cache --refresh replaces an existing cache entry
> with a new one, it forgets to free the original.
I've seen this patch now three times, and it's been wrong every single
time. Maybe we should add a comment?
That active-cache entry you
> "Brian" == Brian O'Mahoney <[EMAIL PROTECTED]> writes:
Brian> (1) I _have_ seen real-life collisions with MD5, in the context
Brian> of Document management systems containing ~10^6 ms-WORD
Brian> documents.
Was this whole-document based, or was it blocked or otherwise chunked?
I'm
>How about building a file list and doing a batch download via 'wget -i
>/tmp/foo'? A quick test (on my ancient wget-1.7) indicates that it reuses
>connectionss when successive URLs point to the same server.
Here's a script that does just that. So there is a burst of individual
wget commands to
commit b0550573055abcf8ad19dcb8a036c32dd00a3be4
tree b77882b170769c07732381b9f19ff2dd5c9f1520
parent 866b4aea9313513612f2b0d66814a2f526d17f21
author Mike Taht <[EMAIL PROTECTED]> 1113704772 -0700
committer Mike Taht <[EMAIL PROTECTED]> 1113704772 -0700
looks my 1878 line patch to convert git to lib
> No, you have to:
How does this compare with the one I posted about 1 hour 30
minuts ago:
tmp=${TMPDIR-/tmp}
tmp=$tmp/gitdiff-do.$RANDOM.$RANDOM.$RANDOM.$$
(umask 077 && mkdir $tmp) || {
echo "Could not create temporary directory! Exiting." 1>&2
No, you have to:
(a) create a unique, pid specific file name /var/tmp/myapp.$$.xyzzy
(b) create it in O_EXCL mode, so you wont smash another's held lock
(b-1) It worked, OK
(b-2) open failed, try ...xyzzz
repeat until (b-1)
There are thousands of examples of how to do this with bash.
Paul Jack
When run on unmerged dircache, show-diff compares the working
file with each non-empty stage for that path. Two out of three
times, this is not very helpful. This patch makes it report the
unmergedness only once per each path and avoids running the
actual diff.
Upper layer SCMs like Cogito are e
This fixes some stylistic problems introduced by my previous set
of patches. I'll be sending my last patch to show-diff next,
which depends on this cleanup.
To be applied on top of my previous patches:
[PATCH] Optionally tell show-diff to show only named files.
[PATCH] show-diff -z optio
Morten wrote:
> It makes some sense in principle, but without storing what they mean
> (i.e., group==?) it certainly makes no sense.
There's no "they" there.
I think Martin's proposal, to which I agreed, was to store a _single_
bit. If any of the execute permissions of the incoming file are set
Oops, sorry I screwed up and sent a wrong patch. Please discard
the previous one.
The show-diff command uses a variable "new" but it is always
used to point at the original data recorded in the dircache
before the user started editing in the working file. Rename it
to "old" to avoid confusion.
Erik wrote:
> How about putting using .git/tmp.$$ or similar as tempfile?
One could, but best to normally honor the users TMPDIR setting.
Could one 'git diff' a readonly git repository?
Perhaps someone has a reason for putting their tmp files where
they choose - say a local file system in a heav
Dave wrote:
> http://www.linuxsecurity.com/content/view/115462/151/
Nice - thanks.
Pasky - would you be interested in a patch that used a more robust tmp
file creation, along the lines of replacing
t=${TMPDIR:-/usr/tmp}/gitdiff.$$
trap 'set +f; rm -fr $t.?; trap 0; exit 0' 0 1 2
The show-diff command uses a variable "new" but it is always
used to point at the original data recorded in the dircache
before the user started editing in the working file. Rename it
to "old" to avoid confusion.
To be applied on top of my previous patches:
[PATCH] Optionally tell show-diff
set your umask to make things only writeable by the same user.
then create a new directory (it will fail with an error if the directory
already exists)
now you can create files in this directory without having to worry about
other users makeing trouble for you (they can't create symlinks in this
> Does it really make sense to store full permissions in the trees? I think
> that remembering the x-bit should be good enough for almost all purposes
> and the other permissions should be left to the local environment.
It makes some sense in principle, but without storing what they mean
(i.e., gr
Junio wrote:
> The command line for running "diff" command is built without
> taking shell metacharacters into account.
Ack - you're right. One should avoid popen and system
in all but personal hacking code. There are many ways,
beyond just embedded shell redirection, to cause problems
with the
On Sat, Apr 16, 2005 at 05:44:09PM -0700, Paul Jackson wrote:
> Dave wrote:
> > mktemp is being used here to provide randomness in the filename,
> > not just a uniqueness.
>
> Ok - useful point.
>
> How about:
>
> t=${TMPDIR:-/usr/tmp}/gitdiff.$$.$RANDOM
pid is still predictable b
On Sat, Apr 16, 2005 at 08:33:25PM -0400, Dave Jones wrote:
> On Sat, Apr 16, 2005 at 05:02:21PM -0700, Paul Jackson wrote:
> > > And racy. And not guaranteed to come up with fresh new files.
> >
> > In theory perhaps. In practice no.
> >
> > Even mktemp(1) can collide, in theory, since the
Daniel wrote:
> I'm working off of Linus's tree when not working on scripts, and it
> doesn't have that section at all.
Ah so - nevermind my README comments then.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jacks
Dave wrote:
> mktemp is being used here to provide randomness in the filename,
> not just a uniqueness.
Ok - useful point.
How about:
t=${TMPDIR:-/usr/tmp}/gitdiff.$$.$RANDOM
> all an attacker has to do is create 65535 symlinks in /usr/tmp
And how about if I removed the tmp files at th
On Sat, 16 Apr 2005, Paul Jackson wrote:
> > Needs libcurl post 7.7 or so.
>
> That could be mentioned in the README, which has a list of 'Software
> requirements.' Actually, zlib-devel and openssl should be on this list
> as well. My laziness got in the way of my sending in a patch for that.
The command line for running "diff" command is built without
taking shell metacharacters into account. A malicious dircache
entry "foo 2>bar" (yes, a filename with space) would result in
creating a file called "bar" with the error message "diff: foo:
No such file or directory" in it.
This is not
On Sat, Apr 16, 2005 at 05:02:21PM -0700, Paul Jackson wrote:
> > And racy. And not guaranteed to come up with fresh new files.
>
> In theory perhaps. In practice no.
>
> Even mktemp(1) can collide, in theory, since there is no practical way
> in shell scripts to hold open and locked the f
> Needs libcurl post 7.7 or so.
That could be mentioned in the README, which has a list of 'Software
requirements.' Actually, zlib-devel and openssl should be on this list
as well. My laziness got in the way of my sending in a patch for that.
--
I won't rest till it's the bes
This enables the use of HTTP to download commits and associated objects
from remote repositories. It now uses libcurl instead of local hack code.
Still causes warnings for fsck-cache and rev-tree, due to unshared code.
Still leaks a bit of memory due to bug copied from read-tree.
Needs libcurl p
Petr wrote:
> Please don't reindent the scripts. It violates the current coding style
> and the patch is unreviewable.
Sorry - I had not realized that there was a style in this case.
I am all in favor of such coding styles, and will gladly fit this one.
Do you want the patch resent, or a patch t
On Sun, 17 Apr 2005, Petr Baudis wrote:
> Dear diary, on Sat, Apr 16, 2005 at 05:17:00AM CEST, I got a letter
> where Daniel Barkalow <[EMAIL PROTECTED]> told me that...
> > On Sat, 16 Apr 2005, Petr Baudis wrote:
> >
> > > Dear diary, on Sat, Apr 16, 2005 at 04:47:55AM CEST, I got a letter
> > >
Junio wrote:
> Sounds like svn
I have no idea what svn is.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373,
1.925.600.0401
-
To unsubscribe from this list: send the line "
> And racy. And not guaranteed to come up with fresh new files.
In theory perhaps. In practice no.
Even mktemp(1) can collide, in theory, since there is no practical way
in shell scripts to hold open and locked the file from the instant of it
is determined to be a unique name.
The window of vul
Daniel Barkalow wrote:
On Sat, 16 Apr 2005, Adam Kropelin wrote:
How about building a file list and doing a batch download via 'wget
-i /tmp/foo'? A quick test (on my ancient wget-1.7) indicates that
it reuses connectionss when successive URLs point to the same server.
You need to look at some of t
> /usr/tmp/ ??? Hey, /usr may be mounted read-only! Why not just use /tmp ?
Sure - that's fine to change. Those that care will have TMPDIR set anyway.
I probably made that choice of /usr/tmp for the fallback 10 or 20 years
ago, and have never had reason to revisit it. I have long forgotten why
Dear diary, on Sun, Apr 17, 2005 at 01:07:35AM CEST, I got a letter
where Daniel Barkalow <[EMAIL PROTECTED]> told me that...
> > Actually, what about if git pull outside of repository did what git
> > clone does now? I'd kinda like clone instead of fork too.
>
> This seems like the best solution
Dear diary, on Sun, Apr 17, 2005 at 01:28:04AM CEST, I got a letter
where Paul Jackson <[EMAIL PROTECTED]> told me that...
> Reduce number of subcommands execv'd by a
> third, by only calling 'rm' once, at end, not each
> loop.
The idea behind that was that diffing could take a significant portion
> "PJ" == Paul Jackson <[EMAIL PROTECTED]> writes:
PJ> That matches my experience - store 1 bit of mode state - executable or not.
Sounds like svn ;-).
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http:
Dear diary, on Sun, Apr 17, 2005 at 01:27:43AM CEST, I got a letter
where Paul Jackson <[EMAIL PROTECTED]> told me that...
> Remove mktemp usage - it doesn't work on
> some Mandrakes, nor on my SuSE 8.2 with
> mktemp-1.5-531.
>
> Replace with simple use of $$ (pid).
> I've been using this same pat
On Sat, 2005-04-16 16:27:43 -0700, Paul Jackson <[EMAIL PROTECTED]>
wrote in message <[EMAIL PROTECTED]>:
> Index: git-pasky-0.4/gitcommit.sh
> ===
> --- git-pasky-0.4.orig/gitcommit.sh 2005-04-12 10:39:14.0 -0700
> +++ git-p
Dear diary, on Sat, Apr 16, 2005 at 05:17:00AM CEST, I got a letter
where Daniel Barkalow <[EMAIL PROTECTED]> told me that...
> On Sat, 16 Apr 2005, Petr Baudis wrote:
>
> > Dear diary, on Sat, Apr 16, 2005 at 04:47:55AM CEST, I got a letter
> > where Petr Baudis <[EMAIL PROTECTED]> told me that..
This patch adds the -z option to the show-diff command,
primarily for use by scripts. The information emitted is
similar to that of -q option, but in a more machine readable
form. Records are terminated with NUL instead of LF, so that
the scripts can deal with pathnames with embedded newlines.
T
First mkdir in gitdiff-do missing -p, so useless error
Signed-off-by: Paul Jackson <[EMAIL PROTECTED]>
Index: git-pasky-0.4/gitdiff-do
===
--- git-pasky-0.4.orig/gitdiff-do 2005-04-16 13:18:29.0 -0700
+++ git-pasky-0.4/
Remove mktemp usage - it doesn't work on
some Mandrakes, nor on my SuSE 8.2 with
mktemp-1.5-531.
Replace with simple use of $$ (pid).
I've been using this same pattern for
20 years on many production scripts;
it's fast, solid and simple.
More robust tmp file removal, using trap,
so that scripts i
Rewrite gitdiff-do so that it works with arbitrary
whitespace (space, tab, newline, ...) in filenames.
Reduce number of subcommands execv'd by a
third, by only calling 'rm' once, at end, not each
loop.
Avoid using shell arrays; perhaps more portable.
Avoid 'echo -e' when displaying names; dont e
Martin wrote:
> Does it really make sense to store full permissions in the trees? I think
> that remembering the x-bit should be good enough for almost all purposes
> and the other permissions should be left to the local environment.
That matches my experience - store 1 bit of mode state - executa
Hi!
> We've already computed the chances of a random pure hash collision
> with SHA1 - it's something like an average of 1 collision every
> 10 billion years if we have 10,000 coders generating 1 new file
> version every minute, non-stop, 24 hours a day, 365 days a year.
GIT is safe even for the
SCMs have ways to say "I want diff only this particular file",
or "I want diff files under this directory". This patch teaches
show-diff to do something similar. Without command line
arguments, it still examines everything in the dircache as
before.
Signed-off-by: Junio C Hamano <[EMAIL PROTECTE
> sysadmins realize that there are an infinante number of files that map to
Sysadmins know that there are an infinite ways for their
systems to crap out, and try to cover for the ones that
there is a snow balls chance in Hades of them seeing in
their lifetime.
--
I won't rest
> what I'm talking about is the chance that somewhere, sometime there will
> be two different documents that end up with the same hash
I have vastly greater chance of a file colliding due to hardware or
software glitch than a random message digest collision of two legitimate
documents.
I've lost
On Sat, 16 Apr 2005, Thomas Gleixner wrote:
On Sat, 2005-04-16 at 10:04 -0700, Linus Torvalds wrote:
So I'd _almost_ suggest just starting from a clean slate after all.
Keeping the old history around, of course, but not necessarily putting it
into git now. It would just force everybody who is getti
On Sun, 17 Apr 2005, Petr Baudis wrote:
> Dear diary, on Sat, Apr 16, 2005 at 05:06:54AM CEST, I got a letter
> where Daniel Barkalow <[EMAIL PROTECTED]> told me that...
>
> > I think "fork" is as good as anything for describing the operation. I had
> > thought about "clone" because it seemed to f
On Sat, 16 Apr 2005, Linus Torvalds wrote:
Almost all attacks on sha1 will depend on _replacing_ a file with a bogus
new one. So guys, instead of using sha256 or going overboard, just make
sure that when you synchronize, you NEVER import a file you already have.
It's really that simple. Add "--igno
Hi Linus et al.,
I'm trying to use git, but I frequenty run into problems with file permissions
-- some archives (including the master git archive) contain group-writable
files, but when I check them out, the permissions get trimmed by my umask
(quite sensibly) and update-cache complains that they
Dear diary, on Sat, Apr 16, 2005 at 05:06:54AM CEST, I got a letter
where Daniel Barkalow <[EMAIL PROTECTED]> told me that...
> On Sat, 16 Apr 2005, Petr Baudis wrote:
> > I'm sorry but you are late, I added it about a hour and half ago or so.
> > :-) Check git fork. (I *want* separate command than
Ok, nobody really objected to the notion of leaving the kernel history
behind for now, and in fact most people seemed to basically agree. So with
that decided, the old kernel testing tree was actually perfectly ok,
except it had been build up with the old-style commit date handling, which
made me
On Sat, 16 Apr 2005, C. Scott Ananian wrote:
Date: Sat, 16 Apr 2005 11:36:28 -0400 (EDT)
From: C. Scott Ananian <[EMAIL PROTECTED]>
To: Petr Baudis <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED], David Lang <[EMAIL PROTECTED]>,
Ingo Molnar <[EMAIL PROTECTED]>, git@vger.kernel.org
Subject: Re: Re: SH
Hello,
just thought that I should drop a line here about it. I recently
changed the .git/HEAD to be a symlink, and old git pull could not cope
with that. So you would get a small error and no updates.
So far I fixed it by just making it a hardlink in my tree for now;
don't do that at home t
Hi,
I can publish the stuff on monday from a university nearby.
---
total blob objects = 228384
total tree objects = 172507
total commit objects = 55877
The "empty" changesets which are noting merges are omitted at the
moment. Is it of interest to include them ??
It might also be interes
When update-cache --refresh replaces an existing cache entry
with a new one, it forgets to free the original.
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---
update-cache.c: 61d2b93a751f35ba24f479cd4fc151188916f02a
--- update-cache.c
+++ update-cache.c 2005-04-16 15:49:03.0 -07
that's the difference between CS researchers and sysadmins.
sysadmins realize that there are an infinante number of files that map to
the same hash value and plan accordingly (becouse we KNOW we will run
across them eventually), and don't see it as a big deal when we finally
do.
CS researches q
On Sat, 16 Apr 2005, Adam Kropelin wrote:
> Tony Luck wrote:
> > Otherwise this looks really nice. I was going to script something
> > similar using "wget" ... but that would have made zillions of seperate
> > connections. Not so kind to the server.
>
> How about building a file list and doing
On Sun, 17 Apr 2005, Martin Mares wrote:
> Hello!
>
> > This adds a program to download a commit, the trees, and the blobs in them
> > from a remote repository using HTTP. It skips anything you already have.
>
> Is it really necessary to write your own HTTP downloader? If so, is it
> necessary t
Tony Luck wrote:
Otherwise this looks really nice. I was going to script something
similar using "wget" ... but that would have made zillions of seperate
connections. Not so kind to the server.
How about building a file list and doing a batch download via 'wget -i
/tmp/foo'? A quick test (on my
On Sat, 16 Apr 2005, David Roundy wrote:
>
> I've been thinking about the possibility of using the git "current
> directory cache" code in darcs.
Go wild. The license is GPLv2, with the limitation that I really do want
to see v3 before I re-license anything at all, so if you take it into
darcs,
On Sun, 17 Apr 2005, Jan-Benedict Glaw wrote:
> On Sat, 2005-04-16 18:03:51 -0400, Daniel Barkalow <[EMAIL PROTECTED]>
> wrote in message <[EMAIL PROTECTED]>:
> > --- /dev/null (tree:ed4f6e454b40650b904ab72048b2f93a068dccc3)
> > +++ a65375b46154c90e7499b7e76998d430cd9cd29d/http-get.c (mode:10064
On Sat, 16 Apr 2005, Brian O'Mahoney wrote:
Three points:
(1) I _have_ seen real-life collisions with MD5, in the context of
Document management systems containing ~10^6 ms-WORD documents.
(2) The HMAC (ethernet-harware-address) of any interface _should_
help to make a unique Id.
you want a u
On Sat, 16 Apr 2005, Tony Luck wrote:
> On 4/16/05, Daniel Barkalow <[EMAIL PROTECTED]> wrote:
> > +buffer = read_sha1_file(sha1, type, &size);
>
> You never free this buffer.
Ideally, this should all be rearranged to share the code with
read-tree, and it should be fixed in common.
> It
On Sat, 2005-04-16 18:03:51 -0400, Daniel Barkalow <[EMAIL PROTECTED]>
wrote in message <[EMAIL PROTECTED]>:
> --- /dev/null (tree:ed4f6e454b40650b904ab72048b2f93a068dccc3)
> +++ a65375b46154c90e7499b7e76998d430cd9cd29d/http-get.c (mode:100644
> sha1:6a36cfa079519a7a3ad5b1618be8711c5127b531)
>
On 4/16/05, Daniel Barkalow <[EMAIL PROTECTED]> wrote:
> +buffer = read_sha1_file(sha1, type, &size);
You never free this buffer.
It would also be nice if you saved "tree" objects in some temporary file
and did not install them until after you had fetched all the blobs and
trees that this
Hello!
> This adds a program to download a commit, the trees, and the blobs in them
> from a remote repository using HTTP. It skips anything you already have.
Is it really necessary to write your own HTTP downloader? If so, is it
necessary to forget basic stuff like the "Host:" header? ;-)
If yo
This adds a program to download a commit, the trees, and the blobs in them
from a remote repository using HTTP. It skips anything you already have.
There are a number of improvements possible, to be done if this catches
on, including, significantly, checking if the response was correct (or
even no
Please see below:
C. Scott Ananian wrote:
> On Sat, 16 Apr 2005, Brian O'Mahoney wrote:
>
>> (1) I _have_ seen real-life collisions with MD5, in the context of
>>Document management systems containing ~10^6 ms-WORD documents.
>
>
> Dude! You could have been *famous*! Why the
> aitch-ee-do
On Sat, 16 Apr 2005, Sanjoy Mahajan wrote:
>
> I like this elegant approach, but clever pattern matching can help even
> at commit time. Suppose hello.c is simply:
Here, what you're talking about is not "commit", but "merge".
The git model very much separates the two events. You first generat
> And that "where did this come from" decision should be done at _search_
> time, not commit time.
I like this elegant approach, but clever pattern matching can help even
at commit time. Suppose hello.c is simply:
printf ("Hello %d\n", year);
And then developer A updates hello.c to:
printf
On Sat, 16 Apr 2005, Mike Taht wrote:
> Junio C Hamano wrote:
> >>"MT" == Mike Taht <[EMAIL PROTECTED]> writes:
> >
> >
> > MT> alternatively, "git-archive-torrent" to create a list of files for a
> > MT> bittorrent feed
> >
> > That is certainly good for establishing the baseline, but
> "CL" == Christopher Li <[EMAIL PROTECTED]> writes:
CL> I bet 90% of the time people sync to the repository head first
CL> want to check out the last bits. And maybe reading some change
CL> log to see what is changed.
CL> So having all the commit object, the user will able to see
CL> what is
1 - 100 of 164 matches
Mail list logo
