tree a43d483cf144eb0f770a6e2e8ac9f721965a7fa9
parent 8085ce084c0f0144c353963853f81486fc331120
author Kumar Gala [EMAIL PROTECTED] Wed, 31 Aug 2005 14:54:47 +1000
committer Linus Torvalds [EMAIL PROTECTED] Fri, 02 Sep 2005 00:52:29 -0700
[PATCH] ppc: L2 cache prefetch fixes on 745x
We run into
tree 7e4ce062242df4690c6711ae1274d76e8ef5fce9
parent 7eaa414ee86cda4c153002ed218b9a0ad17f7de1
author David Gibson [EMAIL PROTECTED] Wed, 31 Aug 2005 14:34:05 +1000
committer Linus Torvalds [EMAIL PROTECTED] Fri, 02 Sep 2005 00:48:20 -0700
[PATCH] Fix bug in ppc64 dynamic hugepage support
In
tree d6a45b71753d97d85dc1bbd7dd7a095144a6c50f
parent 6b39374a27eb4be7e9d82145ae270ba02ea90dc8
author Adrian Bunk [EMAIL PROTECTED] Wed, 31 Aug 2005 17:43:51 +0200
committer Linus Torvalds [EMAIL PROTECTED] Fri, 02 Sep 2005 00:43:33 -0700
[PATCH] Add missing select's to DVB_BUDGET_AV
This fixes
On Wed, 31 Aug 2005, Junio C Hamano wrote:
Daniel Barkalow [EMAIL PROTECTED] writes:
Is there any current use for read-tree with multiple trees without -m or
equivalent?
I did not know it even allowed multiple trees without -m, but
you are right. It does not seem to complain.
I
Daniel Barkalow [EMAIL PROTECTED] writes:
(The thread you mention seems to say that we accept entries being missing
from the index as if they were unchanged, but I don't see a good reason
for this; you'd be dealing with the full set in the index for the merge,
even if you don't have a
Hi Y'all,
I've been playing with export a bit, and it doesn't seem to work. Or at least
it doesn't do what I think of as work-ing.
I'm basically doing a git-export and trying to create a quilt series out of
it.
When you do a quilt push -a I get as far as:
Hello,
A colleague was having problems with git clone. It seemed to work as
expected for me so I went into his environment to see what was causing
it to fail. I found that he had set the CDPATH environment variable to
something like '.:..:../..:$HOME'. Try this (using bash) and you'll see
the
On Thu, 1 Sep 2005, Junio C Hamano wrote:
Daniel, I do not know what your current status is, but I think
you need something like this.
Yup, I forgot to actually test that functionality.
---
diff --git a/tree.c b/tree.c
--- a/tree.c
+++ b/tree.c
@@ -224,10 +224,12 @@ struct tree
Junio C Hamano wrote:
Tim Ottinger [EMAIL PROTECTED] writes:
So when this gets all settled, will we see a lot of tool renaming?
I personally do not see it coming. Any particular one you have
in mind?
git-update-cache for instance?
I am not sure which 'cache' commands need to
On 8/30/05, Paul Mackerras [EMAIL PROTECTED] wrote:
Try now... :)
It also makes the current graph line thicker now, so it's easier to
pick out where the line you clicked on goes.
That's a fine feature :)
BTW, did you sometimes notice lines you can't click at all?
An example is the red
On Thu, September 1, 2005 4:10 pm, Alex Riesen said:
That's a fine feature :)
BTW, did you sometimes notice lines you can't click at all?
An example is the red line on the most left side of the graph
by SHA 66129f88c4cc719591f687e5c8c764fe9d3e437a.
It goes from blue up-arrow through green
Michael Ellerman [EMAIL PROTECTED] writes:
I realise I'm trying to represent a DAG as a linear series of patches. But
the
merge order is a linear sequence of commits, and so it *should* be
representable as a linear series of patches. I think.
Any thoughts?
All true, and more. It does
Russell King [EMAIL PROTECTED] writes:
Is the expected filesystem layout documented somewhere online (_external_
to the source code) ?
There already was a sketchy description in git(7), at
http://www.kernel.org/pub/software/scm/git/docs/
I've updated it a bit to describe the current status;
Tim Ottinger [EMAIL PROTECTED] writes:
git-update-cache for instance?
I am not sure which 'cache' commands need to be 'index' now.
Logically you are right, but I suspect that may not fly well in
practice. Too many of us have already got our fingers wired to
type cache, and the glossary is
14 matches
Mail list logo
