# [PATCH] git-branch --with=commit 9 messages from 2007-11-07 to 2007-11-15. Participants: Junio C Hamano, Jakub Narebski, Johannes Schindelin, Johannes Sixt, Andreas Ericsson, Jan Hudec. Thread: https://gitlist.dev/t/10713 ## Junio C Hamano, 2007-11-07 23:15 Subject: [PATCH] git-branch --with=commit Message-ID: <7vpryl8x5t.fsf@gitster.siamese.dyndns.org> URL: https://gitlist.dev/e/7vpryl8x5t.fsf%40gitster.siamese.dyndns.org ``` This teaches git-branch to limit its listing to branches that are descendants to the named commit. When you are using many topic branches, you often would want to see which branch already includes a commit, so that you know which can and cannot be rewound without disrupting other people. One thing that sometimes happens to me is: * Somebody sends a patch that is a good maint material. I apply it to 'maint': $ git checkout maint $ git am -3 -s obvious-fix.patch * Then somebody else sends another patch that is possibly a good maint material, but I'd want to cook it in 'next' to be extra sure. I fork a topic from 'maint' and apply the patch: $ git checkout -b xx/maint-fix-foo $ git am -3 -s ,xx-maint-fix-foo.patch * A minor typo is found in the "obvious-fix.patch". The above happens without pushing the results out, so I can freely recover from it by amending 'maint', as long as I do not forget to rebase the topics that were forked previously. With this patch, I could do this to find out which topic branches already contain the faulty commit: $ git branch --with=maint^ | grep / xx/maint-fix-foo Signed-off-by: Junio C Hamano --- builtin-branch.c | 50 ++++++++++++++++++++++++++++++++++++++++++++++++-- 1 files changed, 48 insertions(+), 2 deletions(-) diff --git a/builtin-branch.c b/builtin-branch.c index 3bf40f1..d13e64f 100644 --- a/builtin-branch.c +++ b/builtin-branch.c @@ -184,9 +184,30 @@ struct ref_item { struct ref_list { int index, alloc, maxwidth; struct ref_item *list; + struct commit_list *with_commit; int kinds; }; +static int has_commit(const unsigned char *sha1, struct commit_list *with_commit) +{ + struct commit *commit; + + if (!with_commit) + return 1; + commit = lookup_commit_reference_gently(sha1, 1); + if (!commit) + return 0; + while (with_commit) { + struct commit *other; + + other = with_commit->item; + with_commit = with_commit->next; + if (in_merge_bases(other, &commit, 1)) + return 1; + } + return 0; +} + static int append_ref(const char *refname, const unsigned char *sha1, int flags, void *cb_data) { struct ref_list *ref_list = (struct ref_list*)(cb_data); @@ -206,6 +227,10 @@ static int append_ref(const char *refname, const unsigned char *sha1, int flags, refname += 10; } + /* Filter with with_commit if specified */ + if (!has_commit(sha1, ref_list->with_commit)) + return 0; + /* Don't add types the caller doesn't want */ if ((kind & ref_list->kinds) == 0) return 0; @@ -296,13 +321,14 @@ static void print_ref_item(struct ref_item *item, int maxwidth, int verbose, } } -static void print_ref_list(int kinds, int detached, int verbose, int abbrev) +static void print_ref_list(int kinds, int detached, int verbose, int abbrev, struct commit_list *with_commit) { int i; struct ref_list ref_list; memset(&ref_list, 0, sizeof(ref_list)); ref_list.kinds = kinds; + ref_list.with_commit = with_commit; for_each_ref(append_ref, &ref_list); qsort(ref_list.list, ref_list.index, sizeof(struct ref_item), ref_cmp); @@ -505,6 +531,22 @@ static void rename_branch(const char *oldname, const char *newname, int force) die("Branch is renamed, but update of config-file failed"); } +static int opt_parse_with_commit(const struct option *opt, const char *arg, int unset) +{ + unsigned char sha1[20]; + struct commit *commit; + + if (!arg) + return -1; + if (get_sha1(arg, sha1)) + die("malformed object name %s", arg); + commit = lookup_commit_reference(sha1); + if (!commit) + die("no such commit %s", arg); + commit_list_insert(commit, opt->value); + return 0; +} + int cmd_branch(int argc, const char **argv, const char *prefix) { int delete = 0, force_delete = 0, force_create = 0; @@ -512,6 +554,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix) int verbose = 0, abbrev = DEFAULT_ABBREV, detached = 0; int reflog = 0, track; int kinds = REF_LOCAL_BRANCH, kind_remote = 0, kind_any = 0; + struct commit_list *with_commit = NULL; struct option options[] = { OPT_GROUP("Generic options"), @@ -519,6 +562,9 @@ int cmd_branch(int argc, const char **argv, const char *prefix) OPT_BOOLEAN( 0 , "track", &track, "set up tracking mode (see git-pull(1))"), OPT_BOOLEAN( 0 , "color", &branch_use_color, "use colored output"), OPT_BOOLEAN('r', NULL, &kind_remote, "act on remote-tracking branches"), + OPT_CALLBACK(0, "with", &with_commit, "commit", + "print only branches that contain the commit", + opt_parse_with_commit), OPT__ABBREV(&abbrev), OPT_GROUP("Specific git-branch actions:"), @@ -566,7 +612,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix) if (delete) return delete_branches(argc, argv, force_delete, kinds); else if (argc == 0) - print_ref_list(kinds, detached, verbose, abbrev); + print_ref_list(kinds, detached, verbose, abbrev, with_commit); else if (rename && (argc == 1)) rename_branch(head, argv[0], force_rename); else if (rename && (argc == 2)) -- 1.5.3.5.1593.g5baf ``` ## Jakub Narebski, 2007-11-07 23:33 Subject: Re: [PATCH] git-branch --with=commit Message-ID: URL: https://gitlist.dev/e/fgthvm%24m79%241%40ger.gmane.org In-Reply-To: <7vpryl8x5t.fsf@gitster.siamese.dyndns.org> ``` Junio C Hamano wrote: > --- >  builtin-branch.c |   50 ++++++++++++++++++++++++++++++++++++++++++++++++-- >  1 files changed, 48 insertions(+), 2 deletions(-) Documentation/git-branch.txt, please? -- Jakub Narebski Warsaw, Poland ShadeHawk on #git ``` ## Johannes Schindelin, 2007-11-08 00:09 Subject: Re: [PATCH] git-branch --with=commit Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.64.0711080008050.4362%40racer.site In-Reply-To: <7vpryl8x5t.fsf@gitster.siamese.dyndns.org> ``` Hi, would it not be better to call it --containing=commit? Besides, I think that the opt_parse_with_commit() function would be better named opt_parse_commit() and be put into parse-options.[ch]. Ciao, Dscho ``` ## Junio C Hamano, 2007-11-08 02:05 Subject: Re: [PATCH] git-branch --with=commit Message-ID: <7vk5ot7aqz.fsf@gitster.siamese.dyndns.org> URL: https://gitlist.dev/e/7vk5ot7aqz.fsf%40gitster.siamese.dyndns.org In-Reply-To: ``` Johannes Schindelin writes: > would it not be better to call it --containing=commit? Besides, I think > that the opt_parse_with_commit() function would be better named > opt_parse_commit() and be put into parse-options.[ch]. git-describe has "--contains" so that may be a better match. I do not know the particular function is generic enough to be in parse-options. ``` ## Johannes Schindelin, 2007-11-08 03:02 Subject: Re: [PATCH] git-branch --with=commit Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.64.0711080300100.4362%40racer.site In-Reply-To: <7vk5ot7aqz.fsf@gitster.siamese.dyndns.org> ``` Hi, On Wed, 7 Nov 2007, Junio C Hamano wrote: > Johannes Schindelin writes: > > > would it not be better to call it --containing=commit? Besides, I > > think that the opt_parse_with_commit() function would be better named > > opt_parse_commit() and be put into parse-options.[ch]. > > git-describe has "--contains" so that may be a better match. I just thought what I would understand when reading "git branch --with=master". I would have expected that it branches off of master. > I do not know the particular function is generic enough to be in > parse-options. Maybe not, you're right. And we can always come back later, and expose the function if need be. Ciao, Dscho ``` ## Johannes Sixt, 2007-11-08 07:36 Subject: Re: [PATCH] git-branch --with=commit Message-ID: <4732BC6F.7070005@viscovery.net> URL: https://gitlist.dev/e/4732BC6F.7070005%40viscovery.net In-Reply-To: <7vpryl8x5t.fsf@gitster.siamese.dyndns.org> ``` Junio C Hamano schrieb: > $ git checkout -b xx/maint-fix-foo > $ git am -3 -s ,xx-maint-fix-foo.patch Is this comma a hidden feature? > With this patch, I could do this to find out which topic > branches already contain the faulty commit: > > $ git branch --with=maint^ | grep / > xx/maint-fix-foo It'd be helpful if you could construct the example in this commit message such that you don't need the "grep /" here; otherwise, the reader doesn't know which part of the effect is hidden by the grep. -- Hannes ``` ## Junio C Hamano, 2007-11-08 08:13 Subject: Re: [PATCH] git-branch --with=commit Message-ID: <7vejf140jd.fsf@gitster.siamese.dyndns.org> URL: https://gitlist.dev/e/7vejf140jd.fsf%40gitster.siamese.dyndns.org In-Reply-To: <4732BC6F.7070005@viscovery.net> ``` Johannes Sixt writes: > Junio C Hamano schrieb: >> $ git checkout -b xx/maint-fix-foo >> $ git am -3 -s ,xx-maint-fix-foo.patch > > Is this comma a hidden feature? No, just my personal convention to queue e-mails from my mailbox. >> With this patch, I could do this to find out which topic >> branches already contain the faulty commit: >> >> $ git branch --with=maint^ | grep / >> xx/maint-fix-foo > > It'd be helpful if you could construct the example in this commit > message such that you don't need the "grep /" here; otherwise, the > reader doesn't know which part of the effect is hidden by the grep. Yeah, in the example sequence, I think only maint itself and xx/maint-fix-foo are shown, so there is no need for grep. ``` ## Andreas Ericsson, 2007-11-08 09:17 Subject: Re: [PATCH] git-branch --with=commit Message-ID: <4732D440.2020504@op5.se> URL: https://gitlist.dev/e/4732D440.2020504%40op5.se In-Reply-To: <7vejf140jd.fsf@gitster.siamese.dyndns.org> ``` Junio C Hamano wrote: > Johannes Sixt writes: > >> Junio C Hamano schrieb: > >>> With this patch, I could do this to find out which topic >>> branches already contain the faulty commit: >>> >>> $ git branch --with=maint^ | grep / >>> xx/maint-fix-foo >> It'd be helpful if you could construct the example in this commit >> message such that you don't need the "grep /" here; otherwise, the >> reader doesn't know which part of the effect is hidden by the grep. > > Yeah, in the example sequence, I think only maint itself and > xx/maint-fix-foo are shown, so there is no need for grep. And "maint" could certainly be stripped by the code itself, since the user can reasonably be expected to know that plain maint will have everything maint^ has. -- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 ``` ## Jan Hudec, 2007-11-15 17:27 Subject: Re: [PATCH] git-branch --with=commit Message-ID: <20071115172726.GA4525@efreet.light.src> URL: https://gitlist.dev/e/20071115172726.GA4525%40efreet.light.src In-Reply-To: <4732D440.2020504@op5.se> ``` On Thu, Nov 08, 2007 at 10:17:52 +0100, Andreas Ericsson wrote: > Junio C Hamano wrote: >> Johannes Sixt writes: >> >>> Junio C Hamano schrieb: >> >>>> With this patch, I could do this to find out which topic >>>> branches already contain the faulty commit: >>>> >>>> $ git branch --with=maint^ | grep / >>>> xx/maint-fix-foo >>> It'd be helpful if you could construct the example in this commit >>> message such that you don't need the "grep /" here; otherwise, the >>> reader doesn't know which part of the effect is hidden by the grep. >> >> Yeah, in the example sequence, I think only maint itself and >> xx/maint-fix-foo are shown, so there is no need for grep. > > And "maint" could certainly be stripped by the code itself, since the > user can reasonably be expected to know that plain maint will have > everything maint^ has. DWIDNS (Do what I did not say). Normally one would expect 'git branch --with=maint^' and 'git branch --with=$(git ref-parse maint^)' to be exactly the same. Alas, with your suggestion, they would not. -- Jan 'Bulb' Hudec ```