[PATCH 2/2] Make git-update-cache take relative pathnames
This also makes ./filename acceptable as a side effect, since the
pathname normalization handles that too.
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
---
update-cache.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
ece92eeda777c3141f5692132ccc2ba7e4e801a2
diff --git a/update-cache.c b/update-cache.c
--- a/update-cache.c
+++ b/update-cache.c
@@ -321,6 +321,7 @@ int main(int argc, char **argv)
{
int i, newfd, entries, has_errors = 0;
int allow_options = 1;
+ const char *prefix = setup_git_directory();
newfd = hold_index_file_for_update(cache_file, get_index_file());
if (newfd 0)
@@ -381,6 +382,7 @@ int main(int argc, char **argv)
}
die(unknown option %s, path);
}
+ path = prefix_path(prefix, prefix ? strlen(prefix) : 0, path);
if (!verify_path(path)) {
fprintf(stderr, Ignoring path %s\n, argv[i]);
continue;
-
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: Why is there no git-update-cache --modified (aka I give up)
Dear diary, on Tue, Jul 12, 2005 at 07:52:18AM CEST, I got a letter where Marc Singer [EMAIL PROTECTED] told me that... # git-diff-cache HEAD is really nice. But, do I really have to invoke git-update-cache with every modified file? I could write a script to cul the filenames from git-diff-cache, but I'm having a hard time believing that that is how others are preparing their commits. It is. :-) It's only that they have cool scripts to do it, e.g. cg-commit. (You have to enumerate the files explicitly for git-commit-script as well, IIRC.) -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ Espy be careful, some twit might quote you out of context.. - 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: Why is there no git-update-cache --modified (aka I give up)
Marc Singer [EMAIL PROTECTED] writes: # git-diff-cache HEAD is really nice. But, do I really have to invoke git-update-cache with every modified file? I could write a script to cul the filenames from git-diff-cache, but I'm having a hard time believing that that is how others are preparing their commits. Me too. By the way, I think you mean diff-files not diff-cache. I'd like to know how others do it, since this was the first thing I automated when I started using GIT. Having clear distinction between cache (aka index file) and work tree files and making user concious decision of when to and when not to register/update index is what is quite different in GIT from CVS, SVN and friends [*1*], and while I appreciate its flexibility, it often ends up to be simply more typing (and to certain degree more thinking which is not a bad thing) to the user [*2*]. This snippet is essentially what I do to match the cache with the current work tree [*3*]: case $(git-ls-files --unmerged | sed -e 1q) in ?*) echo 2 You have unmerged files and cannot commit. exit 1 ;; esac git-update-cache --refresh /dev/null git-diff-files | sed -e 's/.*//' | xargs -r git-update-cache --add --remove -- [Footnote] *1* I vaguely recall reading somewhere that GIT is not the first SCM to have these three (not two) levels. Usual two-level SCM needs to only move between your hackery and what's in the repo, and words like committing and checking in are used interchangeably, while the other three level SCM (I do not remember which one I read about) gives distinct meaning to these two words. Can anybody tell me which SCM I am talking about? *2* The commit flow in GIT is three level thing. You have HEAD version (a commit with an associated tree already in the object database that you have checked out and started with), you have cache, and you have files in your work tree. Checking out is to match cache and work tree to HEAD; update-cache is to match cache to work tree; and committing is to create a new commit that matches the cache and make it your HEAD. Roughly speaking, diff-* brothers are about comparing these three stages: - diff-files compares cache and work tree - diff-cache compares commit and cache, or commit and work tree - diff-tree compares two commits *3* I do not officially do Porcelain ;-), but the script I use is slightly different from the one quoted above. It uses git-diff-files -z and a helper program to handle filenames with TAB in them. - 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: Why is there no git-update-cache --modified (aka I give up)
On Tue, Jul 12, 2005 at 01:14:24AM -0700, Junio C Hamano wrote: Marc Singer [EMAIL PROTECTED] writes: # git-diff-cache HEAD is really nice. But, do I really have to invoke git-update-cache with every modified file? I could write a script to cul the filenames from git-diff-cache, but I'm having a hard time believing that that is how others are preparing their commits. Me too. By the way, I think you mean diff-files not diff-cache. No, I mean git-diff-cache. I find that this works pretty well, though. # git-update-cache `git-diff-cache | cut -f2` It looks like the same thing works for git-diff-files. # git-update-cache `git-diff-files | cut -f2` This seems to agree with the way you handle things. Similarly, there is the need to determine which files are new to the tree. This isn't much of a burden when creating files in the tree, but can be bothersome when using patch since git-apply is conservative about fuzz. - 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: Why is there no git-update-cache --modified (aka I give up)
Matthias Urlichs smurf at smurf.noris.de writes: Hi, Marc Singer wrote: # git-update-cache `git-diff-cache | cut -f2` g-d-c should have an option to print file names only. All that cutting and argument-backtick-ing gets pretty nasty when there are a lot of files, or if they contain special characters. I concur. I'll add --name-only flag to diff brothers soonish. Sorry I am at work and have turned the incoming connection to my home network before I left for work today -- this is the same [EMAIL PROTECTED] who is guilty for all your diff problems ;-). - 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: git-update-cache:
On Wed, Jul 06, 2005 at 12:42:20AM +0200, Sam Ravnborg wrote: I receive the following error: git-update-cache: symbol lookup error: git-update-cache: undefined symbol: deflateBound open(/usr/lib/libz.so.1, O_RDONLY)= 3 This is the reason. For a strange reason when git-update-chache was compiled is was linked dynamically towards an older libz.so version. Latest installed is libz.1.2.2 which includes deflateBound. libz.so.1 points at 1.1.4 which does not. The solution was to let libz.so.1 point to latest libz.so file. In my gentoo distribution there seems to be inconsistency if /lib or /usr/lib is used. That was the root cause. Back to do some useful stuff.. Sam - 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
