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 any
Ok.. so there's been a couple attempts to patch the leak that were all
wrong due to mixed memory management for that array. Here's a seed for
discussion on how to plug that leak. Some would argue that it's not
leaking enough to fix, but for those that want to turn git into a library,
the
Converted git to libgit. Moved all the main() calls into a single
multi-call binary - git-main.
Made extern a bunch of functions that were static. Verified it at least
still minimally worked.
Note: this is only a first step towards creating a generic library.
Figuring out what functions and
David wrote:
There's a minor reason to write out ALL the perm bit data, but
There's always the 'configurable option' approach.
Someone, I doubt Linus will have any interest in it, could volunteer to
make the masks of st_mode, used when storing and recovering file
permissions, be configurable by
David wrote:
My list would be:
ext2, ext3, NFS, and Windows' NTFS (stupid short filenames,
case-insensitive/case-preserving).
I'm no mind reader, but I'd bet a pretty penny that what you have in
mind and what Linus has in mind have no overlaps in their solution sets.
Happy coding ...
--
The checkout-cache command says file is not in the cache when
an unmerged path is given. This patch adds code to distinguish
the unmerged and the nonexistent cases and gives an appropriate
error message.
Signed-off-by: Junio C Hamano [EMAIL PROTECTED]
---
checkout-cache.c | 11 +--
1
Earlier I wrote down a list of issues your recent merge
stage changes have introduced to the rest of the plumbing, with
a set of suggested adaptions. I think all of them are cleared
now (you have a pile of patches from me in your mailbox).
I do not know what percentage of people on this list are
The function index_fd() in update-cache.c takes 5 arguments, but
two is not necessary and one that is a pointer to a structure
really needs to be a pointer to one member of that structure.
This patch cleans it up.
Also it removes printf() apparently left after initial
debugging.
Signed-off-by:
I've made my tree rsync'able:
rsync://gameboy2.puremagic.com/git
commit 1cdbc0a19b8d9b68f1f42735e2f14f1289823a63
tree 0e060fed0642337e675368913ec8d4f910a9f019
parent 11ed64c1b141c9ba397a1ca76aef2cd250976007
author Brad Roberts,,, [EMAIL PROTECTED] 1113736632 -0700
committer Brad Roberts,,,
Hi,
the following patch fixes show-diff listing all +x files as differring.
Signed-off-by: Petr Baudis [EMAIL PROTECTED]
--- read-cache.c
+++ read-cache.c2005-04-17 13:42:13.322938268 +0200
@@ -306,7 +306,7 @@
ce-ce_gid != htonl(st-st_gid))
changed |=
(ok, author looks better, but committer doesn't obey the AUTHOR_ vars yet)
This might not be how you intended git fork to behave, but without doing
_something_ to protect the head parameter a bit, this is just asking for a
corrutped .git/HEAD file.
commit 76faec069dfeae59c3ce5faaad10bdcded0cc908
Index: gitfork.sh
===
--- 51b1bddbbc05e50d5bbf1f9662e503c2e85d5e96/gitfork.sh (mode:100755
sha1:e5692ea9bdbc39b028fe1e1205381da632541bab)
+++ c291316b28eff4042c80850cd93445345a606835/gitfork.sh (mode:100755
On Sat, 2005-04-16 at 17:33 +0200, Johannes Schindelin 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
Dear diary, on Sun, Apr 17, 2005 at 07:36:51AM CEST, I got a letter
where Steven Cole [EMAIL PROTECTED] told me that...
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
On Sat, Apr 16, 2005 at 04:01:45PM -0700, Linus Torvalds wrote:
So I re-created the dang thing (hey, it takes just a few minutes), and
pushed it out, and there's now an archive on kernel.org in my public
personal directory called linux-2.6.git. I'll continue the tradition
of naming git-archive
merge-base finds one of the best common ancestors of a pair of commits. In
particular, it finds one of the ones which is fewest commits away from the
further of the heads.
Signed-Off-By: Daniel Barkalow [EMAIL PROTECTED]
Index: Makefile
* Ingo Molnar [EMAIL PROTECTED] wrote:
The compromise relies on you having reviewed something harmless, while
in reality what happened within the DB was far less harmless. And the
DB remains self-consistent: neither fsck, nor others importing your
tree will be able to detect the
http-pull is a program that downloads from a (normal) HTTP server a commit
and all of the tree and blob objects it refers to (but not other commits,
etc.). Options could be used to make it download a larger or different
selection of objects. It depends on libcurl, which I forgot to mention in
the
On Sun, 17 Apr 2005, Stefan-W. Hahn wrote:
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.
Actually, it is.
On Sun, 17 Apr 2005, David A. Wheeler wrote:
There's a minor reason to write out ALL the perm bit data, but
only care about a few bits coming back in: Some people use
SCM systems as a generalized backup system
Yes. I was actually thinking about having system config files in a git
Dear diary, on Sun, Apr 17, 2005 at 05:24:20PM CEST, I got a letter
where Daniel Barkalow [EMAIL PROTECTED] told me that...
This adds support to revision.h for parsing commit records (but not going
any further than parsing a single record). Something like this is needed
by anything that uses
Linus Torvalds wrote:
On Sun, 17 Apr 2005, David A. Wheeler wrote:
There's a minor reason to write out ALL the perm bit data, but
only care about a few bits coming back in: Some people use
SCM systems as a generalized backup system
Yes. I was actually thinking about having system config files in a
On Sun, 17 Apr 2005, David Roundy wrote:
That's all right. Darcs would only access the cached data through a
git-caching layer, and we've already got an abstraction layer over the
pristine cache. As long as the git layer can quickly retrieve the contents
of a given file, we should be
Dear diary, on Sun, Apr 17, 2005 at 05:24:48PM CEST, I got a letter
where Russell King [EMAIL PROTECTED] told me that...
However, I've made a start to generate the necessary emails. How about
this format?
I'm not keen on the tree, parent, author and committer objects appearing
in this -
On Sun, 17 Apr 2005, Russell King wrote:
On Sat, Apr 16, 2005 at 04:01:45PM -0700, Linus Torvalds wrote:
So I re-created the dang thing (hey, it takes just a few minutes), and
pushed it out, and there's now an archive on kernel.org in my public
personal directory called linux-2.6.git.
On Sun, 17 Apr 2005, Russell King wrote:
BTW, there appears to be errors in the history committed thus far.
I'm not sure where this came from though. Some of them could be
UTF8 vs ASCII issues, but there's a number which seem to have extra
random crap in them (^M) and lots of blank
Stefan-W. Hahn wrote:
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.
Should be:
...
Committer-Dater: 1113684324
Linus Torvalds wrote:
On Sun, 17 Apr 2005, David Roundy wrote:
That's all right. Darcs would only access the cached data through a
git-caching layer, and we've already got an abstraction layer over the
pristine cache. As long as the git layer can quickly retrieve the contents
of a given file, we
merge-base finds one of the best common ancestors of a pair of commits. In
particular, it finds one of the ones which is fewest commits away from the
further of the heads.
Signed-Off-By: Daniel Barkalow [EMAIL PROTECTED]
Index: Makefile
On Sun, 17 Apr 2005, Brad Roberts wrote:
(ok, author looks better, but committer doesn't obey the AUTHOR_ vars yet)
They should't, but maybe I should add COMMITTER_xxx overrides. I just do
_not_ want people to think that they should claim to be somebody else:
it's not a security issue (you
On Sun, 17 Apr 2005, Linus Torvalds wrote:
On Sun, 17 Apr 2005, Brad Roberts wrote:
(ok, author looks better, but committer doesn't obey the AUTHOR_ vars yet)
They should't, but maybe I should add COMMITTER_xxx overrides. I just do
_not_ want people to think that they should claim to be
Dear diary, on Sun, Apr 17, 2005 at 05:35:19PM CEST, I got a letter
where Daniel Barkalow [EMAIL PROTECTED] told me that...
Index: checkout-cache.c
===
--- 157b46ce1d82b3579e2e1258927b0d9bdbc033ab/checkout-cache.c (mode:100644
Paul Jackson wrote:
David wrote:
My list would be:
ext2, ext3, NFS, and Windows' NTFS (stupid short filenames,
case-insensitive/case-preserving).
I'm no mind reader, but I'd bet a pretty penny that what you have in
mind and what Linus has in mind have no overlaps in their solution sets.
Sadly, I
Dear diary, on Sun, Apr 17, 2005 at 08:13:59PM CEST, I got a letter
where David A. Wheeler [EMAIL PROTECTED] told me that...
On Sun, 17 Apr 2005, Russell King wrote:
BTW, there appears to be errors in the history committed thus far.
I'm not sure where this came from though. Some of them could
On Sun, 17 Apr 2005, Daniel Barkalow wrote:
--- 45f926575d2c44072bfcf2317dbf3f0fbb513a4e/revision.h (mode:100644
sha1:28d0de3261a61f68e4e0948a25a416a515cd2e83)
+++ 37a0b01b85c2999243674d48bfc71cdba0e5518e/revision.h (mode:100644
sha1:523bde6e14e18bb0ecbded8f83ad4df93fc467ab)
@@ -24,6
Dear diary, on Sun, Apr 17, 2005 at 08:38:10AM CEST, I got a letter
where David A. Wheeler [EMAIL PROTECTED] told me that...
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,
On Sun, 17 Apr 2005, Russell King wrote:
One thing which definitely needs to be considered is - what character
encoding are the comments to be stored as?
...
I replied:
I would _heartily_ recommend moving towards UTF-8 as the
internal charset for all comments.
Petr said:
Not that the plumbing
On Sun, 17 Apr 2005, Petr Baudis wrote:
Index: Makefile
===
--- d662b707e11391f6cfe597fd4d0bf9c41d34d01a/Makefile (mode:100644
sha1:b2ce7c5b63fffca59653b980d98379909f893d44)
+++
http-pull is a program that downloads from a (normal) HTTP server a commit
and all of the tree and blob objects it refers to (but not other commits,
etc.). Options could be used to make it download a larger or different
selection of objects.
Signed-Off-By: Daniel Barkalow [EMAIL PROTECTED]
Index:
On Sun, Apr 17, 2005 at 09:36:09AM -0700, Linus Torvalds wrote:
On Sun, 17 Apr 2005, Russell King wrote:
On Sat, Apr 16, 2005 at 04:01:45PM -0700, Linus Torvalds wrote:
So I re-created the dang thing (hey, it takes just a few minutes), and
pushed it out, and there's now an archive on
Dear diary, on Sun, Apr 17, 2005 at 08:49:11PM CEST, I got a letter
where Daniel Barkalow [EMAIL PROTECTED] told me that...
On Sun, 17 Apr 2005, Petr Baudis wrote:
Index: http-pull.c
===
--- /dev/null
On Sun, 17 Apr 2005, Linus Torvalds wrote:
On Sun, 17 Apr 2005, Daniel Barkalow wrote:
--- 45f926575d2c44072bfcf2317dbf3f0fbb513a4e/revision.h (mode:100644
sha1:28d0de3261a61f68e4e0948a25a416a515cd2e83)
+++ 37a0b01b85c2999243674d48bfc71cdba0e5518e/revision.h (mode:100644
On Sun, 17 Apr 2005, Petr Baudis wrote:
Dear diary, on Sun, Apr 17, 2005 at 08:49:11PM CEST, I got a letter
where Daniel Barkalow [EMAIL PROTECTED] told me that...
I'm not too kind at this. Either make it totally separate commands, or
make a required switch specifying what to do. Otherwise
Dear diary, on Sun, Apr 17, 2005 at 09:24:27PM CEST, I got a letter
where Daniel Barkalow [EMAIL PROTECTED] told me that...
On Sun, 17 Apr 2005, Petr Baudis wrote:
Dear diary, on Sun, Apr 17, 2005 at 08:49:11PM CEST, I got a letter
where Daniel Barkalow [EMAIL PROTECTED] told me that...
On Sun, 17 Apr 2005, Russell King wrote:
This will (and does) do exactly what I want. I'll also read into the
above a request that you want it in forward date order. 8)
No, I actually don't _think_ I care. In many ways I'm more used to
reverse date order, because that's usually how you
On Sun, Apr 17, 2005 at 04:03:46PM -0400, Daniel Barkalow wrote:
Actually, the documentation I've got says:
F_OK requests checking whether merely testing for the existence of the
file would be allowed (this depends on the permissions of the directories
in the path to the file, as given in
On Sun, 17 Apr 2005, Petr Baudis wrote:
Dear diary, on Sun, Apr 17, 2005 at 06:51:59PM CEST, I got a letter
where Daniel Barkalow [EMAIL PROTECTED] told me that...
merge-base finds one of the best common ancestors of a pair of commits. In
particular, it finds one of the ones which is fewest
Linus Torvalds wrote:
Ie we have two phases to the merge: first get the objects, with something
like
repo=kernel.org:/pub/kernel/people/torvalds/linux-2.6.git
rsync --ignore-existing -acv $(repo)/ .git/
Could you place a tarball there for people like me who are no real
kernel hackers and
Linus,
do you have any particular reason you did not want the patch
to skip unmerged ones when checkout-cache -a is done, and if
so could you let me know?
Here is what happens before the patch:
$ ls -al
total 16
drwxrwsr-x 3 junio src 4096 Apr 17 14:30 ./
drwxrwsr-x 8
It may not be pretty, but it seems to have worked fine!
Here's my history log (with intermediate checking removed - I was being
pretty anal ;):
rsync -avz --ignore-existing
master.kernel.org:/home/rmk/linux-2.6-rmk.git/ .git/
rsync -avz --ignore-existing
On Sunday 17 April 2005 08:03 am, Petr Baudis wrote:
Dear diary, on Sun, Apr 17, 2005 at 07:36:51AM CEST, I got a letter
where Steven Cole [EMAIL PROTECTED] told me that...
This is a fairly trivial addition, but if users are adding remote
repositories
with git addremote, then those users
On Sun, 17 Apr 2005, Russell King wrote:
I pulled it tonight into a pristine tree (which of course worked.)
Goodie.
In doing so, I noticed that I'd messed up one of the commits - there's
a missing new file. Grr. I'll put that down to being a newbie git.
Actually, you should put that
Here's a tidbit to enable git to compile on Fedora. Add the following
line to /etc/rc.d/rc.local...
ln -sf /lib/modules/`uname -r`/build/include/linux
/usr/local/include/linux
This fix creates a symlink, on each boot up, in the local include
directory that points to the kernel header
On Sun, 17 Apr 2005, Linus Torvalds wrote:
On Sun, 17 Apr 2005, Brad Roberts wrote:
(ok, author looks better, but committer doesn't obey the AUTHOR_ vars yet)
They should't, but maybe I should add COMMITTER_xxx overrides. I just do
_not_ want people to think that they should claim to be
Dear diary, on Mon, Apr 18, 2005 at 01:29:05AM CEST, I got a letter
where Herbert Xu [EMAIL PROTECTED] told me that...
I get the feeling that it isn't that bad. For example, if we did it
at the points where the blobs actually entered the tree, then the cost
is always proportional to the change
On Sun, Apr 17, 2005 at 07:25:49PM -0400, jeff millar wrote:
Here's a tidbit to enable git to compile on Fedora. Add the
following line to /etc/rc.d/rc.local...
ln -sf /lib/modules/`uname -r`/build/include/linux /usr/local/include/linux
I can't see why this should be needed. What breaks
On Sun, 17 Apr 2005, Brad Roberts wrote:
braddr:x:1000:1000:Brad Roberts,,,:/home/braddr:/bin/bash
All gecos entries on all my debian boxes are of the form:
fullname, office number, office extension, and home number
Ahh, ok.
I'll make the cleanup thing just remove strange characters
On Sun, 2005-04-17 at 19:25 -0400, jeff millar wrote:
ln -sf /lib/modules/`uname -r`/build/include/linux
/usr/local/include/linux
This fix creates a symlink, on each boot up, in the local include
directory that points to the kernel header files. If there's a better
way to do this,
Dear diary, on Mon, Apr 18, 2005 at 01:31:36AM CEST, I got a letter
where David Woodhouse [EMAIL PROTECTED] told me that...
Note that any given copy of a tree doesn't _need_ to keep all the
history back the beginning of time. It's OK if the oldest commit object
in your tree actually refers back
On Mon, 18 Apr 2005, Herbert Xu wrote:
I wasn't disputing that of course. However, the same effect can be
achieved in using a single hash with a bigger length, e.g., sha256
or sha512.
No it cannot.
If somebody actually literally totally breaks that hash, length won't
matter. There are
Petr Baudis wrote:
Dear diary, on Mon, Apr 18, 2005 at 01:29:05AM CEST, I got a letter
where Herbert Xu [EMAIL PROTECTED] told me that...
I get the feeling that it isn't that bad. For example, if we did it
at the points where the blobs actually entered the tree, then the cost
is always
Dear diary, on Thu, Apr 14, 2005 at 02:53:54PM CEST, I got a letter
where Ingo Molnar [EMAIL PROTECTED] told me that...
this patch fixes a 1-byte overflow in show-files.c (looks narrow is is
probably not exploitable). A specially crafted db object (tree) might
trigger this overflow.
On Mon, 2005-04-18 at 02:50 +0200, Petr Baudis wrote:
I think I will make git-pasky's default behaviour (when we get
http-pull, that is) to keep the complete commit history but only trees
you need/want; togglable to both sides.
I think the default behaviour should probably be to fetch
Dear diary, on Mon, Apr 18, 2005 at 02:49:06AM CEST, I got a letter
where Herbert Xu [EMAIL PROTECTED] told me that...
Therefore the only conclusion I can draw is that we're only calling
update-cache on the set of changed files, or at most a small superset
of them. In that case, the cost of
This implements the parsing functions.
Signed-Off-By: Daniel Barkalow [EMAIL PROTECTED]
Index: blob.c
===
--- /dev/null (tree:5ca133e1b74aee39b2124c0ec9fd51539babb5e0)
+++ 1172a9b8f45b2fd640985595cc5258db3b027828/blob.c
65 matches
Mail list logo
