threads / patch / 6071

patchsha1_name(): accept ':directory/' to get at the cache_tree

Subject: [PATCH] sha1_name(): accept ':directory/' to get at the cache_tree

## tl;dr

10 messages between Dec 22, 2006 and Dec 22, 2006. Diffs are folded; open one to read it.

replies: 9people: 4as markdown or json

Johannes Schindelin· Dec 22, 2006, 02:19 UTC · lore
If the cache tree is not up-to-date, it will be updated first. So, now
	$ git show :Documentation/

will in effect show what files/directories are in the index' version of the directory Documentation. The three commands

	$ git show :./
	$ git show :.
	$ git show :
are all equivalent and show the index' idea of the root directory.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 sha1_name.c |   24 +++++++++++++++++++++++-
 1 files changed, 23 insertions(+), 1 deletions(-)
Show changes to sha1_name.c +23 −1
diff --git a/sha1_name.c b/sha1_name.c
index 6d7cd78..e3758cc 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -5,6 +5,7 @@
 #include "blob.h"
 #include "tree-walk.h"
 #include "refs.h"
+#include "cache-tree.h"
 
 static int find_short_object_filename(int len, const char *name, unsigned char *sha1)
 {
@@ -532,7 +533,7 @@ int get_sha1(const char *name, unsigned char *sha1)
 	 */
 	if (name[0] == ':') {
 		int stage = 0;
-		struct cache_entry *ce;
+		struct cache_entry *ce = NULL;
 		int pos;
 		if (namelen < 3 ||
 		    name[2] != ':' ||
@@ -561,6 +562,27 @@ int get_sha1(const char *name, unsigned char *sha1)
 			}
 			pos++;
 		}
+		if (namelen > 0 && cp[namelen - 1] == '/')
+			namelen--;
+		if (namelen == 1 && cp[0] == '.') {
+			namelen = 0;
+			cp = "";
+		}
+		if (namelen == 0 || (ce && ce_namelen(ce) > namelen &&
+					ce->name[namelen] == '/' &&
+					!memcmp(ce->name, cp, namelen))) {
+			struct cache_tree *tree =
+				cache_tree_find(active_cache_tree, cp);
+			if (!cache_tree_fully_valid(tree)) {
+				ret = cache_tree_update(active_cache_tree,
+						active_cache, active_nr, 0, 0);
+				if (ret < 0)
+					return ret;
+				tree = cache_tree_find(active_cache_tree, cp);
+			}
+			hashcpy(sha1, tree->sha1);
+			return 0;
+		}
 		return -1;
 	}
 	for (cp = name, bracket_depth = 0; *cp; cp++) {

-- 
1.4.4.2.ga854-dirty
Jakub Narebski· Dec 22, 2006, 08:28 UTC · re: Junio C Hamano · lore

Re: [PATCH] sha1_name(): accept ':directory/' to get at the cache_tree

Junio C Hamano wrote:
> (1) Why is this needed?
Probably for completeness.
> (2) What does this do when the index is unmerged?
I think it should show "git ls-files --unmerged --abbrev", perhaps...
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
Johannes Schindelin· Dec 22, 2006, 12:16 UTC · re: Jakub Narebski · lore

Re: [PATCH] sha1_name(): accept ':directory/' to get at the cache_tree

Hi,
On Fri, 22 Dec 2006, Jakub Narebski wrote:
Show 5 quoted lines
> Junio C Hamano wrote:
> 
> > (2) What does this do when the index is unmerged?
> 
> I think it should show "git ls-files --unmerged --abbrev", perhaps...

Nah. I'd rather fail out, saying that because there are unmerged entries, there is no valid tree in the index.

Ciao, Dscho

Jakub Narebski· Dec 22, 2006, 18:05 UTC · re: Johannes Schindelin · lore

Re: [PATCH] sha1_name(): accept ':directory/' to get at the cache_tree

Johannes Schindelin wrote:
Show 10 quoted lines
> On Fri, 22 Dec 2006, Jakub Narebski wrote:
> 
>> Junio C Hamano wrote:
>> 
>>> (2) What does this do when the index is unmerged?
>> 
>> I think it should show "git ls-files --unmerged --abbrev", perhaps...
> 
> Nah. I'd rather fail out, saying that because there are unmerged entries, 
> there is no valid tree in the index.

Well, 'git diff' on unmerged IIRC does 'git diff -cc', so why not 'git show :' do 'git ls-files --unmerged --abbrev'...

-- 
Jakub Narebski
Poland
Johannes Schindelin· Dec 22, 2006, 12:14 UTC · re: Junio C Hamano · lore

Re: [PATCH] sha1_name(): accept ':directory/' to get at the cache_tree

Hi,
On Thu, 21 Dec 2006, Junio C Hamano wrote:
> (1) Why is this needed?

It was asked recently. It also serves well when you want to show the index.

> (2) What does this do when the index is unmerged?
I have no idea, and ATM no time to test. Will do later.

Ciao, Dscho

Johannes Schindelin· Dec 22, 2006, 19:25 UTC · re: Junio C Hamano · lore

Re: [PATCH] sha1_name(): accept ':directory/' to get at the cache_tree

Hi,
On Thu, 21 Dec 2006, Junio C Hamano wrote:
> (2) What does this do when the index is unmerged?
	$ git show :
	a1: unmerged (f16f906ab60483c100d1241dfc39868de9ec9fcb)
	a1: unmerged (cf84443e49e1b366fac938711ddf4be2d4d1d9e9)
	a1: unmerged (fd7923529855d0b274795ae3349c5e0438333979)
	fatal: ambiguous argument ':': unknown revision or path not in the 
	working tree. Use '--' to separate paths from revisions

We could be a bit nicer, but I think the first three lines speak for themselves. This is all stderr BTW.

Ciao, Dscho

Alex Riesen· Dec 22, 2006, 08:44 UTC · re: Johannes Schindelin · lore

Re: [PATCH] sha1_name(): accept ':directory/' to get at the cache_tree

Johannes Schindelin, Fri, Dec 22, 2006 03:19:21 +0100:
Show 13 quoted lines
> 
> If the cache tree is not up-to-date, it will be updated first. So, now
> 
> 	$ git show :Documentation/
> 
> will in effect show what files/directories are in the index' version
> of the directory Documentation. The three commands
> 
> 	$ git show :./
> 	$ git show :.
> 	$ git show :
> 
> are all equivalent and show the index' idea of the root directory.

That is a bit unexpected if you're not in the root directory of repository, but in some subdir of the working directory. Why root? Why not the current directory relative to root?

Johannes Schindelin· Dec 22, 2006, 12:18 UTC · re: Alex Riesen · lore

Re: [PATCH] sha1_name(): accept ':directory/' to get at the cache_tree

Hi,
On Fri, 22 Dec 2006, Alex Riesen wrote:
Show 18 quoted lines
> Johannes Schindelin, Fri, Dec 22, 2006 03:19:21 +0100:
> > 
> > If the cache tree is not up-to-date, it will be updated first. So, now
> > 
> > 	$ git show :Documentation/
> > 
> > will in effect show what files/directories are in the index' version
> > of the directory Documentation. The three commands
> > 
> > 	$ git show :./
> > 	$ git show :.
> > 	$ git show :
> > 
> > are all equivalent and show the index' idea of the root directory.
> 
> That is a bit unexpected if you're not in the root directory of
> repository, but in some subdir of the working directory.
> Why root? Why not the current directory relative to root?

Why root? Because you are not asking for the working directory. Use "ls" for that. You are asking for the index. If you git-show a commit, you don't expect the output to be restricted by the subdirectory you're in, either, right?

CIao, Dscho

Alex Riesen· Dec 22, 2006, 16:09 UTC · re: Johannes Schindelin · lore

Re: [PATCH] sha1_name(): accept ':directory/' to get at the cache_tree

Johannes Schindelin, Fri, Dec 22, 2006 13:18:55 +0100:
Show 21 quoted lines
> > > If the cache tree is not up-to-date, it will be updated first. So, now
> > > 
> > > 	$ git show :Documentation/
> > > 
> > > will in effect show what files/directories are in the index' version
> > > of the directory Documentation. The three commands
> > > 
> > > 	$ git show :./
> > > 	$ git show :.
> > > 	$ git show :
> > > 
> > > are all equivalent and show the index' idea of the root directory.
> > 
> > That is a bit unexpected if you're not in the root directory of
> > repository, but in some subdir of the working directory.
> > Why root? Why not the current directory relative to root?
> 
> Why root? Because you are not asking for the working directory. Use "ls" 
> for that. You are asking for the index. If you git-show a commit, you 
> don't expect the output to be restricted by the subdirectory you're in, 
> either, right?

Of course I do. You're breaking a very well-known and widely used idiom here: the "." means current or at least somehow related to the current directory. Why would you expect "git show :." to show everything from root on if your current directory is "Documentation"? Yes, it is a commit which "git show" displays, but the patches/diffs are restricted by filenames, and that is where the old rules come into play. And I would actually expect ":/" to filter from the root on, and ":." to mean the current directory.

← back to recent threads