LT == Linus Torvalds [EMAIL PROTECTED] writes:
LT Damn, my cunning plan is some good stuff.
I really like this a lot. It is *so* *simple*, clear, flexible
and an example of elegance. This is one of the things I would
happily say Sheesh! Why didn't *I* think of *THAT*
first!!!
Hi,
It seems that there's something weird going on with the file mode
handling. Firstly, some files in the git-pasky repository have mode
0664 while others have 0644.
Having pulled from git-pasky a number of times, with Petr's being the
tracked repository, I now find that when I do an
JNH == Junio C Hamano [EMAIL PROTECTED] writes:
LT == Linus Torvalds [EMAIL PROTECTED] writes:
LT I should make ls-files have a -l format, which shows the
LT index and the mode for each file too.
JNH You probably meant ls-tree. You used the word mode but it
JNH already shows the mode so I
This adds --stage option to show-files command. It shows
file-mode, SHA1, stage and pathname. Record separator follows
the usual convention of -z option as before.
The patch is on top of the byte order fix for create_ce_flags in my
previous message.
Signed-off-by: Junio C Hamano [EMAIL
Dear diary, on Sat, Apr 16, 2005 at 05:16:12AM CEST, I got a letter
where Linus Torvalds [EMAIL PROTECTED] told me that...
On Sat, 16 Apr 2005, Petr Baudis wrote:
I'm wondering, whether each tree should be fixed to a certain branch.
I'm wondering why you talk about branches at all.
No
On Fri, Apr 15, 2005 at 08:32:46AM -0700, Linus Torvalds wrote:
In other words, I'm right. I'm always right, but sometimes I'm more
right
than other times. And dammit, when I say files don't matter, I'm
really
really Right(tm).
You're right, of course (All Hail Linus!), if you can make it work
we alrady have the concept of objects that contain objects and therefor
don'e need to be re-checked (directories), the chunks inside a file could
be the same type of thing.
currently we say that if the hash on the directory is the same we don't
need to re-check each of the files in that
* David Lang [EMAIL PROTECTED] wrote:
this issue was raised a few days ago in the context of someone
tampering with the files and it was decided that the extra checks were
good enough to prevent this (at least for now), but what about
accidental collisions?
if I am understanding things
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.
(3) While I havn't looked at the details of the
In this message, a method to simplify and at the same time make more
powerful the git abstraction is presented.
I believe that the enhancements I propose make git adhere even more to
its spirit and make it more intuitive.
The proposal makes it much easier to build an SCM over git, obtaining in
* Ingo Molnar [EMAIL PROTECTED] wrote:
the patches contain all the existing metadata, dates, log messages and
revision history. (What i think is missing is the BK tree merge
information, but i'm not sure we want/need to convert them to GIT.)
author names are abbreviated, e.g. 'viro'
Dear diary, on Sat, Apr 16, 2005 at 11:45:59AM CEST, I got a letter
where Russell King [EMAIL PROTECTED] told me that...
Hi,
Hello,
It seems that there's something weird going on with the file mode
handling. Firstly, some files in the git-pasky repository have mode
0664 while others have
Ingo Molnar [EMAIL PROTECTED] :
[...]
the history data starts at 2.4.0 and ends at 2.6.12-rc2. I've included a
script that will apply all the patches in order and will create a
pristine 2.6.12-rc2 tree.
127 weeks of bk-commit mail for the 2.6 branch alone since october 2002
provides more
Dear diary, on Sat, Apr 16, 2005 at 04:58:15PM CEST, I got a letter
where C. Scott Ananian [EMAIL PROTECTED] told me that...
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
On Sat, 16 Apr 2005, Junio C Hamano wrote:
LT NOTE NOTE NOTE! I could make read-tree do some of these nontrivial
LT merges, but I ended up deciding that only the matches in all three
LT states thing collapses by default.
* Understood and agreed.
Having slept on it, I think I'll merge
Hi,
On Fri, 15 Apr 2005, David Woodhouse wrote:
But if it can be done cheaply enough at a later date even though we end
up repeating ourselves, and if it can be done _well_ enough that we
shouldn't have just asked the user in the first place, then yes, OK I
agree.
The repetition could be
On Sat, Apr 16, 2005 at 06:03:33PM +0200, Petr Baudis wrote:
Dear diary, on Sat, Apr 16, 2005 at 05:55:37PM CEST, I got a letter
where Simon Fowler [EMAIL PROTECTED] told me that...
On Sat, Apr 16, 2005 at 05:19:24AM -0700, David Lang wrote:
Simon
given that you have multiple
On Sat, 16 Apr 2005, Linus Torvalds wrote:
Having slept on it, I think I'll merge all the trivial cases that don't
involve a file going away or being added. Ie if the file is in all three
trees, but it's the same in two of them, we know what to do.
Junio, I pushed this out, along with
On Sat, 16 Apr 2005, Ingo Molnar wrote:
i've converted the Linux kernel CVS tree into 'flat patchset' format,
which gave a series of 28237 separate patches. (Each patch represents a
changeset, in the order they were applied. I've used the cvsps utility.)
the history data starts at
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 getting used to git in
the first place
Dear diary, on Sat, Apr 16, 2005 at 09:23:40PM CEST, I got a letter
where Thomas Gleixner [EMAIL PROTECTED] told me that...
One remark on the tree blob storage format.
The binary storage of the sha1sum of the refered object is a PITA for
scripting.
Converting the ASCII - binary for the
* A script git-archive-tar is used to create a base tarball
that roughly corresponds to linux-*.tar.gz. This works as
follows:
$ git-archive-tar C [B1 B2...]
This reads the named commit C, grabs the associated tree
(i.e. its sub-tree objects and the blob they refer to), and
Dear diary, on Sat, Apr 16, 2005 at 08:32:32PM CEST, I got a letter
where Petr Baudis [EMAIL PROTECTED] told me that...
Dear diary, on Sat, Apr 16, 2005 at 09:23:40PM CEST, I got a letter
where Thomas Gleixner [EMAIL PROTECTED] told me that...
One remark on the tree blob storage format.
The
On Sat, 2005-04-16 at 20:32 +0200, Petr Baudis wrote:
Dear diary, on Sat, Apr 16, 2005 at 09:23:40PM CEST, I got a letter
where Thomas Gleixner [EMAIL PROTECTED] told me that...
One remark on the tree blob storage format.
The binary storage of the sha1sum of the refered object is a PITA for
On Sat, 16 Apr 2005, Thomas Gleixner wrote:
One remark on the tree blob storage format.
The binary storage of the sha1sum of the refered object is a PITA for
scripting.
Converting the ASCII - binary for the sha1sum comparision should not
take much longer than the binary - ASCII
JCH == Junio C Hamano [EMAIL PROTECTED] writes:
JCH I have been cooking this idea before I dove into the merge stuff
JCH and did not have time to implement it myself (Hint Hint), but I
JCH think something along the following lines would work nicely:
It should be fairly obvious from the context
On Sat, 2005-04-16 at 11:44 -0700, Linus Torvalds wrote:
That level of abstraction (we never look directly at the objects) is
what allows us to change the object structure later. For example, we
already changed the commit date thing once, and the tree object has
obviously evolved a bit,
On Sat, Apr 16, 2005 at 07:43:27PM +0200, Petr Baudis wrote:
Dear diary, on Sat, Apr 16, 2005 at 07:04:31PM CEST, I got a letter
where Linus Torvalds [EMAIL PROTECTED] told me that...
So I'd _almost_ suggest just starting from a clean slate after all.
Keeping the old history around, of
On Sat, 2005-04-16 10:04:31 -0700, Linus Torvalds [EMAIL PROTECTED]
wrote in message [EMAIL PROTECTED]:
What do people think? I'm not so much worried about the data itself: the
git architecture is _so_ damn simple that now that the size estimate has
been confirmed, that I don't think it would
On Sat, 16 Apr 2005, Thomas Gleixner wrote:
For the export stuff its terrible slow. :(
I don't really see your point.
If you already know what the tree is like you say, you don't care about
the tree object. And if you don't know what the tree is, what _are_ you
doing?
In other words, show
* David Mansfield [EMAIL PROTECTED] wrote:
Ingo Molnar wrote:
* Ingo Molnar [EMAIL PROTECTED] wrote:
the patches contain all the existing metadata, dates, log messages and
revision history. (What i think is missing is the BK tree merge
information, but i'm not sure we want/need to
* Linus Torvalds [EMAIL PROTECTED] wrote:
the history data starts at 2.4.0 and ends at 2.6.12-rc2. I've included a
script that will apply all the patches in order and will create a
pristine 2.6.12-rc2 tree.
Hey, that's great. I got the CVS repo too, and I was looking at it,
but the
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 you
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 would
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 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 to forget
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 a batch
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
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
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
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 fill the role
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
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
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
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 PROTECTED]
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
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
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
+++
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.
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...
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
+++
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 pattern
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
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 to me,
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
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
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
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
where Petr
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 to
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
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
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 file
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 there is no
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 these
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.,
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 to
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
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
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.
To
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,
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
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
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. 12
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 libgit
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
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 wondering,
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
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]
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
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
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
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
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 and
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 see my
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
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
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 any of the
* 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 of
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 to
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:
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
the
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 merging
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
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 ;).
--
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,
This is my bad. I added #include ctype.h 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 @@
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:
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
+++
98 matches
Mail list logo