Paul Dickson wrote:
Since 160-bits does not go into base64 evenly anyways, what happens if
you use 2^10 instead of 2^12 for the subdir names? That will be 1/4 the
directories of the base64 given above.
I was going to try one-character subdirs, so 2^6, but I haven't had a
chance to do that since I
David Lang wrote:
note that default configs of ext2 and ext3 don't qualify as sane
filesystems by this definition.
Not using dir_index *IS* insane.
-hpa
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at ht
The "update-cache --refresh" command attempts refresh_entry()
on unmerged path, which results in as many "needs update" messages
as there are unmerged stages for that path. This does not do
any harm to the working directory, but it is confusing.
$ ls -al
total 16
drwxrwsr-x 3 junio
Add tool to render git's " " into an RFC2822-compliant
string, because I don't think date(1) can do it. Use same for 'git log'
output.
Signed-off-by: David Woodhouse <[EMAIL PROTECTED]>
--- Makefile
+++ Makefile2005-04-18 15:40:43.0 +1000
@@ -14,7 +14,7 @@
PROG= update-cache show
I said:
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 (stupid short filenames,
case-insensitive/case-preserving).
Petr Baudis replied:
I personally don't mind g
Pasky wrote:
> It has some room for more
> crystal-clearness, though. ;-)
True indeed ;).
--
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 f
Herbert wrote:
> mktemp(1) creates the file before exiting. ... O_EXCL
Aha - right you are. Thanks for pointing that out.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373,
There's a patch at the bottom of this, so please look at that first before
my reading my whining immediately below.
I'm having some troubles with git pull, so this is just an ordinary diff.
Otherwise, I would have used the in-house diff command.
patch: Only garbage was found in the patch in
On Sun, 2005-04-17 at 18:15 -0700, Linus Torvalds wrote:
> In particular, is there some easy way to walk backwards by time? "git log"
> definitely needs that, and merge-base clearly wants something similar.
Actually the ideal output of 'git log' isn't strictly chronological.
IIRC my bkexport sc
> Not until all the data structures are really really stable.
Fine by me to wait, though perhaps not for the same reason, and perhaps
not as long.
A libgit.so can deal with data structure changes just as well as a set
of command line utilities. So long as everything funnels through one
place, yo
> So until proven otherwise, I worry about accidental hashes, and in
> 160 bits of good hashing, that just isn't an issue either...[Going
> from 128 bits to 160 bits made it] so _unbelievably_ less likely to
> happen that it's not even funny.
You are right. Here's how I learnt to stop worrying an
Linus Torvalds wrote:
>
> Well, libgcrypt seems to be pretty rare out there - I certainly don't have
> it installed on my machine.
Well, I don't even have openssl ...
> Or merge the SHA1 code from the kernel, even, and make the project
> entirely self-sufficient.
... so I took the sha1 code fro
On Sun, 17 Apr 2005, Daniel Barkalow wrote:
> > But if there are simple helper functions to get the "next backwards in
> > time" case (by looking at the parent dates in a merge), then that should
> > be ok to do incrementally.
>
> Haven't written that yet, but I can do so.
Okay, I wrote this.
On Sun, 17 Apr 2005, Paul Jackson wrote:
>
> I'd encourage you to invite someone to provide a libgit.
Not until all the data structures are really really stable.
That's the thing - we can keep the _program_ interfaces somewhat stable.
But internally we may change stuff wildly, and anybody who
On Sun, 17 Apr 2005, Junio C Hamano wrote:
>
> LT> What do you think? I can whip up a "merge-cache" program like that in
> five
> LT> minutes, and it _seems_ like the right interface..
>
> Yes. I think that is the right thing to do. In fact the idea
> is quite similar to what I've been work
Paul Jackson <[EMAIL PROTECTED]> wrote:
>
> 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.
mktemp(1) creates the file before exiting. Other instances of mktemp(
Linus wrote:
> But then I'd really suggest that you use "git" itself, not any
> "libgit". Ie you take _all_ the plumbing as real programs, and instead of
> trying to link against individual routines, you'd _script_ it.
I think you've got this upside down, Linus.
Trying to make the executable 'git
Here's the beginnings of yet another git usage/howto/tutorial.
It can grow or die... I'll gladly take patches for it,
or Pasky et al can merge more git plumbing and toilet usages
into it, with or without me.
http://www.xenotime.net/linux/doc/git-usage-howto
---
~Randy
-
To unsubscribe from thi
On Sun, 17 Apr 2005, Junio C Hamano wrote:
>
> One small detail. What about the "-x" bit?
You'll need to merge those kinds of changes separately for now. We'll have
to resolve that too, right now I think the -x bit gets lost on a merge
simply because we just write the temp-files, something m
> "LT" == Linus Torvalds <[EMAIL PROTECTED]> writes:
LT> I'm actually thinking that maybe the _right_ interface is to do something
LT> like this:
LT> merge-cache
LT> and what that does is to look up the in the cache, and if it
LT> has any merge entries, unpack all of them (which may
On Sun, Apr 17, 2005 at 12:38:37AM -0400, David A. Wheeler wrote:
> The probability of an accidental overlap for SHA-1 for two
> different files is absurdly remote; it's just not worth worrying about.
>
> However, the possibility of an INTENTIONAL overlap is a completely
> different matter. I thi
This switches to my implementation of merge-base, but with the new parsing
library.
Signed-Off-By: Daniel Barkalow <[EMAIL PROTECTED]>
Index: Makefile
===
--- 108bfb69c14c55c3c6e30a298307390c82cf1b3b/Makefile (mode:100644
sha1:affc0
This ports fsck-cache to use parsing functions. Note that performance
could be improved here by only reading each object once, but this requires
somewhat more complicated flow control.
Signed-Off-By: Daniel Barkalow <[EMAIL PROTECTED]>
Index: Makefile
==
This ports rev-tree to use the parsing functions introduced in the
previous patches.
Signed-Off-By: Daniel Barkalow <[EMAIL PROTECTED]>
Index: Makefile
===
--- 5ca133e1b74aee39b2124c0ec9fd51539babb5e0/Makefile (mode:100644
sha1:7731
This implements the parsing functions.
Signed-Off-By: Daniel Barkalow <[EMAIL PROTECTED]>
Index: blob.c
===
--- /dev/null (tree:5ca133e1b74aee39b2124c0ec9fd51539babb5e0)
+++ 1172a9b8f45b2fd640985595cc5258db3b027828/blob.c (mode:1006
This adds the structs and function declarations for parsing git objects.
Signed-Off-By: Daniel Barkalow <[EMAIL PROTECTED]>
Index: blob.h
===
--- /dev/null (tree:5ca133e1b74aee39b2124c0ec9fd51539babb5e0)
+++ 1172a9b8f45b2fd640985595c
This series introduces common parsers for objects, and ports the programs
that currently use revision.h to them.
1: the header files
2: the implementations
3: port rev-tree
4: port fsck-cache
5: port merge-base
-Daniel
*This .sig left intentionally blank*
-
To unsubscribe from this
> "LT" == Linus Torvalds <[EMAIL PROTECTED]> writes:
LT> On Sun, 17 Apr 2005, Junio C Hamano wrote:
>>
>> This is the alternative strategy I mentioned in my previous
>> message. A new -m option to checkout-cache causes it to store
>> contents of unmerged paths in path~1~, path~2~, and path~3
On Sun, 17 Apr 2005, Linus Torvalds wrote:
> On Sun, 17 Apr 2005, Daniel Barkalow wrote:
> >
> > Any comment on the design, or should I send my implementation?
>
> Show the patches, and maybe I (and others) can make comments on the
> thing.. It doesn't sound broken by design, the only question
Linus wants to drive ahead, and ignore the collision issue for now,
and has been dismissive of the risks, he wants a result not heart
searching, and the list comments exhibit a confusion with the
engineering problem of avoiding accidental collisions v deliberate sabotage.
Since this is not a show-
On Sun, 17 Apr 2005, Junio C Hamano wrote:
>
> This is the alternative strategy I mentioned in my previous
> message. A new -m option to checkout-cache causes it to store
> contents of unmerged paths in path~1~, path~2~, and path~3~.
I don't think this is wrong, but it all seems a bit hacky. Th
The patch needed some tweaking, but not in the way you thought. :)
commit a6aa192641e9ea242332fee4916abf5ad2640d75
tree c69878b009ec2f505d75aa7d99e9ee30cd21ab02
parent 60e1274460f50bcecdc3f162b4fced9e5ebf2dfb
author Brad Roberts <[EMAIL PROTECTED]> 1113789519 -0700
committer Brad Roberts <[EMAIL P
Junio wrote:
> What Linus is saying is that he wants you to talk with git
> plumbing by invoking the executables he have, via system(3),
> popen(3), etc.
Hopefully, Linus didn't specify system(3) or popen(3) for production
software.
They are a rich source of security holes. Inefficient, too, sin
> "LT" == Linus Torvalds <[EMAIL PROTECTED]> writes:
LT> On Mon, 18 Apr 2005, Petr Baudis wrote:
>>
>> Am I just slow or does the first dst-- make it miss the last trailing
>> /[,;.]/?
LT> Hopefully not. It _should_ make it miss the last '\0', but hey, it got my
LT> usual amount of testing (
Dear diary, on Mon, Apr 18, 2005 at 03:35:08AM CEST, I got a letter
where Paul Jackson <[EMAIL PROTECTED]> told me that...
> Petr wrote:
> > The documentation I've got says:
> >
> > "R_OK, W_OK and X_OK request checking whether the file exists and has
> > read, write and execute permissions, r
On Sun, 2005-04-17 at 18:16 -0700, Linus Torvalds wrote:
> Alternatively, you can have just the rev-tree cache of them. That's what
> it was designed for (along with avoiding to have to read 60,000 commits).
Purely from a conceptual POV I'd be a little happier with the history
just ending with a p
Petr wrote:
> The documentation I've got says:
>
> "R_OK, W_OK and X_OK request checking whether the file exists and has
> read, write and execute permissions, respectively. F_OK just requests
> checking for the existence of the file."
You don't exactly say it, but I'm guessing that you thi
On Mon, 18 Apr 2005 09:21:45 +1000 David Woodhouse wrote:
| On Sun, 2005-04-17 at 15:22 -0700, randy_dunlap wrote:
| > David did the commits-mailing-list script and I'm working on a
| > commits web-page like what was formerly seen at:
| > http://www.kernel.org/pub/linux/kernel/v2.6/testing/cset/
|
> So it shouldn't complain about a filename which you're allowed to try to
> stat, even if there's nothing there.
I'm not sure what 'nothing there' means to you.
To me, it means 'no file there', so no you would not be allowed
to stat it - and should fail ENOENT.
> And it would depend on the priv
Petr wrote:
> Does this distinction have any effect when doing F_OK?
Well, yeah. If only one of real or effective id's could traverse the
path (execute perm on directories), then you'd get the wrong answer.
--
I won't rest till it's the best ...
Programmer, L
On Sun, 17 Apr 2005, Daniel Barkalow wrote:
>
> Any comment on the design, or should I send my implementation?
Show the patches, and maybe I (and others) can make comments on the
thing.. It doesn't sound broken by design, the only question is how much
harder (if any) it is to use than the rat
On Mon, 18 Apr 2005, Petr Baudis wrote:
> Dear diary, on Mon, Apr 18, 2005 at 02:06:43AM CEST, I got a letter
> where David Woodhouse <[EMAIL PROTECTED]> told me that...
> > On Mon, 2005-04-18 at 01:39 +0200, Petr Baudis wrote:
> > > Of course an entirely different thing are _trees_ associated w
[EMAIL PROTECTED] said:
[...]
> Linus has already weighed in that he doesn't give a crap. All the
> crypto-babble about collision whitepapers is uninteresting without a
> repo that has real collisions. git is far too cool as is - prove I
> should be concerned.
Just copy over a file (might be t
On Mon, 18 Apr 2005, Petr Baudis wrote:
>
> Am I just slow or does the first dst-- make it miss the last trailing
> /[,;.]/?
Hopefully not. It _should_ make it miss the last '\0', but hey, it got my
usual amount of testing (ie none). I'm sure Brad can tell us whether it
makes any difference..
Dear diary, on Mon, Apr 18, 2005 at 02:51:59AM CEST, I got a letter
where David Woodhouse <[EMAIL PROTECTED]> told me that...
> 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 commi
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 o
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 everyt
Dear diary, on Mon, Apr 18, 2005 at 02:45:22AM CEST, I got a letter
where David Woodhouse <[EMAIL PROTECTED]> told me that...
> On Mon, 2005-04-18 at 02:35 +0200, Petr Baudis wrote:
> > > For the special case of removing history before 2.6.12-rc2 from the
> > > trees, I certainly think we can do it
On Mon, Apr 18, 2005 at 01:34:41AM +0200, Petr Baudis wrote:
>
> No. The collision check is done in the opposite cache - when you want to
> write a blob and there is already a file of the same hash in the tree.
> So either the blob is already in the database, or you have a collision.
> Therefore, t
On Mon, 2005-04-18 at 02:35 +0200, Petr Baudis wrote:
> > For the special case of removing history before 2.6.12-rc2 from the
> > trees, I certainly think we can do it by leaving out all the commits,
> > not just the trees. We can do that easily, but there's no way we can
> > _add_ that history ret
Dear diary, on Mon, Apr 18, 2005 at 02:06:43AM CEST, I got a letter
where David Woodhouse <[EMAIL PROTECTED]> told me that...
> On Mon, 2005-04-18 at 01:39 +0200, Petr Baudis wrote:
> > Of course an entirely different thing are _trees_ associated with those
> > commits. As long as you stay with a s
After the fiasco with confusing struct revision for a struct commit, I've
worked out something that makes more sense. I've actually ported
fsck-cache, rev-tree, and my merge-base to it, so it should at least be
comprehensive.
The design is as follows:
There is a struct object for each object in t
Dear diary, on Mon, Apr 18, 2005 at 01:39:10AM CEST, I got a letter
where Linus Torvalds <[EMAIL PROTECTED]> told me that...
>
>
> 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 th
On Mon, 2005-04-18 at 01:39 +0200, Petr Baudis wrote:
> I think this is bad, bad, bad. If you don't keep around all the
> _commits_, you get into all sorts of troubles - when merging, when doing
> git log, etc. And the commits themselves are probably actually pretty
> small portion of the thing. I
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.
>
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 proportio
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 ar
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
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 thi
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 cha
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 bre
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 ch
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
On Sun, Apr 17, 2005 at 03:35:17PM -0700, Linus Torvalds wrote:
>
> Quite the reverse. Again, you bring up totally theoretical arguments. In
> _practice_ it has indeed been shown that using two hashes _does_ catch
> hash colissions.
>
> The trivial example is using md5 sums with a length. The "
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
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 files
> "NA" == Nomad Arton <[EMAIL PROTECTED]> writes:
NA> Linus Torvalds schrieb:
>> In fact, one of my hopes was that other SCM's could just use the git
>> plumbing. But then I'd really suggest that you use "git" itself, not any
>> "libgit". Ie you take _all_ the plumbing as real programs, and in
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
On Sun, 2005-04-17 at 15:22 -0700, randy_dunlap wrote:
> David did the commits-mailing-list script and I'm working on a
> commits web-page like what was formerly seen at:
> http://www.kernel.org/pub/linux/kernel/v2.6/testing/cset/
> (with daily tarball)
>
> based on some older scripts from David,
This is the alternative strategy I mentioned in my previous
message. A new -m option to checkout-cache causes it to store
contents of unmerged paths in path~1~, path~2~, and path~3~.
To be applied on top of the previous patch I re-sent:
[PATCH] checkout-cache -a should not extract unmerged s
On Sun, Apr 17, 2005 at 11:19:59PM +0100, Russell King wrote:
> On Sun, Apr 17, 2005 at 03:17:50PM -0700, Linus Torvalds wrote:
> > Can people usefully track my current kernel git repository, or do you have
> > to be crazy to do so? That's really the question. You be the judge. Me,
> > I'm just gid
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 tho
Linus Torvalds schrieb:
In fact, one of my hopes was that other SCM's could just use the git
plumbing. But then I'd really suggest that you use "git" itself, not any
"libgit". Ie you take _all_ the plumbing as real programs, and instead of
trying to link against individual routines, you'd _script_
Hi,
Thanks for your comments.
> > This is the first time for me to send you a patch; be gentle.
> > the following patch allows for use of gcrypt.
>
> Well, libgcrypt seems to be pretty rare out there - I certainly don't have
> it installed on my machine.
Hmm... okay. Might be the case if you
On Mon, 18 Apr 2005, Herbert Xu wrote:
>
> Sorry, it has already been shown that combining two difference hashes
> doesn't necessarily provide the security that you would hope.
Sorry, that's not true.
Quite the reverse. Again, you bring up totally theoretical arguments. In
_practice_ it has i
Dear diary, on Mon, Apr 18, 2005 at 12:09:21AM CEST, I got a letter
where "Randy.Dunlap" <[EMAIL PROTECTED]> told me that...
> On Sun, 17 Apr 2005 23:50:40 +0200 Jochen Roemling wrote:
>
> | Linus Torvalds wrote:
> |
> | >Ie we have two phases to the merge: first get the objects, with something
>
On Sun, 17 Apr 2005 15:17:50 -0700 (PDT) Linus Torvalds wrote:
|
|
| On Mon, 18 Apr 2005, David Woodhouse wrote:
| >
| > Do you want the commits list running for it yet? Do you want the
| > changesets which are already in it re-mailed without a 'TESTING' tag?
|
| I really don't know. I'm actua
I have set up /pub/scm/linux/kernel/git on kernel.org. Everyone who had
directories in /pub/linux/kernel/people now have directories in
/pub/scm/linux/kernel/git. For non-kernel trees it would probably be
better to have different trees, however; I also would like to request
that git itself is
On Sun, Apr 17, 2005 at 03:17:50PM -0700, Linus Torvalds wrote:
> Can people usefully track my current kernel git repository, or do you have
> to be crazy to do so? That's really the question. You be the judge. Me,
> I'm just giddy from a merge that was clearly done using interfaces that
> aren't a
On Mon, 18 Apr 2005, David Woodhouse wrote:
>
> Do you want the commits list running for it yet? Do you want the
> changesets which are already in it re-mailed without a 'TESTING' tag?
I really don't know. I'm actually very happy where this thing is right
now, and completing that first merge su
There's one more mode bit we might actually care about: the symlink bit.
(One would store the target as the blob, presumably, but chmod isn't going
to create symlinks out of regular files.)
Morten
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL P
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
> If we want to have any kind of confidence that the hash is reall
> yunbreakable, we should make it not just longer than 160 bits, we should
> make sure that it's two or more hashes, and that they are based on totally
> different principles.
Sorry, it
On Sun, 17 Apr 2005 23:50:40 +0200 Jochen Roemling wrote:
| 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/
| >
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
master.kernel.org:/home
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 jun
On Sat, 2005-04-16 at 16:01 -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
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 do
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
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 commits away from the
> further of the he
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 give
Dear diary, on Sun, Apr 17, 2005 at 09:25:17PM CEST, I got a letter
where Paul Jackson <[EMAIL PROTECTED]> told me that...
> Petr wrote:
> > BTW, I'd just use access(F_OK) instead of stat() it I don't care about
>
> I recommend _only_ using it when you require exactly the above real vs.
> effectiv
On Sun, 17 Apr 2005, Linus Torvalds wrote:
>
> Yes. I'm not opposed to yours, I was just opposed to some of the things
> around it you did, so I wrote mine as a kind of place-holder. I'll happily
> take patches to turn it from a rally simple and stupid one into a more
> polished version.
Btw
On Sun, 17 Apr 2005, Petr Baudis wrote:
> Dear diary, on Sun, Apr 17, 2005 at 09:25:17PM CEST, I got a letter
> where Paul Jackson <[EMAIL PROTECTED]> told me that...
> > Petr wrote:
> > > BTW, I'd just use access(F_OK) instead of stat() it I don't care about
> >
> > I recommend _only_ using it w
On Sun, Apr 17, 2005 at 01:26:27PM -0700, Linus Torvalds wrote:
>
>
> On Sun, 17 Apr 2005, Russell King wrote:
> >
> > It's trivial to change - it's either sort -n or sort -nr !
>
> Yes.
>
> Btw, it might make sense to do the "grep" before the sort, since the sort
> doesn't scale as nicely wi
Dear diary, on Sun, Apr 17, 2005 at 10:03:46PM 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 09:25:17PM CEST, I got a letter
> > where Paul Jackson <[EMAIL PROTECTED]> told me that.
On Sun, 17 Apr 2005, Russell King wrote:
>
> It's trivial to change - it's either sort -n or sort -nr !
Yes.
Btw, it might make sense to do the "grep" before the sort, since the sort
doesn't scale as nicely with lots of output. On the other hand, then the
grep pattern needs to be a bit more
On Sun, 17 Apr 2005, Linus Torvalds wrote:
> On Sun, 17 Apr 2005, Linus Torvalds wrote:
> >
> > Yes. I'm not opposed to yours, I was just opposed to some of the things
> > around it you did, so I wrote mine as a kind of place-holder. I'll happily
> > take patches to turn it from a rally simple
Linus Torvalds wrote:
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 han
On Sun, Apr 17, 2005 at 01:08:51PM -0700, Linus Torvalds wrote:
> 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
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
1 - 100 of 181 matches
Mail list logo
