What's new in git.git master branch

What's new in git.git master branch

[Junio C Hamano]

As promised (or warned), most of the things are now graduating
from proposed updates to the master branch.  The plan is to
merge this into "maint" by the weekend after field testing
(sorry, you guys are guinea pigs, but I did human experiments on
myself first ;-)), and label that 1.0rc4.  After that, hopefully
no disrupting feature changes until 1.0 final.

Among the miscellaneous fixes, notable recent changes are:

 - bisect can cut down trials if given pathspec (Linus).

 - merge-one-file leaves unmerged entries in index (Linus,
   linux@horizon.com, me).  The recursive merge strategy has
   been also updated to match this but only in no-renaming
   case.

 - diff-files updated to show diff between a higher stage and
   working tree (Linus).  I reverted most of the butchering I
   suggested last night on the list except one obvious bugfix
   Linus agreed.

 - ls-tree rewrite (Linus).

 - making more things work from subdirectories (me).

 - repository format version futureproofing (Martin Atukunda and
   me).  A fix by Tommi Virtanen for the bug reported by David
   Woodhouse is included here.

 - improved gitk (Paulus, Yann Dirson, Pavel Roskin)

I am still holding back "Disable USE_SYMLINK_HEAD" by Pavel
Roskin in the proposed updates branch.  This makes symref
everywhere, not only on symbolic-challenged platforms, to
represent HEAD link.  As far as I know, Cogito and StGIT are
ready for this change, but this will break gitweb, which
directly reads from $project/HEAD to find out the object name of
the HEAD commit (it needs to do `GIT_DIR=$project git-rev-parse
HEAD` now).  I think we earlier agreed that this patch will go
in sometime after 1.0; correct me if I am wrong.

One interesting change is ls-tree rewrite by Linus.  The command
does _not_ show tree nodes when running with -r flag anymore.
Running "git diff v0.99.9i t/t3100-ls-tree-restrict.sh"
after updating to the master tells you the summary of changes in
the behaviour.

I've looked at gitweb, Cogito and StGIT to see if this breaks
things, and while I think it is safe for these three, authors of
Porcelains including these three are asked to double check.

Particularly interesting one is cg-log, which only uses
"git-ls-tree -r" to show the list of things being committed for
the initial commit, and this change actually fixes a small bug
there (I think with the ls-tree before this change it would end
up listing tree entries).  cg-restore guards itself with a sed
script from ls-tree spitting out entries other than blob, so it
is not affected, but it could lose that guard now.

Another improvement is around git-merge-one-file and
git-diff-files to change how the conflicting path information is
left in the index after a failed automerge.  This change was
prompted by a question from linux@horizon.com (do you have a
real name?).  We leave the failed merge result in the working
tree with conflict markers as before, but unlike the previous
round which registered the HEAD commit version at stage0 in the
index file, we now leave the index entries unmerged.  "git diff"
command can be used to see what the changes from our HEAD commit
is as before, but you can also say "git diff --base" to see the
differences from the merge base, and "git diff --theirs" to see
the differences from the other branch that was merged.

Re: What's new in git.git master branch

[Fredrik Kuivinen]

On Wed, Nov 30, 2005 at 02:57:06PM -0800, Junio C Hamano wrote:

[...]

>  - ls-tree rewrite (Linus).

[...]

> One interesting change is ls-tree rewrite by Linus.  The command
> does _not_ show tree nodes when running with -r flag anymore.
> Running "git diff v0.99.9i t/t3100-ls-tree-restrict.sh"
> after updating to the master tells you the summary of changes in
> the behaviour.

It turns out that this change breaks the directory/file conflict
handling in git-merge-recursive. Right now merge-recursive uses

   git-ls-tree -r -z <tree SHA1>

to get a listing of every blob object (which corresponds to files) and
every tree object (which corresponds to directories) in the tree
designated by the SHA1. With the new ls-tree behaviour we don't get
any tree objects and hence merge-recursive can't do the d/f conflict
detection as it doesn't know about the directories. As we don't track
empty directories it could be fixed within git-merge-recursive, a list
of the directory names can be obtained from the list of file names by
stripping everything after the last slash in the file names.

Should we do it that way or should ls-tree be changed?

- Fredrik

Re: What's new in git.git master branch

[Junio C Hamano]

Fredrik Kuivinen <freku045@student.liu.se> writes:

> It turns out that this change breaks the directory/file conflict
> handling in git-merge-recursive.
>
>    git-ls-tree -r -z <tree SHA1>
>
> Should we do it that way or should ls-tree be changed?

Ouch.  Sorry, I should have been more careful.  For this
particular one, I think updating merge-recursive is less work,
so for now I'd vote for that approach.  However, as you might
already be aware, I am not convinced that the new behaviour is
better than the previous round (there is no question about the
implementation quality and the clean-up value the rewrite
brings), so we might want to also add the "show tree entry in
recursive cases too" option to ls-tree as well.  What I am
saying is essentially, "why not do both?" ;-).

I was looking at the merge-recursive, and there is another topic
I wanted to discuss with you about.  Conflicts in renaming
merges and index collapsing.  The latest merge-one-file leaves
index entries uncollapsed when the file content changes cannot
be automerged, and I think we would want to match that in
merge-recursive.  When there is no rename involved it can do the
same thing as merge-one-file does -- just leave the index
unmerged.  Renaming case is different.

Currently, rename result is recorded by using "git-update-index
--cacheinfo" to populate the index.  This method unfortunately
can only create a stage0 entry.  We can go two ways.  One way is
to support "register this mode/sha1 tuple at stageN for path" to
update-index.  Another would be for merge-recursive to first
construct three trees with the final directory structure
(i.e. prepare three temporary trees with renames applied) and
run read-tree 3-way merge on these temporary trees.  I suspect
the former is probably of lesser impact.  Thoughts?

Also I think I broke the case where base trees need to be merged
in 58cce8a8 commit (I changed processEntry not to collapse the
index entry when file content changes cannot be automerged, but
that change has to be done only for the final merge, and merges
between base trees must collapse to be able to write the index
file out as a tree).

Re: What's new in git.git master branch

[Junio C Hamano]

Junio C Hamano <junkio@cox.net> writes:

> Fredrik Kuivinen <freku045@student.liu.se> writes:
>
>> It turns out that this change breaks the directory/file conflict
>> handling in git-merge-recursive.
>>
>>    git-ls-tree -r -z <tree SHA1>
>>
>> Should we do it that way or should ls-tree be changed?
>
> Ouch.  Sorry, I should have been more careful.

So we updated ls-tree to take -t flag which shows tree entries
under -r flag.  I'd appreciate if you test the attached patch.

> Also I think I broke the case where base trees need to be merged
> in 58cce8a8 commit (I changed processEntry not to collapse the
> index entry when file content changes cannot be automerged, but
> that change has to be done only for the final merge, and merges
> between base trees must collapse to be able to write the index
> file out as a tree).

I think that the above worry was unfounded, because the
updateFileExt call I removed to prevent it from collapsing the
unmerged entries was in effect only in !cacheOnly case
(i.e. callDepth == 0).

Re: What's new in git.git master branch

[Junio C Hamano]

Junio C Hamano <junkio@cox.net> writes:

> Fredrik Kuivinen <freku045@student.liu.se> writes:
>
>> It turns out that this change breaks the directory/file conflict
>> handling in git-merge-recursive.
>>
>>    git-ls-tree -r -z <tree SHA1>
>>
>> Should we do it that way or should ls-tree be changed?
>
> Ouch.  Sorry, I should have been more careful.

So we updated ls-tree to take -t flag which shows tree entries
under -r flag.  I'd appreciate if you test the attached patch.

> Also I think I broke the case where base trees need to be merged
> in 58cce8a8 commit (I changed processEntry not to collapse the
> index entry when file content changes cannot be automerged, but
> that change has to be done only for the final merge, and merges
> between base trees must collapse to be able to write the index
> file out as a tree).

I think that the above worry was unfounded, because the
updateFileExt call I removed to prevent it from collapsing the
unmerged entries was in effect only in !cacheOnly case
(i.e. callDepth == 0).

-- >8 --
[PATCH] merge-recursive: adjust git-ls-tree use for the latest.

You need to pass -t flag if you want to see tree objects in
"git-ls-tree -r" output these days.  This change broke the tree
structure reading code in git-merge-recursive used to detect D/F
conflicts.

Signed-off-by: Junio C Hamano <junkio@cox.net>

---

 git-merge-recursive.py |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

a6b51f11ab7f7f838a9b17f81059eebfc36e4c84
diff --git a/git-merge-recursive.py b/git-merge-recursive.py
index e599b11..b7fb096 100755
--- a/git-merge-recursive.py
+++ b/git-merge-recursive.py
@@ -98,7 +98,7 @@ getFilesRE = re.compile(r'^([0-7]+) (\S+
 def getFilesAndDirs(tree):
     files = Set()
     dirs = Set()
-    out = runProgram(['git-ls-tree', '-r', '-z', tree])
+    out = runProgram(['git-ls-tree', '-r', '-z', '-t', tree])
     for l in out.split('\0'):
         m = getFilesRE.match(l)
         if m:
-- 
0.99.9.GIT

Re: What's new in git.git master branch

[Fredrik Kuivinen]

On Thu, Dec 01, 2005 at 09:46:12PM -0800, Junio C Hamano wrote:
> Junio C Hamano <junkio@cox.net> writes:
> 
> > Fredrik Kuivinen <freku045@student.liu.se> writes:
> >
> >> It turns out that this change breaks the directory/file conflict
> >> handling in git-merge-recursive.
> >>
> >>    git-ls-tree -r -z <tree SHA1>
> >>
> >> Should we do it that way or should ls-tree be changed?
> >
> > Ouch.  Sorry, I should have been more careful.
> 
> So we updated ls-tree to take -t flag which shows tree entries
> under -r flag.  I'd appreciate if you test the attached patch.

With the patch tt works properly again. Thanks :)

> > Also I think I broke the case where base trees need to be merged
> > in 58cce8a8 commit (I changed processEntry not to collapse the
> > index entry when file content changes cannot be automerged, but
> > that change has to be done only for the final merge, and merges
> > between base trees must collapse to be able to write the index
> > file out as a tree).
> 
> I think that the above worry was unfounded, because the
> updateFileExt call I removed to prevent it from collapsing the
> unmerged entries was in effect only in !cacheOnly case
> (i.e. callDepth == 0).

Yes, the code is correct. You can apply the following patch to make it
a bit simpler.

- Fredrik

--
merge-recursive: Clean up index updates

Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>


---

 git-merge-recursive.py |    5 +----
 1 files changed, 1 insertions(+), 4 deletions(-)

66b1a0157f25629b35ecf300450618a230741218
diff --git a/git-merge-recursive.py b/git-merge-recursive.py
index b7fb096..4f061da 100755
--- a/git-merge-recursive.py
+++ b/git-merge-recursive.py
@@ -825,10 +825,7 @@ def processEntry(entry, branch1Name, bra
             cleanMerge = False
             output('CONFLICT (content): Merge conflict in', path)
 
-            if cacheOnly:
-                updateFile(False, sha, mode, path)
-            else:
-                updateFileExt(sha, mode, path, updateCache=False, updateWd=True)
+            updateFile(False, sha, mode, path)
     else:
         die("ERROR: Fatal merge failure, shouldn't happen.")
 
-- 
0.99.9.GIT

Re: What's new in git.git master branch

[Fredrik Kuivinen]

On Thu, Dec 01, 2005 at 01:38:47AM -0800, Junio C Hamano wrote:

> Currently, rename result is recorded by using "git-update-index
> --cacheinfo" to populate the index.  This method unfortunately
> can only create a stage0 entry.  We can go two ways.  One way is
> to support "register this mode/sha1 tuple at stageN for path" to
> update-index.  Another would be for merge-recursive to first
> construct three trees with the final directory structure
> (i.e. prepare three temporary trees with renames applied) and
> run read-tree 3-way merge on these temporary trees.  I suspect
> the former is probably of lesser impact.  Thoughts?

If we really want to do this then the former is certainly easier from
the perspective of git-merge-recursive.

- Fredrik

[PATCH 3/3] update-index: allow --index-info to add higher stages.

[Junio C Hamano]

The new merge world order tells the merge strategies to leave
the cache unmerged and store the automerge result in the working
tree if automerge is not clean.  This was done for the resolve
strategy and recursive strategy when no rename is involved, but
recording a conflicting merge in the rename case could not
easily be done by the recursive strategy.

This commit adds a new input format, in addition to the exsting
two, to "update-index --index-info".

    (1) mode         SP sha1          TAB path
    The first format is what "git-apply --index-info"
    reports, and used to reconstruct a partial tree
    that is used for phony merge base tree when falling
    back on 3-way merge.

    (2) mode SP type SP sha1          TAB path
    The second format is to stuff git-ls-tree output
    into the index file.

    (3) mode         SP sha1 SP stage TAB path
    This format is to put higher order stages into the
    index file and matches git-ls-files --stage output.

To place a higher stage entry to the index, the path should
first be removed by feeding a mode=0 entry for the path, and
then feeding necessary input lines in the (3) format.

For example, starting with this index:

$ git ls-files -s
100644 8a1218a1024a212bb3db30becd860315f9f3ac52 0       frotz

$ git update-index --index-info ;# interactive session -- input follows...

0 0000000000000000000000000000000000000000	frotz
100644 8a1218a1024a212bb3db30becd860315f9f3ac52 1	frotz
100755 8a1218a1024a212bb3db30becd860315f9f3ac52 2	frotz

The first line of the input feeds 0 as the mode to remove the
path; the SHA1 does not matter as long as it is well formatted.
Then the second and third line feeds stage 1 and stage 2 entries
for that path.  After the above, we would end up with this:

$ git ls-files -s
100644 8a1218a1024a212bb3db30becd860315f9f3ac52 1	frotz
100755 8a1218a1024a212bb3db30becd860315f9f3ac52 2	frotz

This completes the groundwork for the new merge world order.

Signed-off-by: Junio C Hamano <junkio@cox.net>

---

 Documentation/git-update-index.txt |   57 +++++++++++++++++++++++++++++++++
 update-index.c                     |   63 ++++++++++++++++++++++++++----------
 2 files changed, 103 insertions(+), 17 deletions(-)

d23748a6af3e3db2b239090553f92c3a779b3578
diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt
index e4678cd..c74311d 100644
--- a/Documentation/git-update-index.txt
+++ b/Documentation/git-update-index.txt
@@ -136,6 +136,63 @@ in the database but the file isn't avail
 useful when the file is available, but you do not wish to update the
 object database.
 
+
+Using --index-info
+------------------
+
+`--index-info` is a more powerful mechanism that lets you feed
+multiple entry definitions from the standard input, and designed
+specifically for scripts.  It can take inputs of three formats:
+
+    . mode         SP sha1          TAB path
++
+The first format is what "git-apply --index-info"
+reports, and used to reconstruct a partial tree
+that is used for phony merge base tree when falling
+back on 3-way merge.
+
+    . mode SP type SP sha1          TAB path
++
+The second format is to stuff git-ls-tree output
+into the index file.
+
+    . mode         SP sha1 SP stage TAB path
++
+This format is to put higher order stages into the
+index file and matches git-ls-files --stage output.
+
+To place a higher stage entry to the index, the path should
+first be removed by feeding a mode=0 entry for the path, and
+then feeding necessary input lines in the third format.
+
+For example, starting with this index:
+
+------------
+$ git ls-files -s
+100644 8a1218a1024a212bb3db30becd860315f9f3ac52 0       frotz
+------------
+
+you can feed the following input to `--index-info`:
+
+------------
+$ git update-index --index-info
+0 0000000000000000000000000000000000000000	frotz
+100644 8a1218a1024a212bb3db30becd860315f9f3ac52 1	frotz
+100755 8a1218a1024a212bb3db30becd860315f9f3ac52 2	frotz
+------------
+
+The first line of the input feeds 0 as the mode to remove the
+path; the SHA1 does not matter as long as it is well formatted.
+Then the second and third line feeds stage 1 and stage 2 entries
+for that path.  After the above, we would end up with this:
+
+------------
+$ git ls-files -s
+100644 8a1218a1024a212bb3db30becd860315f9f3ac52 1	frotz
+100755 8a1218a1024a212bb3db30becd860315f9f3ac52 2	frotz
+------------
+
+
 Examples
 --------
 To update and refresh only the files already checked out:
diff --git a/update-index.c b/update-index.c
index 11b7f6a..be87b99 100644
--- a/update-index.c
+++ b/update-index.c
@@ -256,35 +256,30 @@ inside:
 	}
 }
 
-static int add_cacheinfo(const char *arg1, const char *arg2, const char *arg3)
+static int add_cacheinfo(unsigned int mode, const unsigned char *sha1,
+			 const char *path, int stage)
 {
 	int size, len, option;
-	unsigned int mode;
-	unsigned char sha1[20];
 	struct cache_entry *ce;
 
-	if (sscanf(arg1, "%o", &mode) != 1)
-		return -1;
-	if (get_sha1_hex(arg2, sha1))
-		return -1;
-	if (!verify_path(arg3))
+	if (!verify_path(path))
 		return -1;
 
-	len = strlen(arg3);
+	len = strlen(path);
 	size = cache_entry_size(len);
 	ce = xmalloc(size);
 	memset(ce, 0, size);
 
 	memcpy(ce->sha1, sha1, 20);
-	memcpy(ce->name, arg3, len);
-	ce->ce_flags = htons(len);
+	memcpy(ce->name, path, len);
+	ce->ce_flags = create_ce_flags(len, stage);
 	ce->ce_mode = create_ce_mode(mode);
 	option = allow_add ? ADD_CACHE_OK_TO_ADD : 0;
 	option |= allow_replace ? ADD_CACHE_OK_TO_REPLACE : 0;
 	if (add_cache_entry(ce, option))
 		return error("%s: cannot add to the index - missing --add option?",
-			     arg3);
-	report("add '%s'", arg3);
+			     path);
+	report("add '%s'", path);
 	return 0;
 }
 
@@ -342,7 +337,24 @@ static void read_index_info(int line_ter
 		char *path_name;
 		unsigned char sha1[20];
 		unsigned int mode;
+		int stage;
 
+		/* This reads lines formatted in one of three formats:
+		 *
+		 * (1) mode         SP sha1          TAB path
+		 * The first format is what "git-apply --index-info"
+		 * reports, and used to reconstruct a partial tree
+		 * that is used for phony merge base tree when falling
+		 * back on 3-way merge.
+		 *
+		 * (2) mode SP type SP sha1          TAB path
+		 * The second format is to stuff git-ls-tree output
+		 * into the index file.
+		 * 
+		 * (3) mode         SP sha1 SP stage TAB path
+		 * This format is to put higher order stages into the
+		 * index file and matches git-ls-files --stage output.
+		 */
 		read_line(&buf, stdin, line_termination);
 		if (buf.eof)
 			break;
@@ -354,9 +366,19 @@ static void read_index_info(int line_ter
 		tab = strchr(ptr, '\t');
 		if (!tab || tab - ptr < 41)
 			goto bad_line;
+
+		if (tab[-2] == ' ' && '1' <= tab[-1] && tab[-1] <= '3') {
+			stage = tab[-1] - '0';
+			ptr = tab + 1; /* point at the head of path */
+			tab = tab - 2; /* point at tail of sha1 */
+		}
+		else {
+			stage = 0;
+			ptr = tab + 1; /* point at the head of path */
+		}
+
 		if (get_sha1_hex(tab - 40, sha1) || tab[-41] != ' ')
 			goto bad_line;
-		ptr = tab + 1;
 
 		if (line_termination && ptr[0] == '"')
 			path_name = unquote_c_style(ptr, NULL);
@@ -382,7 +404,7 @@ static void read_index_info(int line_ter
 			 * ptr[-41] is at the beginning of sha1
 			 */
 			ptr[-42] = ptr[-1] = 0;
-			if (add_cacheinfo(buf.buf, ptr-41, path_name))
+			if (add_cacheinfo(mode, sha1, path_name, stage))
 				die("git-update-index: unable to update %s",
 				    path_name);
 		}
@@ -449,10 +471,17 @@ int main(int argc, const char **argv)
 				continue;
 			}
 			if (!strcmp(path, "--cacheinfo")) {
+				unsigned char sha1[20];
+				unsigned int mode;
+
 				if (i+3 >= argc)
 					die("git-update-index: --cacheinfo <mode> <sha1> <path>");
-				if (add_cacheinfo(argv[i+1], argv[i+2], argv[i+3]))
-					die("git-update-index: --cacheinfo cannot add %s", argv[i+3]);
+
+				if ((sscanf(argv[i+1], "%o", &mode) != 1) ||
+				    get_sha1_hex(argv[i+2], sha1) ||
+				    add_cacheinfo(mode, sha1, argv[i+3], 0))
+					die("git-update-index: --cacheinfo"
+					    " cannot add %s", argv[i+3]);
 				i += 3;
 				continue;
 			}
-- 
0.99.9.GIT

git-ls-tree: add "-t" option to always show the tree entries

[Linus Torvalds]

The old (new) behaviour was that it only shows trees if the object is 
specified exactly, and recursive is not set. That makes sense, because 
there is obviously nothing else it can show for that case.

However, with the new "-t" option, it will show the tree even with "-r", 
as it traverses down into it.

NOTE! This also means that it will show all trees leading up to that tree. 

For example, if you do a

	git-ls-tree -t HEAD -- drivers/char/this/file/does/not/exist

it will show the trees that lead up to the files that do not exist:

	[torvalds@g5 linux]$ git-ls-tree -t HEAD -- drivers/char/this/file/does/not/exist
	040000 tree 9cb687b77dcd64bf82e9a73214db467c964c1266    drivers
	040000 tree 298e2fadf0ff3867d1ef49936fd2c7bf6ce1eb66    drivers/char
	[torvalds@g5 linux]$

and note how this is true even though I didn't specify "-r": the fact that 
I supplied a pathspec automatically implies "enough recursion" for that 
particular pathspec.

I think the code is cleaner and easier to understand too: the patch looks 
bigger, but it's really just splitting up the "should we recurse into this 
tree" into a function of its own.

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
----

This obviously means that to fix merge-recursive, we should add that "-t" 
flag to it, but then hopefully everything should be ok? Do you have a 
test-case, and perhaps something we could add to "make test".

Talking about "make test", this doesn't break any (since it doesn't change 
behaviour without the "-t" flag), but maybe it should add some. But I'm 
lazy.

On Thu, 1 Dec 2005, Fredrik Kuivinen wrote:
> 
> It turns out that this change breaks the directory/file conflict
> handling in git-merge-recursive. Right now merge-recursive uses
> 
>    git-ls-tree -r -z <tree SHA1>
> 
> to get a listing of every blob object (which corresponds to files) and
> every tree object (which corresponds to directories) in the tree
> designated by the SHA1.

diff --git a/ls-tree.c b/ls-tree.c
index d4b6219..a2a5eb0 100644
--- a/ls-tree.c
+++ b/ls-tree.c
@@ -11,39 +11,53 @@
 static int line_termination = '\n';
 #define LS_RECURSIVE 1
 #define LS_TREE_ONLY 2
+#define LS_SHOW_TREES 4
 static int ls_options = 0;
 const char **pathspec;
 
 static const char ls_tree_usage[] =
-	"git-ls-tree [-d] [-r] [-z] <tree-ish> [path...]";
+	"git-ls-tree [-d] [-r] [-t] [-z] <tree-ish> [path...]";
+
+static int show_recursive(const char *base, int baselen, const char *pathname)
+{
+	const char **s;
+
+	if (ls_options & LS_RECURSIVE)
+		return 1;
+
+	s = pathspec;
+	if (!s)
+		return 0;
+
+	for (;;) {
+		const char *spec = *s++;
+		int len, speclen;
+
+		if (!spec)
+			return 0;
+		if (strncmp(base, spec, baselen))
+			continue;
+		len = strlen(pathname);
+		spec += baselen;
+		speclen = strlen(spec);
+		if (speclen <= len)
+			continue;
+		if (memcmp(pathname, spec, len))
+			continue;
+		return 1;
+	}
+}
 
 static int show_tree(unsigned char *sha1, const char *base, int baselen, const char *pathname, unsigned mode, int stage)
 {
+	int retval = 0;
 	const char *type = "blob";
 
 	if (S_ISDIR(mode)) {
-		const char **s;
-		if (ls_options & LS_RECURSIVE)
-			return READ_TREE_RECURSIVE;
-		s = pathspec;
-		if (s) {
-			for (;;) {
-				const char *spec = *s++;
-				int len, speclen;
-
-				if (!spec)
-					break;
-				if (strncmp(base, spec, baselen))
-					continue;
-				len = strlen(pathname);
-				spec += baselen;
-				speclen = strlen(spec);
-				if (speclen <= len)
-					continue;
-				if (memcmp(pathname, spec, len))
-					continue;
-				return READ_TREE_RECURSIVE;
-			}
+		if (show_recursive(base, baselen, pathname)) {
+			retval = READ_TREE_RECURSIVE;
+			if (!(ls_options & LS_SHOW_TREES))
+				return retval;
 		}
 		type = "tree";
 	}
@@ -51,7 +65,7 @@ static int show_tree(unsigned char *sha1
 	printf("%06o %s %s\t", mode, type, sha1_to_hex(sha1));
 	write_name_quoted(base, baselen, pathname, line_termination, stdout);
 	putchar(line_termination);
-	return 0;
+	return retval;
 }
 
 int main(int argc, const char **argv)
@@ -73,6 +87,9 @@ int main(int argc, const char **argv)
 		case 'd':
 			ls_options |= LS_TREE_ONLY;
 			break;
+		case 't':
+			ls_options |= LS_SHOW_TREES;
+			break;
 		default:
 			usage(ls_tree_usage);
 		}

Re: git-ls-tree: add "-t" option to always show the tree entries

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> writes:

> NOTE! This also means that it will show all trees leading up to that tree. 

... which is logical but slightly unexpected.  Also I noticed we
lost '-d' but still accept it as an option, so...

-- >8 --
[PATCH]: ls-tree: resurrect '-d' to mean 'show trees only'

With this:

	git-ls-tree -d HEAD -- drivers/net/

shows only immediate subtrees of drivers/net.

	git-ls-tree -d -t HEAD -- drivers/net/

shows drivers, drivers/net and immediate subtrees of
drivers/net.

	git-ls-tree -d -r HEAD -- drivers/net/

shows drivers, drivers/net and all subtrees of drivers/net (but
not blobs).

Signed-off-by: Junio C Hamano <junkio@cox.net>
---

 * The practical value of this patch is dubious, and we might
   want to simply remove '-d' from the options.  But the output
   from this looks kind-of nice.  Thoughts?

diff --git a/ls-tree.c b/ls-tree.c
index a2a5eb0..07db863 100644
--- a/ls-tree.c
+++ b/ls-tree.c
@@ -61,6 +61,8 @@ static int show_tree(unsigned char *sha1
 		}
 		type = "tree";
 	}
+	else if (ls_options & LS_TREE_ONLY)
+		return 0;
 
 	printf("%06o %s %s\t", mode, type, sha1_to_hex(sha1));
 	write_name_quoted(base, baselen, pathname, line_termination, stdout);
@@ -95,6 +97,10 @@ int main(int argc, const char **argv)
 		}
 		argc--; argv++;
 	}
+	/* -d -r should imply -t, but -d by itself should not have to. */
+	if ( (LS_TREE_ONLY|LS_RECURSIVE) ==
+	    ((LS_TREE_ONLY|LS_RECURSIVE) & ls_options))
+		ls_options |= LS_SHOW_TREES;
 
 	if (argc < 2)
 		usage(ls_tree_usage);

Re: git-ls-tree: add "-t" option to always show the tree entries

[Linus Torvalds]

On Thu, 1 Dec 2005, Junio C Hamano wrote:
> Linus Torvalds <torvalds@osdl.org> writes:
> 
> > NOTE! This also means that it will show all trees leading up to that tree. 
> 
> ... which is logical but slightly unexpected.  Also I noticed we
> lost '-d' but still accept it as an option, so...

Yes. I like the notion of doing

	git-ls-tree -r -d HEAD

to get a full list of directories for the project.

That brings up another issue. I typed

	git-ls-tree -r --name-only ..

and it obviously didn't work. That's kind of sad. I use that quite a lot 
for "git diff", for example, because quite often I want to see the files, 
but I don't care about anything else.

Maybe nobody else uses that "--name-only" thing.

		Linus

Re: git-ls-tree: add "-t" option to always show the tree entries

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> writes:

> Maybe nobody else uses that "--name-only" thing.

I often use --name-status for diff, so that makes me nobody.

[PATCH] ls-tree: --name-only

[Junio C Hamano]

Fingers of some "git diff" users are trained to do --name-only
which git-ls-tree unfortunately does not take.  With this,

	cd sub/directory && git-ls-tree -r --name-only HEAD -- ..

would show only the paths but not object names nor modes.  I
threw in another synonym --name-status only for usability, but
obviously ls-tree does not do any comparison so what it does is
the same as --name-only.

Signed-off-by: Junio C Hamano <junkio@cox.net>

---

  Linus Torvalds <torvalds@osdl.org> writes:

  > That brings up another issue. I typed
  >
  > 	git-ls-tree -r --name-only ..
  >
  > and it obviously didn't work. That's kind of sad. I use that quite a lot 
  > for "git diff", for example, because quite often I want to see the files, 
  > but I don't care about anything else.

 ls-tree.c |   13 +++++++++++--
 1 files changed, 11 insertions(+), 2 deletions(-)

c639a5548a5d8414b55202592885449f66ee2f33
diff --git a/ls-tree.c b/ls-tree.c
index 07db863..dae377d 100644
--- a/ls-tree.c
+++ b/ls-tree.c
@@ -12,11 +12,12 @@ static int line_termination = '\n';
 #define LS_RECURSIVE 1
 #define LS_TREE_ONLY 2
 #define LS_SHOW_TREES 4
+#define LS_NAME_ONLY 8
 static int ls_options = 0;
 const char **pathspec;
 
 static const char ls_tree_usage[] =
-	"git-ls-tree [-d] [-r] [-t] [-z] <tree-ish> [path...]";
+	"git-ls-tree [-d] [-r] [-t] [-z] [--name-only] [--name-status] <tree-ish> [path...]";
 
 static int show_recursive(const char *base, int baselen, const char *pathname)
 {
@@ -64,7 +65,8 @@ static int show_tree(unsigned char *sha1
 	else if (ls_options & LS_TREE_ONLY)
 		return 0;
 
-	printf("%06o %s %s\t", mode, type, sha1_to_hex(sha1));
+	if (!(ls_options & LS_NAME_ONLY))
+		printf("%06o %s %s\t", mode, type, sha1_to_hex(sha1));
 	write_name_quoted(base, baselen, pathname, line_termination, stdout);
 	putchar(line_termination);
 	return retval;
@@ -92,6 +94,13 @@ int main(int argc, const char **argv)
 		case 't':
 			ls_options |= LS_SHOW_TREES;
 			break;
+		case '-':
+			if (!strcmp(argv[1]+2, "name-only") ||
+			    !strcmp(argv[1]+2, "name-status")) {
+				ls_options |= LS_NAME_ONLY;
+				break;
+			}
+			/* otherwise fallthru */
 		default:
 			usage(ls_tree_usage);
 		}
-- 
0.99.9.GIT

Re: git-ls-tree: add "-t" option to always show the tree entries

[Junio C Hamano]

Linus Torvalds <torvalds <at> osdl.org> writes:

> That brings up another issue. I typed
> 
> 	git-ls-tree -r --name-only ..
> 
> and it obviously didn't work.

This brings up another issue.  When git-ls-tree works from subdirectory,
do we want to see repository-relative paths, or cwd relative paths?
Currently we do the latter.

Re: git-ls-tree: add "-t" option to always show the tree entries

[Linus Torvalds]

On Fri, 2 Dec 2005, Junio C Hamano wrote:
> 
> This brings up another issue.  When git-ls-tree works from subdirectory,
> do we want to see repository-relative paths, or cwd relative paths?
> Currently we do the latter.

Umm, I'd not say that we do the latter, but yeah, that's broken. We 
actually do _filter_ based on the cwd, but then we show the whole path, 
which makes no sense.

Something like this?

		Linus

---
diff --git a/ls-tree.c b/ls-tree.c
index dae377d..09dc34d 100644
--- a/ls-tree.c
+++ b/ls-tree.c
@@ -14,6 +14,7 @@ static int line_termination = '\n';
 #define LS_SHOW_TREES 4
 #define LS_NAME_ONLY 8
 static int ls_options = 0;
+static int skip_chars = 0;
 const char **pathspec;
 
 static const char ls_tree_usage[] =
@@ -65,6 +66,12 @@ static int show_tree(unsigned char *sha1
 	else if (ls_options & LS_TREE_ONLY)
 		return 0;
 
+	/* Normalize to cwd */
+	if (baselen < skip_chars)
+		return retval;
+	base += skip_chars;
+	baselen -= skip_chars;
+
 	if (!(ls_options & LS_NAME_ONLY))
 		printf("%06o %s %s\t", mode, type, sha1_to_hex(sha1));
 	write_name_quoted(base, baselen, pathname, line_termination, stdout);
@@ -116,6 +123,9 @@ int main(int argc, const char **argv)
 	if (get_sha1(argv[1], sha1) < 0)
 		usage(ls_tree_usage);
 
+
+	if (prefix)
+		skip_chars = strlen(prefix);
 	pathspec = get_pathspec(prefix, argv + 2);
 	buf = read_object_with_reference(sha1, "tree", &size, NULL);
 	if (!buf)