Re: [PATCH 3/2] Remove emu23, fix entry order

Daniel Barkalow <[EMAIL PROTECTED]> writes: > A few things to improve testing. I'll clean up the series as a whole once > it's tested. > > This removes the emu23 tests; I think that the only DF conflict tests were > in that set, however, so these should be fished out and added to something > el

[PATCH 3/2] Remove emu23, fix entry order

A few things to improve testing. I'll clean up the series as a whole once it's tested. This removes the emu23 tests; I think that the only DF conflict tests were in that set, however, so these should be fished out and added to something else. Signed-off-by: Daniel Barkalow <[EMAIL PROTECTED]>

Re: Tool renames? was Re: First stab at glossary

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

[PATCH] Show modified files in git-ls-files

Add -m/--modified to show files that have been modified wrt. the index. M was already taken so the tag for modifified files is C (changed). $ git-ls-files -m -t C Documentation/git-ls-files.txt C ls-files.c Signed-off-by: Brian Gerst <[EMAIL PROTECTED]> --- Documentation/git-ls-files.txt |

Re: please pull ppc64-2.6.git

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 I've updated it a bit to describe the current stat

Re: Any plans to make export work?

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

Re: gitk with hyperspace support

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 g

Re: gitk with hyperspace support

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 th

Re: Tool renames? was Re: First stab at glossary

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

Re: Reworked read-tree.

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 *pa

[PATCH] unset CDPATH in git-clone

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 p

Any plans to make export work?

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: 06f81ea8ca09b880cadf101d7e23b500e9

Reworked read-tree.

Daniel, I do not know what your current status is, but I think you need something like this. I was scratching my head figuring out why it passes all the t/ tests but couldn't do a simple 'git-read-tree HEAD'. --- diff --git a/tree.c b/tree.c --- a/tree.c +++ b/tree.c @@ -224,10 +224,12 @@ struct