[PATCH] git-branch --with=commit

[PATCH] git-branch --with=commit

[Junio C Hamano]

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 <gitster@pobox.com>
---
 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

Re: [PATCH] git-branch --with=commit

[Jakub Narebski]

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

Re: [PATCH] git-branch --with=commit

[Johannes Schindelin]

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

Re: [PATCH] git-branch --with=commit

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> 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.

Re: [PATCH] git-branch --with=commit

[Johannes Schindelin]

Hi,

On Wed, 7 Nov 2007, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> 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

Re: [PATCH] git-branch --with=commit

[Johannes Sixt]

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

Re: [PATCH] git-branch --with=commit

[Junio C Hamano]

Johannes Sixt <j.sixt@viscovery.net> 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.

Re: [PATCH] git-branch --with=commit

[Andreas Ericsson]

Junio C Hamano wrote:
> Johannes Sixt <j.sixt@viscovery.net> 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

Re: [PATCH] git-branch --with=commit

[Jan Hudec]

[-- Attachment #1: Type: text/plain, Size: 1144 bytes --]

On Thu, Nov 08, 2007 at 10:17:52 +0100, Andreas Ericsson wrote:
> Junio C Hamano wrote:
>> Johannes Sixt <j.sixt@viscovery.net> 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 <bulb@ucw.cz>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]