{"thread":{"id":"32959","subject":"\"git branch --contains x y\" creates a branch instead of checking containment","startedAt":"2013-02-21T13:00:27Z","lastAt":"2013-02-21T17:48:14Z","messageCount":4,"participants":["Per Cederqvist","Jeff King","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"209969","messageId":"51261A6B.5020909@opera.com","threadId":"32959","inReplyTo":null,"subject":"\"git branch --contains x y\" creates a branch instead of checking containment","fromName":"Per Cederqvist","fromEmail":"cederp@opera.com","sentAt":"2013-02-21T13:00:27Z","receivedAt":"2013-02-21T13:00:27Z","isPatch":false,"sender":{"key":"cederp@opera.com","avatar":"https://gravatar.com/avatar/008fe28caedea0ba34042cd5157705267934f4ba7a9b29fb248ae18ec5b3055e?d=mp&s=160"},"body":"The \"git branch --list --contains x y\" command lists\nall branches that contains commit x and matches the\npattern y. Reading the git-branch(1) manual page gives\nthe impression that \"--list\" is redundant, and that\nyou can instead write\n\n    git branch --contains x y\n\nThat command does something completely different,\nthough. The \"--contains x\" part is silently ignored,\nso it creates a branch named \"y\" pointing at HEAD.\n\nTested in git 1.8.1.1 and 1.8.1.4.\n\nIn my opinion, there are two ways to fix this:\n\n  - change the \"git branch\" implementation so\n    that --contains implies --list.\n\n  - change the manual page synopsis so that\n    it is clear that --contains can only be\n    used if --list is also used.  Also add an\n    error check to the \"git branch\" implementation\n    so that using --contains without specifying\n    --list produces a fatal error message.\n\nPersonally I would prefer the first solution.\n\nRepeat by running these commands:\n\n# Set up a repo with two commits.\n# Branch a points to the oldest one, and\n# b and master to the newest one.\nmkdir contains || exit 1\ncd contains\ngit init\ntouch a; git add a; git commit -m\"Added a\".\ngit branch a\ntouch b; git add b; git commit -m\"Added b\".\ngit branch b\n\ngit branch --list --contains a\n# Prints \"a\", \"b\" and \"master, as expected.\n\ngit branch --contains a\n# Prints \"a\", \"b\" and \"master, as expected.\n# In this case, the --list option can be removed.\n\ngit branch --list --contains a b\n# Prints \"b\", as expected.  \"b\" is a <pattern>.\n\ngit branch --list --contains a c\n# Prints nothing, as expected, as the \"c\" pattern doesn't match any of\n# the existing branches.\n\ngit for-each-ref\n# Prints three lines: refs/heads/a, refs/heads/b and\n# refs/heads/master, as expected.\n\ngit branch --contains a c\n# Prints nothing, as expected, but...\n\ngit for-each-ref\n# Prints four lines!  Apparently, the command above created\n# refs/heads/c.\n\n     /ceder\n\nP.S. What I really wanted to do was \"git merge-base\n--is-ancestor a b\", but I keep forgetting its name.\n"},{"id":"209978","messageId":"20130221155827.GA20640@sigill.intra.peff.net","threadId":"32959","inReplyTo":"51261A6B.5020909@opera.com","subject":"Re: \"git branch --contains x y\" creates a branch instead of checking containment","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-02-21T15:58:28Z","receivedAt":"2013-02-21T15:58:28Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Feb 21, 2013 at 02:00:27PM +0100, Per Cederqvist wrote:\n\n> That command does something completely different,\n> though. The \"--contains x\" part is silently ignored,\n> so it creates a branch named \"y\" pointing at HEAD.\n> \n> Tested in git 1.8.1.1 and 1.8.1.4.\n> \n> In my opinion, there are two ways to fix this:\n> \n>  - change the \"git branch\" implementation so\n>    that --contains implies --list.\n\nI think that is the best option, too. In fact, I even wrote a patch. :)\n\nIt's d040350 (branch: let branch filters imply --list, 2013-01-31), and\nit's already in v1.8.2-rc0.\n\n-Peff\n"},{"id":"209979","messageId":"512645D1.4040607@opera.com","threadId":"32959","inReplyTo":"20130221155827.GA20640@sigill.intra.peff.net","subject":"Re: \"git branch --contains x y\" creates a branch instead of checking containment","fromName":"Per Cederqvist","fromEmail":"cederp@opera.com","sentAt":"2013-02-21T16:05:37Z","receivedAt":"2013-02-21T16:05:37Z","isPatch":false,"sender":{"key":"cederp@opera.com","avatar":"https://gravatar.com/avatar/008fe28caedea0ba34042cd5157705267934f4ba7a9b29fb248ae18ec5b3055e?d=mp&s=160"},"body":"On 02/21/13 16:58, Jeff King wrote:\n> On Thu, Feb 21, 2013 at 02:00:27PM +0100, Per Cederqvist wrote:\n>\n>> That command does something completely different,\n>> though. The \"--contains x\" part is silently ignored,\n>> so it creates a branch named \"y\" pointing at HEAD.\n>>\n>> Tested in git 1.8.1.1 and 1.8.1.4.\n>>\n>> In my opinion, there are two ways to fix this:\n>>\n>>   - change the \"git branch\" implementation so\n>>     that --contains implies --list.\n>\n> I think that is the best option, too. In fact, I even wrote a patch. :)\n>\n> It's d040350 (branch: let branch filters imply --list, 2013-01-31), and\n> it's already in v1.8.2-rc0.\n>\n> -Peff\n\nGreat! Thanks for the quick fix of my bug report. Negative response\ntime... not bad. Not bad at all. :-)\n\n     /ceder\n"},{"id":"209982","messageId":"7vr4k9v9r5.fsf@alter.siamese.dyndns.org","threadId":"32959","inReplyTo":"512645D1.4040607@opera.com","subject":"Re: \"git branch --contains x y\" creates a branch instead of checking containment","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-02-21T17:48:14Z","receivedAt":"2013-02-21T17:48:14Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Per Cederqvist <cederp@opera.com> writes:\n\n> On 02/21/13 16:58, Jeff King wrote:\n>> On Thu, Feb 21, 2013 at 02:00:27PM +0100, Per Cederqvist wrote:\n>>\n>>> That command does something completely different,\n>>> though. The \"--contains x\" part is silently ignored,\n>>> so it creates a branch named \"y\" pointing at HEAD.\n>>>\n>>> Tested in git 1.8.1.1 and 1.8.1.4.\n>>>\n>>> In my opinion, there are two ways to fix this:\n>>>\n>>>   - change the \"git branch\" implementation so\n>>>     that --contains implies --list.\n>>\n>> I think that is the best option, too. In fact, I even wrote a patch. :)\n>>\n>> It's d040350 (branch: let branch filters imply --list, 2013-01-31), and\n>> it's already in v1.8.2-rc0.\n>>\n>> -Peff\n>\n> Great! Thanks for the quick fix of my bug report. Negative response\n> time... not bad. Not bad at all. :-)\n\nYeah, Jeff has a time machine ;-)\n"}]}