What is "-u" supposed to mean in git-fetch?

Johannes Schindelin· Jan 26, 2006, 10:57 UTC · lore

Hi,

96b086d6 introduced "-u" to mean "--upload-pack" taking one argument. But long ago, b10ac50f1 from Aug 10 already introduced "-u" to mean "--update-head-ok" (without argument). This broke my scripts badly.

So, what is it?

Also, in the course of researching this, I tried

	git-whatchanged git-fetch-script

because git-whatchanged does not follow renames. But that did not work, because there is no current file of that name! When I created a dummy file of that name, git-whatchanged worked real fine! I consider that behaviour a bug.

Ciao, Dscho

Junio C Hamano· Jan 26, 2006, 11:50 UTC · re: Johannes Schindelin · lore

Re: What is "-u" supposed to mean in git-fetch?

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 5 quoted lines

> 96b086d6 introduced "-u" to mean "--upload-pack" taking one argument. But 
> long ago, b10ac50f1 from Aug 10 already introduced "-u" to mean 
> "--update-head-ok" (without argument). This broke my scripts badly.
>
> So, what is it?

Ah, I was not careful enough when reviewing.

You are right. The newcomer --upload-pack should drop its abbreviation shorter than "--upl".

> Also, in the course of researching this, I tried
>
> 	git-whatchanged git-fetch-script

As in Linus' message, "git whatchanged -- git-fetch-script" is supposed to be the kosher way now, but it does *not* work.

I started to suspect that flag/option parsing with rev-parse has outlived its usefulness, at least in whatchanged.

It is getting late, so won't have updates from me tonight. Sorry.

Junio C Hamano· Jan 27, 2006, 03:37 UTC · re: Junio C Hamano · lore

Re: What is "-u" supposed to mean in git-fetch?

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

Show 8 quoted lines

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>...
>> Also, in the course of researching this, I tried
>>
>> 	git-whatchanged git-fetch-script
>
> As in Linus' message, "git whatchanged -- git-fetch-script" is
> supposed to be the kosher way now, but it does *not* work.

Here is an attempt to fix it.

It is not perfect. As I said in a different message, the option parsing by rev-parse in whatchanged might have outlived its usefulness, especially after rev-list acquired path limit arguments. If you see what 'sh -x git-whatchanged' does, you will notice that the path limiter is not given to rev-list, but is given to diff-tree.

-- >8 -- [PATCH] rev-parse: make "whatchanged -- git-fetch-script" work again.

The latest update to avoid misspelled revs interfered when we were not interested in parsing non flags or arguments not meant for rev-list. This makes these two forms work again:

	git whatchanged -- git-fetch-script

We could enable "!def" in the part this change touches to make the above work without '--', but then it would cause misspelled v2.6.14..v2.6.16 to be given to diff-tree and defeats the whole point of the previous fix.

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

---

 rev-parse.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

f63fb6067037890d4928e35f7839f2a133a08d80

diff --git a/rev-parse.c b/rev-parse.c
index 7abad35..9567b0f 100644
--- a/rev-parse.c
+++ b/rev-parse.c
@@ -294,7 +294,9 @@ int main(int argc, char **argv)
 		}
 		if (verify)
 			die("Needed a single revision");
-		if (lstat(arg, &st) < 0)
+		if ((filter & DO_REVS) &&
+		    (filter & DO_NONFLAGS) && /* !def && */
+		    lstat(arg, &st) < 0)
 			die("'%s': %s", arg, strerror(errno));
 		as_is = 1;
 		show_file(arg);

-- 
1.1.4.g2cff