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

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

[Johannes Schindelin]

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

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

[Junio C Hamano]

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

> 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.

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

[Junio C Hamano]

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

> 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