# [PATCH] fmt-patch: understand old notation 7 messages from 2006-05-06 to 2006-05-07. Participants: Johannes Schindelin, Junio C Hamano, Linus Torvalds, Olivier Galibert. Thread: https://gitlist.dev/t/4082 ## Johannes Schindelin, 2006-05-06 20:56 Subject: [PATCH] fmt-patch: understand old notation Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.63.0605062252530.4155%40wbgn013.biozentrum.uni-wuerzburg.de ``` When calling "git fmt-patch HEAD~5", you now get the same as if you would have said "git fmt-patch HEAD~5..". This makes it easier for my fingers which are so used to the old syntax. Signed-off-by: Johannes Schindelin --- I wonder: would it make sense to make add_pending_object() and get_reference() in revision.c non-static? builtin-diff.c | 2 +- builtin-log.c | 8 ++++++++ 2 files changed, 9 insertions(+), 1 deletions(-) diff --git a/builtin-diff.c b/builtin-diff.c index 636edbf..2087316 100644 --- a/builtin-diff.c +++ b/builtin-diff.c @@ -232,7 +232,7 @@ static int builtin_diff_combined(struct return 0; } -static void add_head(struct rev_info *revs) +void add_head(struct rev_info *revs) { unsigned char sha1[20]; struct object *obj; diff --git a/builtin-log.c b/builtin-log.c index 0027998..d5bbc1c 100644 --- a/builtin-log.c +++ b/builtin-log.c @@ -11,6 +11,9 @@ #include "revision.h" #include "log-tree.h" #include "builtin.h" +/* this is in builtin-diff.c */ +void add_head(struct rev_info *revs); + static int cmd_log_wc(int argc, const char **argv, char **envp, struct rev_info *rev) { @@ -185,6 +188,11 @@ int cmd_format_patch(int argc, const cha if (argc > 1) die ("unrecognized argument: %s", argv[1]); + if (rev.pending_objects && rev.pending_objects->next == NULL) { + rev.pending_objects->item->flags |= UNINTERESTING; + add_head(&rev); + } + if (!use_stdout) realstdout = fdopen(dup(1), "w"); -- 1.3.1.g9ba6-dirty ``` ## Junio C Hamano, 2006-05-06 21:41 Subject: Re: [PATCH] fmt-patch: understand old notation Message-ID: <7viroirfur.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7viroirfur.fsf%40assigned-by-dhcp.cox.net In-Reply-To: ``` Johannes Schindelin writes: > When calling "git fmt-patch HEAD~5", you now get the same as if you would > have said "git fmt-patch HEAD~5..". This makes it easier for my fingers > which are so used to the old syntax. While this would be easier on _my_ fingers as well, I have a suspicion that it might make more sense to make this "single ref" case to mean "HEAD~5^..HEAD~5" (if we _were_ designing a new command that is called format-patch today, that would be more natural). But probably it is too late to break it by now. > I wonder: would it make sense to make add_pending_object() and > get_reference() in revision.c non-static? I'd rather not expose such revision.c internals too much. An alternative approach would be to give instruction to revision.c (read: another flag like rev.no_walk) to tell it to do something special when the user has only one commit, but I think what you did in your patch is cleaner and sufficient. Also we probably would want to default the diff options to show the root commit diff (rev.show_root_diff). ``` ## Johannes Schindelin, 2006-05-06 22:01 Subject: Re: [PATCH] fmt-patch: understand old notation Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.63.0605062358280.6357%40wbgn013.biozentrum.uni-wuerzburg.de In-Reply-To: <7viroirfur.fsf@assigned-by-dhcp.cox.net> ``` Hi, On Sat, 6 May 2006, Junio C Hamano wrote: > Johannes Schindelin writes: > > > When calling "git fmt-patch HEAD~5", you now get the same as if you would > > have said "git fmt-patch HEAD~5..". This makes it easier for my fingers > > which are so used to the old syntax. > > While this would be easier on _my_ fingers as well, I have a > suspicion that it might make more sense to make this "single > ref" case to mean "HEAD~5^..HEAD~5" (if we _were_ designing a > new command that is called format-patch today, that would be > more natural). But probably it is too late to break it by now. No, it is not too late. I did this patch only to prevent cluttering my directory with millions of patches, only because I forgot _again_ to type the two dots. > > I wonder: would it make sense to make add_pending_object() and > > get_reference() in revision.c non-static? > > I'd rather not expose such revision.c internals too much. An > alternative approach would be to give instruction to revision.c > (read: another flag like rev.no_walk) to tell it to do something > special when the user has only one commit, but I think what you > did in your patch is cleaner and sufficient. I just stole the function add_head() from builtin-diff.c, but that feels wrong. I think adding a pending object should not be internal to revision.c. > Also we probably would want to default the diff options to show > the root commit diff (rev.show_root_diff). I gather this is needed for git-am/git-rebase to continue working? Ciao, Dscho ``` ## Linus Torvalds, 2006-05-06 22:30 Subject: Re: [PATCH] fmt-patch: understand old notation Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.64.0605061527030.16343%40g5.osdl.org In-Reply-To: <7viroirfur.fsf@assigned-by-dhcp.cox.net> ``` On Sat, 6 May 2006, Junio C Hamano wrote: > > While this would be easier on _my_ fingers as well, I have a > suspicion that it might make more sense to make this "single > ref" case to mean "HEAD~5^..HEAD~5" (if we _were_ designing a > new command that is called format-patch today, that would be > more natural). Careful, that "X^..X" thing does entirely the wrong thing for merges. Not what you want at all, I think. > But probably it is too late to break it by now. Maybe not. I've actually cursed the fact that I made "git diff X" mean "diff from X to current working tree", because it almost never makes any sense at all when X is anything but "HEAD". I probably _should_ have made "git diff X" mean basically "git show X", and not what it means now. Oh, well. Linus ``` ## Olivier Galibert, 2006-05-06 23:19 Subject: Re: [PATCH] fmt-patch: understand old notation Message-ID: <20060506231901.GB45996@dspnet.fr.eu.org> URL: https://gitlist.dev/e/20060506231901.GB45996%40dspnet.fr.eu.org In-Reply-To: ``` On Sat, May 06, 2006 at 03:30:38PM -0700, Linus Torvalds wrote: > Maybe not. I've actually cursed the fact that I made "git diff X" mean > "diff from X to current working tree", because it almost never makes any > sense at all when X is anything but "HEAD". > > I probably _should_ have made "git diff X" mean basically "git show X", > and not what it means now. Funny, when tracking other projects I use (sometimes path-filtered) "git diff origin" often, but I find "git show origin" utterly uninteresting. OG. ``` ## Junio C Hamano, 2006-05-07 01:28 Subject: Re: [PATCH] fmt-patch: understand old notation Message-ID: <7vd5eqr5bt.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vd5eqr5bt.fsf%40assigned-by-dhcp.cox.net In-Reply-To: ``` Johannes Schindelin writes: > No, it is not too late. I did this patch only to prevent cluttering my > directory with millions of patches, only because I forgot _again_ to type > the two dots. I did that as well, and the thing is, this is _so_ fast that when I noticed and typed ^C, it already has done 400 or so commits starting from the epoch (which was empty by the way). I am already working on adjusting in-tree format-patch users not to use syntax but to use .. syntax, so this should not be a problem either way. >> Also we probably would want to default the diff options to show >> the root commit diff (rev.show_root_diff). > I gather this is needed for git-am/git-rebase to continue working? No, but people want to export the whole history sometimes. ``` ## Junio C Hamano, 2006-05-07 01:31 Subject: Re: [PATCH] fmt-patch: understand old notation Message-ID: <7v8xper56t.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7v8xper56t.fsf%40assigned-by-dhcp.cox.net In-Reply-To: ``` Linus Torvalds writes: > Maybe not. I've actually cursed the fact that I made "git diff X" mean > "diff from X to current working tree", because it almost never makes any > sense at all when X is anything but "HEAD". Actually, I do "git diff next" all the time while on the tip of my topic branches, and also when merging a topic branch into "master". This "a different tree with the current working files" is probably the second most frequently used form for me (the first one is of course HEAD vs working files). ```