Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> --- git.c | 9 ++++++++- 1 files changed, 8 insertions(+), 1 deletions(-) diff --git a/git.c b/git.c index 82a8357..c43d4ff 100644 --- a/git.c +++ b/git.c @@ -387,8 +387,15 @@ int main(int argc, const char **argv, char **envp) done_alias = 1; } - if (errno == ENOENT) + if (errno == ENOENT) { + if (done_alias) { + fprintf(stderr, "Expansion of alias '%s' failed; " + "'%s' is not a git-command\n", + cmd, ...

If the alias expansion is prefixed with an exclamation point, treat it as a shell command which is run using system(3). Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> --- Documentation/config.txt | 6 ++++++ git.c | 10 ++++++++++ 2 files changed, 16 insertions(+), 0 deletions(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index 4e650af..e6e9409 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -222,6 +222,12 @@ ...

If an SVN revision has a property, "svm:headrev", it is likely that the revision was created by SVN::Mirror (a part of SVK). The property contains a repository UUID and a revision. We want to make it look like we are mirroring the original URL, so introduce a helper function that returns the original identity URL and UUID, and use it when generating commit messages. --- git-svn.perl | 39 +++++++++++++++++++++++++++++++++------ 1 files changed, 33 insertions(+), 6 deletions(-) diff --git ...

One of the solutions, used in git.git repository, is to put public key as a out-of-tree blob using git-hash-object, then tag it using singed tag with instruction about how to extract key in the tag message (tag comment). $ git cat-file -p junio-gpg-pub object 0246401b5d117e01717149c413aa2f8702a83d4f type blob tag junio-gpg-pub tagger Junio C Hamano <junkio@cox.net> Tue Dec 13 16:33:29 2005 -0800 GPG key to sign git.git archive. This blob object contains the GPG public key I use ...

--- Documentation/git-repack.txt | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/git-repack.txt b/Documentation/git-repack.txt index 4a57ce8..d39abc1 100644 --- a/Documentation/git-repack.txt +++ b/Documentation/git-repack.txt @@ -30,9 +30,9 @@ OPTIONS Instead of incrementally packing the unpacked objects, pack everything available into a single pack. Especially useful when packing a repository that is used - for a private development and ...

And don't get me wrong. I think that for 1.5.0 you should really do (0). Nicolas -

If you end up doing (2), may I suggest making the functionality of "git-status" today available as "git-commit -n"? It is something useful, so we shouldn't lose it, and -n meaning --no-action is a well accepted convention for Unix commands. - Ted -

I'm using git v1.4.4.4, and trying to use directly git-send-email on plain files. bug #1 (default values when prompting do not work) According to git-send-email documentation, it should suggest default values when prompting the user. However it does not, since ->readline does not accept a default value. I've verified this in man Term\:\:ReadLine and by looking at /usr/share/perl/5.8.7/Term/ReadLine.pm, and with the perl debugger - the default is correctly calculated but not printed. ...

It really depends on what Marco means by "if cwd is clean". If by "clean" Marco means "no differences after discarding cache cleanliness information", "git-diff" is not quite it, as it shows the differences including the cleanliness of the cache entry. "git-status", as Marco found out in the message that started this thread, loses the cache cleanliness information when it runs [*1*]. If he cares about cache cleanliness information, "git-diff" is the right thing to use, and using "git ...

Hi, Probably. AFAIR Windows lacks some important information, which is filled with zeroes by Cygwin. Note that this problem already arises between Cygwin and MinGW, and it cannot be fixed: Cygwin _has_ symlinks, while MinGW has _not_. Ciao, Dscho -

Quote both file names separately when printing a rename, yielding something like "foo" => "bar" instead of the current "foo => bar" Signed-off-by: Alexandre Julliard <julliard@winehq.org> --- diff.c | 34 +++++++++++++++++++++++++++------- 1 files changed, 27 insertions(+), 7 deletions(-) diff --git a/diff.c b/diff.c index e036aae..c6a9692 100644 --- a/diff.c +++ b/diff.c @@ -545,6 +545,24 @@ static char *pprint_rename(const char *a, const char *b) int pfx_length, ...

This avoids some code duplication, and yields more readable results for directory renames. Signed-off-by: Alexandre Julliard <julliard@winehq.org> --- diff.c | 31 ++++--------------------------- 1 files changed, 4 insertions(+), 27 deletions(-) diff --git a/diff.c b/diff.c index ad476f7..4c642d7 100644 --- a/diff.c +++ b/diff.c @@ -2430,34 +2430,11 @@ static void show_mode_change(struct diff_filepair *p, int show_name) static void show_rename_copy(const char *renamecopy, struct ...

I suspect that you are dual booting and browsing a git repository that is on a read-only mounted NTFS filesystem from the Linux side, and the index was created on Cygwin git? I (perhaps luckily) am fairly ignorant on the way things done in Windows environment. For one thing, I do not know if NTFS has notion of i-number, file owner uid, and other information that are used in the index (not that I want to know). If NTFS does not support the information returned by lstat(2) fully on disk, I ...

The thing is, it touches central part of the system by changing the calling convention of two rather important functions. You might have already fully tested that there is no regression for git-runstatus, but it affects other callers as well. I tried to be careful when I did the conversion but I am not 100% sure there is no "unintended side effects". -

So in this case your patch that introduce '--refresh' option in 'git runstatus' is not just a shortcut for 'git update-index' + 'git runstatus' but adds some real value. One more reason for asking you to add it before 1.5 release ;-) -

This is the complete log under Windows (git with Cygwin distribution, but run _outside_ cygwin shell, directly in Windows cmd.exe shell). And _after_ under Linus, current git tree _without_ your last patches applied. *************** UNDER WINDOWS *********************** C:\varie\c\qgit4>git status # Untracked files: # (use "git add" to add to commit) # # AAA_convert.xls.lnk # Cygwin.lnk # Qt 4.2.2 Command ...

Well, if you never pushed anything out, just re-tag it. Use "-f" to replace the old one. And you're done. But if you have pushed things out (or others could just read your repository directly), then others will have already seen the old tag. In that case you can do one of two things: - The sane thing. Just admit you screwed up, and use a different name. Others have already seen one tag-name, and if you keep the same name, you may be in the situation that two people ...

Actually, I think you can do it already. I think the "update" hook runs whenever we're pulling a ref, once for each ref. It might happen just for pushing to a remote, though. Anyway, with a hook, it's easy enough to just add exactly the kind of thing you are outlining, and yes, it would be repository-local. Linus -

Hi, Not really. The thing is, git-status does a lot more than what you need. And what you need is _only_ what "git diff --name-only HEAD" does already! It _also_ checks the index, it _also_ only checks the files with different stat information, but it does _not_ try to update the index and prepare a message to be displayed when committing. So, what is the big problem about accepting that patching git-status for one obscure use is wrong, wrong, wrong, when git-diff already does what is ...

I could opt for shipping qgit 1.5.5 _without_ using '--refresh' and then ship, as example in a month, qgit 1.5.6 that uses the feaure. But I can do this _only_ if git 1.5 has it. -

Probably I'm doing something wrong, but that's how working dir detection is currently implemented in qgit: void Git::getDiffIndex() { QString status; if (!run("git status", &status)) // git status refreshes the index, run as first return; if (!run("git diff-index HEAD", &_wd.diffIndex)) return; // check for files already updated in cache, we will // save this information in status third field if (!run("git diff-index --cached HEAD", &_wd.diffIndexCached)) return; ...

It is. It's the technical issue that makes it not so. But when a user asks for a status, he's clearly not expecting to _write_ anything, even less for the command to fail if the file system is read-only. This is like if a file system driver refused to open a file when the file system is mounted read-only just because it cannot update the file's atime on disk. Just like the atime example, we may refresh the index while at it when preparing the status results. This is a valid ...

I do not think so. It is a workflow issue that user indicates the cache cleanliness information does not matter anymore. Is it wrong for "git-status" to be losing the cache cleanliness information? The intended audience of that program is those who are about to make a commit in the repository, as they are asking "what would I be committing?" Up to that point, they may have cared about the reminder they get from "git diff" that they edited a file and then ended up reverting the whole edit ...

Well, I tested the patch and indeed it helps a lot ;-) It's correct that checking Linux lstat against cygwin one (stored in index) gives different results, but it's now where the patch makes the difference rechecking all the files (in memory) to see if are really That's a true point. Altough if git 1.5 ships _without_ '--refresh' option in 'git runstatus' for a porcelain tool point of view it means *do forget* that option until next major release. There's no point in adding the feature one ...

Hi, Which issues? That the lstat data are not equal on Cygwin and Linux? The patch does not help here. Maybe a patch to Linux' ntfs driver would, but I fail to see how Git could possibly help here. If git-diff is trying to write files, _that_ would be a bug. As for your use of git-status: I think it is wrong. You said you want to check if the working directory is clean. Then just do that, and do not try You need a new version of _Git_ if you use that option. And if you can do ...

Sure, something like this: $ export IMAGE=$HOME/etoys.image $ cd etoys $ git init-db $ echo 1 > image-version $ git add image-version $ mkdir upgrade $ cd upgrade $ ls patch1 patch2 # These patches are the "update stream" from the previous commit to the # current commit. $ cat patch1 touch $IMAGE $ cat patch2 echo abc >> $IMAGE $ cd .. $ git add patch1 patch2 $ git commit -a # After every commit, you can remove the previous update stream. $ git rm upgrade/* # Here is ...

Hi, There are basically three ways I can think of: - rewrite the commit objects on the fly. You might want to avoid the use of the pack protocol here (i.e. use HTTP or FTP transport). - try to teach git a way to ignore certain missing objects and directories. This might be involved, but you could extend upload-pack easily with a new extension for that. (my favourite:) - use git-split to create a new branch, which only contains doc/. Do work only on that branch, and merge into ...

Here are some patches to fix the horrible error message and to allow aliases to expand to external shell commands. - Ted -

That's not how I code but it does seem to be the prevailing git coding Yes, that makes the error message look a bit nicer. I'll respin the ... and git-shell only allows git-receive-pack and git-upload-pack to be called, with a single argument, and aliases aren't allowed to override commands. So we're safe here, I think. - Ted -

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> --- git.c | 9 ++++++++- 1 files changed, 8 insertions(+), 1 deletions(-) diff --git a/git.c b/git.c index 82a8357..c43d4ff 100644 --- a/git.c +++ b/git.c @@ -387,8 +387,15 @@ int main(int argc, const char **argv, char **envp) done_alias = 1; } - if (errno == ENOENT) + if (errno == ENOENT) { + if (done_alias) { + fprintf(stderr, "Expansion of alias '%s' failed; " + "'%s' is not a git-command\n", + cmd, ...

If the alias expansion is prefixed with an exclamation point, treat it as a shell command which is run using system(3). Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> --- Documentation/config.txt | 6 ++++++ git.c | 10 ++++++++++ 2 files changed, 16 insertions(+), 0 deletions(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index 4e650af..de185d8 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -222,6 +222,12 @@ ...

I think the new semantics for -z ("inter-record termination is NUL") makes a lot more sense for "-p -z" format that shows commit log message and the patch text. It makes filtering the output with "grep -z" feel much more natural. The new semantics is however quite inconsistent with the other formats: --raw, --name-only and --name-status. These already use NUL for separating pathnames and fields when -z is given, in order to allow scripts sensibly deal with pathname that contain funny ...

... well, it just occured to me that it might make sense not to let this new "use NUL as inter-commit separator for grep -z" semantics hijack existing -z option, but introduce another option, say, -Z. Then you could even do something like: git log -Z -r --numstat | grep -z -e '^[1-9][0-9][0-9][0-9]* ' to find commits that has more than 100 lines of additions to a file. (or use --stat and grep for '| *[1-9][0-9][0-9][0-9]* ' to look for sum of addition+deletion ...