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

[Junio C Hamano]

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 
> else.

Thanks.  I'll take a look at 'test moving' part later, perhaps
this weekend.

I should give Pasky a heads-up, since I vaguely recall him
writing something about always doing 3-way merge even when fast
forwarding in his TODO list in the Cogito tree, and just in case
emu23 was what he had in mind...  I'll also CC: Catalin too
just in case StGIT is tempted to use emu23 in git.switch().

Petr, we _might_ remove "read-tree --emu23" in the near future,
but not immediately.  That will not happen until the read-tree
rewrite Daniel is working on proves to be useful in making
'interesting' merges more reliably work.

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Daniel Barkalow]

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]>

---

 read-tree.c   |   89 +++-
 t/t1005-read-tree-m-2way-emu23.sh |  422 -
 2 files changed, 37 insertions(+), 474 deletions(-)
 delete mode 100755 t/t1005-read-tree-m-2way-emu23.sh

63092a4dfb2042e8fc21260b2f315b01e9163940
diff --git a/read-tree.c b/read-tree.c
--- a/read-tree.c
+++ b/read-tree.c
@@ -9,7 +9,6 @@
 #include "tree.h"
 
 static int merge = 0;
-static int emu23 = 0;
 static int update = 0;
 
 static struct object_list *trees = NULL;
@@ -19,19 +18,39 @@ typedef int (*merge_fn_t)(struct cache_e
  int df_conflicts_2,
  int df_conflicts_3);
 
+static int entcmp(char *name1, int dir1, char *name2, int dir2)
+{
+   int len1 = strlen(name1);
+   int len2 = strlen(name2);
+   int len = len1 < len2 ? len1 : len2;
+   int ret = memcmp(name1, name2, len);
+   unsigned char c1, c2;
+   if (ret)
+   return ret;
+   c1 = name1[len];
+   c2 = name2[len];
+   if (!c1 && dir1)
+   c1 = '/';
+   if (!c2 && dir2)
+   c2 = '/';
+   ret = (c1 < c2) ? -1 : (c1 > c2) ? 1 : 0;
+   if (c1 && c2 && !ret)
+   ret = len1 - len2;
+   return ret;
+}
+
 static int unpack_trees_rec(struct tree_entry_list **posns, int len,
const char *base, merge_fn_t fn, 
int file2, int file3, int *indpos)
 {
int baselen = strlen(base);
int src_size = len + 1;
-   if (emu23)
-   src_size++;
if (src_size > 4)
src_size = 4;
do {
int i;
char *first = NULL;
+   int firstdir = 0;
int pathlen;
unsigned ce_size;
int dir2 = 0;
@@ -73,11 +92,23 @@ static int unpack_trees_rec(struct tree_
}
}
 
+   /*
+   if (first)
+   printf("%s\n", first);
+   */
+
for (i = 0; i < len; i++) {
if (!posns[i])
continue;
-   if (!first || strcmp(first, posns[i]->name) > 0)
+   /*
+   printf("%d %s\n", i + 1, posns[i]->name);
+   */
+   if (!first || entcmp(first, firstdir,
+posns[i]->name, 
+posns[i]->directory) > 0) {
first = posns[i]->name;
+   firstdir = posns[i]->directory;
+   }
}
/* No name means we're done */
if (!first)
@@ -94,19 +125,6 @@ static int unpack_trees_rec(struct tree_
   src_size);
src[0] = active_cache[*indpos];
remove_cache_entry_at(*indpos);
-   if (emu23) {
-   // we need this in stage 2 as well as stage 0
-   struct cache_entry *copy =
-   xmalloc(ce_size);
-   memcpy(copy, src[0], ce_size);
-   copy->ce_flags = 
-   create_ce_flags(baselen + pathlen, 2);
-   if (dir2 || file2) {
-   die("cannot merge index and our head 
tree");
-   }
-   src[2] = copy;
-   subfile2 = 1;
-   }
}
 
for (i = 0; i < len; i++) {
@@ -125,8 +143,6 @@ static int unpack_trees_rec(struct tree_
} else {
ce_stage = i + merge;
}
-   if (emu23 && ce_stage == 2)
-   ce_stage = 3;
 
if (posns[i]->directory) {
if (!subposns) {
@@ -137,8 +153,6 @@ static int unpack_trees_rec(struct tree_
parse_tree(posns[i]->item.tree);
subposns[i] = posns[i]->item.tree->entries;
posns[i] = posns[i]->next;
-   if (emu23 && ce_stage == 1)
-   dir2 = 1;
if (ce_stage == 2)
dir2 = 1;
if (ce_stage == 3)
@@ -

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

[Junio C Hamano]

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 there to describe both cache and
index.

 


-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Brian Gerst]

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 |4 
 ls-files.c |   20 +++-
 2 files changed, 19 insertions(+), 5 deletions(-)

Subject: [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 |4 
 ls-files.c |   20 +++-
 2 files changed, 19 insertions(+), 5 deletions(-)

9de83ef7cce7ed5c1aa129cf2a81f8bce3aedb4f
diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt
--- a/Documentation/git-ls-files.txt
+++ b/Documentation/git-ls-files.txt
@@ -33,6 +33,9 @@ OPTIONS
 -d|--deleted::
Show deleted files in the output
 
+-m|--modified::
+   Show modified files in the output
+
 -o|--others::
Show other files in the output
 
@@ -71,6 +74,7 @@ OPTIONS
H   cached
M   unmerged
R   removed/deleted
+   C   modifed (changed)
K   to be killed
?   other
 
diff --git a/ls-files.c b/ls-files.c
--- a/ls-files.c
+++ b/ls-files.c
@@ -17,6 +17,7 @@ static int show_ignored = 0;
 static int show_stage = 0;
 static int show_unmerged = 0;
 static int show_killed = 0;
+static int show_modified = 0;
 static int line_terminator = '\n';
 
 static int prefix_len = 0, prefix_offset = 0;
@@ -26,6 +27,7 @@ static const char **pathspec = NULL;
 static const char *tag_cached = "";
 static const char *tag_unmerged = "";
 static const char *tag_removed = "";
+static const char *tag_modified = "";
 static const char *tag_other = "";
 static const char *tag_killed = "";
 
@@ -443,15 +445,18 @@ static void show_files(void)
show_ce_entry(ce_stage(ce) ? tag_unmerged : tag_cached, 
ce);
}
}
-   if (show_deleted) {
+   if (show_deleted | show_modified) {
for (i = 0; i < active_nr; i++) {
struct cache_entry *ce = active_cache[i];
struct stat st;
+   int err;
if (excluded(ce->name) != show_ignored)
continue;
-   if (!lstat(ce->name, &st))
-   continue;
-   show_ce_entry(tag_removed, ce);
+   err = lstat(ce->name, &st);
+   if (show_deleted && err)
+   show_ce_entry(tag_removed, ce);
+   if (show_modified && ce_match_stat(ce, &st))
+   show_ce_entry(tag_modified, ce);
}
}
 }
@@ -547,6 +552,7 @@ int main(int argc, char **argv)
tag_cached = "H ";
tag_unmerged = "M ";
tag_removed = "R ";
+   tag_modified = "C ";
tag_other = "? ";
tag_killed = "K ";
continue;
@@ -559,6 +565,10 @@ int main(int argc, char **argv)
show_deleted = 1;
continue;
}
+   if (!strcmp(arg, "-m") || !strcmp(arg, "--modified")) {
+   show_modified = 1;
+   continue;
+   }
if (!strcmp(arg, "-o") || !strcmp(arg, "--others")) {
show_others = 1;
continue;
@@ -630,7 +640,7 @@ int main(int argc, char **argv)
}
 
/* With no flags, we default to showing the cached files */
-   if (!(show_stage | show_deleted | show_others | show_unmerged | 
show_killed))
+   if (!(show_stage | show_deleted | show_others | show_unmerged | 
show_killed | show_modified))
show_cached = 1;
 
read_cache();

Re: please pull ppc64-2.6.git

[Junio C Hamano]

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 status; please
look for "File/Directory Structure" section of the above URL.

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Any plans to make export work?

[Junio C Hamano]

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 not show the initial import so you
cannot bootstrap from an emptiness.

git-export is among one of the things that were there before all
the modern core features were invented (especially git-rev-list,
let alone --merge-order flag to it) and could use an overhaul.
I would script around rev-list --merge-order and diff-tree
instead of hacking on that C code if I were doing it myself.

But we need to define what we _want_ to see first.

Here is a simple example:

 ---> B --> C --> D
   /  /
 O ---> A ---

The original O forked into branch A and B, merged at C and then
continued on to D.

What the current (admittedly ancient) 'git export' gives is:

commit object O
diff between void and O should be given but it doesn't.
commit object A
diff O A
commit object B
diff O B
commit object C
diff A C
commit object D
diff C D

I just noticed that diff between B and C is not shown.  Come to
think of it, this is _not_ a bug (unlike the initial import not
showing which I think is just a bug).  The purpose of export is
to give you everything that lets you recreate each tree
associated with all commits and their ancestry information, so
as long as you know C is a child of A and B, enough information
to get trees A and B, and diff between A and C, diff between B
and C is simply redundant.  So, in short, export is perfect if
we fix it to show the initial import.  It just is not designed
for doing whatever you are trying to do with its output.

To be usable in your quilt workflow, what output would we want?

Off the top of my head, I can think of this:

commit object O
diff between void and O
commit object A
diff between O and A
commit object B
diff between O and B
commit object C
diff between A and C
diff between B and C
commit object D
diff between C and D

Is this what you can use?  If you can live with something like
the above, 'git whatchanged -p -m --merge-order --root' would
give you exactly that in a reverse order.  It would give you:

commit object D
diff between C and D
commit object C
diff between A and C
diff between B and C
commit object B
diff between O and B
commit object A
diff between O and A
commit object O
diff between void and O

You earlier said "diff between (automerged A+B) and C", but the
former is not something git even records, so you have to compute
it yourself from the given information, if you really want it.

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: gitk with hyperspace support

[Sean]

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 left bump to the grey
> down-arrow (on my system in the kernel tree). Clicking on the blue
> arrow (on the line, not the arrow itself) will turn the blue line
> stricken-
> through with the red line (a bold blue line with a red streak inside),
> the next click leaves me with with just bold blue line and broken
> red line above it.

For what it's worth, everything near that SHA1 works here as expected.  
Although I wasn't able to follow what you meant by "blue up-arrow through
green left bump..." etc.   But all the lines respond to being clicked and
all the arrow heads in that area properly jump to their corresponding
commit.

That's with the latest checked out version of git and tcl/tk 8.4.9 as well.

Sean


-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: gitk with hyperspace support

[Alex Riesen]

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 line on the most left side of the graph
by SHA 66129f88c4cc719591f687e5c8c764fe9d3e437a.
It goes from blue up-arrow  through green left bump to the grey
down-arrow (on my system in the kernel tree). Clicking on the blue
arrow (on the line, not the arrow itself) will turn the blue line stricken-
through with the red line (a bold blue line with a red streak inside),
the next click leaves me with with just bold blue line and broken
red line above it.

It's on Gentoo's Tcl/Tk 8.4.9.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Tim Ottinger]

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 be 'index' now.


--
><>
... either 'way ahead of the game, or 'way out in left field.

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Reworked read-tree.

[Daniel Barkalow]

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 *parse_tree_indirect(const u
>   if (obj->type == tree_type)
>   return (struct tree *) obj;
>   else if (obj->type == commit_type)
> - return ((struct commit *) obj)->tree;
> + obj = (struct object *)(((struct commit *) obj)->tree);

obj = &((struct commit *) obj)->tree->object;

Multiple sequential casts always bother me, and we do actually have a 
field for this.

>   else if (obj->type == tag_type)
> - obj = ((struct tag *) obj)->tagged;
> + obj = deref_tag(obj);

Shouldn't be necessary (once you've got the parse_object below); we're 
already in a loop dereferencing things.

>   else
>   return NULL;
> + if (!obj->parsed)
> + parse_object(obj->sha1);
>   } while (1);
>  }
> 
> 
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] unset CDPATH in git-clone

[Carl Baldwin]

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 problem:

export CDPATH=.
git clone (anything local)

The function get_repo_base seems to break with this CDPATH.

Below is how I solved the problem for the short-term.  Use it as you see
fit.  I did not look into other commands to see if there are other
implications to using CDPATH.

Cheers,
Carl

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 Carl BaldwinSystems VLSI Laboratory
 Hewlett Packard Company
 MS 88   work: 970 898-1523
 3404 E. Harmony Rd. work: [EMAIL PROTECTED]
 Fort Collins, CO 80525  home: [EMAIL PROTECTED]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---

 git-clone-script |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

50e48b03a5a82bb1e4ca95ef4e04cafc39a96f79
diff --git a/git-clone-script b/git-clone-script
--- a/git-clone-script
+++ b/git-clone-script
@@ -5,6 +5,8 @@
 # 
 # Clone a repository into a different directory that does not yet exist.
 
+unset CDPATH
+
 usage() {
echo >&2 "* git clone [-l [-s]] [-q] [-u ]  "
exit 1
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Any plans to make export work?

[Michael Ellerman]

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:
06f81ea8ca09b880cadf101d7e23b500e9c164bc
[PATCH] scsi: remove volatile from scsi data

which doesn't apply as it (seems to) conflict with: 
152587deb8903c0edf483a5b889f975bc6bea7e0
[PATCH] fix NMI lockup with CFQ scheduler

Those two commits (and others) were merged by hand in:
c46f2ffb9e7fce7208c2639790e1ade42e00b146
merge by hand (scsi_device.h)

Export gives me a patch for the merge, but it a) appears to contain everything 
that was merged, not just the fixup-by-hand, and b) export spits it out after 
both of the commits which the merge merged - which is no good as quilt 
doesn't even get that far.

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?

cheers

-- 
Michael Ellerman
IBM OzLabs

email: michael:ellerman.id.au
inmsg: mpe:jabber.org
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person


pgp7wto6cqJCz.pgp
Description: PGP signature

Reworked read-tree.

[Junio C Hamano]

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 tree *parse_tree_indirect(const u
if (obj->type == tree_type)
return (struct tree *) obj;
else if (obj->type == commit_type)
-   return ((struct commit *) obj)->tree;
+   obj = (struct object *)(((struct commit *) obj)->tree);
else if (obj->type == tag_type)
-   obj = ((struct tag *) obj)->tagged;
+   obj = deref_tag(obj);
else
return NULL;
+   if (!obj->parsed)
+   parse_object(obj->sha1);
} while (1);
 }

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html