# What is "-u" supposed to mean in git-fetch? 3 messages from 2006-01-26 to 2006-01-27. Participants: Johannes Schindelin, Junio C Hamano. Thread: https://gitlist.dev/t/3156 ## Johannes Schindelin, 2006-01-26 10:57 Subject: What is "-u" supposed to mean in git-fetch? Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.63.0601261148510.32499%40wbgn013.biozentrum.uni-wuerzburg.de ``` 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, 2006-01-26 11:50 Subject: Re: What is "-u" supposed to mean in git-fetch? Message-ID: <7voe1zfbsm.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7voe1zfbsm.fsf%40assigned-by-dhcp.cox.net In-Reply-To: ``` Johannes Schindelin 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. ``` ## Junio C Hamano, 2006-01-27 03:37 Subject: Re: What is "-u" supposed to mean in git-fetch? Message-ID: <7v3bja733p.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7v3bja733p.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <7voe1zfbsm.fsf@assigned-by-dhcp.cox.net> ``` Junio C Hamano writes: > Johannes Schindelin 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 --- 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 ```