{"thread":{"id":"24992","subject":"Determining commit reachability","startedAt":"2010-09-05T20:34:11Z","lastAt":"2010-09-09T22:45:13Z","messageCount":13,"participants":["Artur Skawina","Jeff King","Junio C Hamano","Sverre Rabbelier","Ævar Arnfjörð Bjarmason","Jonathan Nieder","Nguyen Thai Ngoc Duy"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"149998","messageId":"4C83FEC3.3040101@gmail.com","threadId":"24992","inReplyTo":null,"subject":"Determining commit reachability","fromName":"Artur Skawina","fromEmail":"art.08.09@gmail.com","sentAt":"2010-09-05T20:34:11Z","receivedAt":"2010-09-05T20:34:11Z","isPatch":false,"sender":{"key":"art.08.09@gmail.com","avatar":null},"body":"Given commit C, refs (branches) R, S and T what would be the best way\nto test whether 'C' is reachable from any of the heads?\n\nChecking if `git rev-list -n1 O ^R ^S ^T` produces any output is what\ni came up with; is there a better (ie faster) solution?\n\nartur\n"},{"id":"150030","messageId":"20100906031700.GA25012@sigill.intra.peff.net","threadId":"24992","inReplyTo":"4C83FEC3.3040101@gmail.com","subject":"Re: Determining commit reachability","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-09-06T03:17:01Z","receivedAt":"2010-09-06T03:17:01Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Sep 05, 2010 at 10:34:11PM +0200, Artur Skawina wrote:\n\n> Given commit C, refs (branches) R, S and T what would be the best way\n> to test whether 'C' is reachable from any of the heads?\n> \n> Checking if `git rev-list -n1 O ^R ^S ^T` produces any output is what\n> i came up with; is there a better (ie faster) solution?\n\nI think that is about as fast as you will get. You could try something\nwith git-merge-base, but it should be about the same speed.\n\nNote that neither will tell you _which_ head the target was reachable\nfrom. For that, given the current interface you have to test each head\nindividually. If you write some C code, you can do it all in a single\ntraversal. See this thread for some discussion of how \"git tag\n--contains\" can be sped up:\n\n http://article.gmane.org/gmane.comp.version-control.git/150039\n\n-Peff\n"},{"id":"150039","messageId":"4C847661.3020800@gmail.com","threadId":"24992","inReplyTo":"20100906031700.GA25012@sigill.intra.peff.net","subject":"Re: Determining commit reachability","fromName":"Artur Skawina","fromEmail":"art.08.09@gmail.com","sentAt":"2010-09-06T05:04:33Z","receivedAt":"2010-09-06T05:04:33Z","isPatch":false,"sender":{"key":"art.08.09@gmail.com","avatar":null},"body":"On 09/06/10 05:17, Jeff King wrote:\n> On Sun, Sep 05, 2010 at 10:34:11PM +0200, Artur Skawina wrote:\n> \n>> Given commit C, refs (branches) R, S and T what would be the best way\n>> to test whether 'C' is reachable from any of the heads?\n>>\n>> Checking if `git rev-list -n1 O ^R ^S ^T` produces any output is what\n>> i came up with; is there a better (ie faster) solution?\n> \n> I think that is about as fast as you will get. You could try something\n> with git-merge-base, but it should be about the same speed.\n> \n> Note that neither will tell you _which_ head the target was reachable\n> from. For that, given the current interface you have to test each head\n\nAs i think i'll only need this to prevent leaking (private) commits that\nwouldn't be reachable from the (public) heads, just catching the\nunreachable ones should be enough.\n\n$ time git rev-list -n1 v2.6.12 ^v33 ^v35\n0m2.333s user 0m0.040s system 0m2.379s elapsed 99.77% CPU\n$ time git rev-list -n1 v2.6.36-rc2 ^v33 ^v35\n76be97c1fc945db08aae1f1b746012662d643e97\n0m0.500s user 0m0.010s system 0m0.514s elapsed 99.13% CPU\n\nA bit expensive, but I guess should it become a problem I could cache\nthe result and/or blacklist the client.\n\nThanks,\n\nartur\n"},{"id":"150050","messageId":"7viq2jv05c.fsf@alter.siamese.dyndns.org","threadId":"24992","inReplyTo":"4C83FEC3.3040101@gmail.com","subject":"Re: Determining commit reachability","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-09-06T06:47:27Z","receivedAt":"2010-09-06T06:47:27Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Artur Skawina writes:\n\n> Given commit C, refs (branches) R, S and T what would be the best way\n> to test whether 'C' is reachable from any of the heads?\n\nDepends on the definition of \"best\", but I often find myself typing\n\n git branch --with C\n\nwhere C often is somewhere between 'master' and 'ko/master' (the 'master'\nbranch everybody else has already seen on k.org). When I have second\nthoughts sometime after applying a patch directly on top of 'master', I\nneed to see if I have built a new topic branch forking from the faulty\ncommit before rewinding it, as such a topic branch also needs to be\nrewound.\n"},{"id":"150125","messageId":"AANLkTinDfCkkY_D6F7VepvuNAN1g1hC9UgnqRUjZn88y@mail.gmail.com","threadId":"24992","inReplyTo":"7viq2jv05c.fsf@alter.siamese.dyndns.org","subject":"Re: Determining commit reachability","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2010-09-06T20:45:55Z","receivedAt":"2010-09-06T20:45:55Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Mon, Sep 6, 2010 at 01:47, Junio C Hamano wrote:\n> Depends on the definition of \"best\", but I often find myself typing\n>\n>    git branch --with C\n\nIn case anyone else is wondering, '--with' is a hidden alias for '--contains'.\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"150132","messageId":"AANLkTim4kxpQj_UFOBcwCaVmBFCHun4T9t3O9Zvq3w49@mail.gmail.com","threadId":"24992","inReplyTo":"AANLkTinDfCkkY_D6F7VepvuNAN1g1hC9UgnqRUjZn88y@mail.gmail.com","subject":"Re: Determining commit reachability","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-09-06T20:53:46Z","receivedAt":"2010-09-06T20:53:46Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Mon, Sep 6, 2010 at 20:45, Sverre Rabbelier wrote:\n> Heya,\n>\n> On Mon, Sep 6, 2010 at 01:47, Junio C Hamano wrote:\n>> Depends on the definition of \"best\", but I often find myself typing\n>>\n>>    git branch --with C\n>\n> In case anyone else is wondering, '--with' is a hidden alias for '--contains'.\n\nMaybe it should be documented?\n"},{"id":"150133","messageId":"AANLkTinPDUeL2jaY3P17TiA959WH8eOQZ4=CeaHOYuq2@mail.gmail.com","threadId":"24992","inReplyTo":"AANLkTim4kxpQj_UFOBcwCaVmBFCHun4T9t3O9Zvq3w49@mail.gmail.com","subject":"Re: Determining commit reachability","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2010-09-06T21:05:59Z","receivedAt":"2010-09-06T21:05:59Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Mon, Sep 6, 2010 at 15:53, Ævar Arnfjörð Bjarmason wrote:\n> On Mon, Sep 6, 2010 at 20:45, Sverre Rabbelier wrote:\n>> In case anyone else is wondering, '--with' is a hidden alias for '--contains'.\n>\n> Maybe it should be documented?\n\nJunio added it that way back in \"git-branch --contains=commit\"\nv1.5.3.6-879-g694a577 (Nov 7 2007) when the feature was added. Junio,\ndo you remember why you added \"--with\" as a hidden alias?\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"150152","messageId":"7v39tmtpci.fsf@alter.siamese.dyndns.org","threadId":"24992","inReplyTo":"AANLkTinPDUeL2jaY3P17TiA959WH8eOQZ4=CeaHOYuq2@mail.gmail.com","subject":"Re: Determining commit reachability","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-09-06T23:38:21Z","receivedAt":"2010-09-06T23:38:21Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sverre Rabbelier writes:\n\n> On Mon, Sep 6, 2010 at 15:53, Ævar Arnfjörð Bjarmason wrote:\n>> On Mon, Sep 6, 2010 at 20:45, Sverre Rabbelier wrote:\n>>> In case anyone else is wondering, '--with' is a hidden alias for '--contains'.\n>>\n>> Maybe it should be documented?\n>\n> Junio added it that way back in \"git-branch --contains=commit\"\n> v1.5.3.6-879-g694a577 (Nov 7 2007) when the feature was added. Junio,\n> do you remember why you added \"--with\" as a hidden alias?\n\nIt was originally called --with. I wrote it to help me in the exact use\ncase in this thread, and the option was naturally named --with, as the\nrequest I wanted to make was \"Give me branches _with_ this commit, so that\nI know which ones I need to rewind before reintegrating and publishing\".\n\nSomehow people wanted to see an option with a longer name, but by that\ntime my fingers were well trained, so I kept \"--with\" but didn't bother\nadvertising duplicated options.\n"},{"id":"150190","messageId":"20100907055209.GT1182@burratino","threadId":"24992","inReplyTo":"7v39tmtpci.fsf@alter.siamese.dyndns.org","subject":"[PATCH] Documentation: explain \"git branch --with\"","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-09-07T05:52:09Z","receivedAt":"2010-09-07T05:52:09Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Junio C Hamano wrote:\n\n> It was originally called --with. I wrote it to help me in the exact use\n> case in this thread, and the option was naturally named --with, as the\n> request I wanted to make was \"Give me branches _with_ this commit, so that\n> I know which ones I need to rewind before reintegrating and publishing\".\n> \n> Somehow people wanted to see an option with a longer name, but by that\n> time my fingers were well trained, so I kept \"--with\" but didn't bother\n> advertising duplicated options.\n\nMore precisely, it is advertised by \"git branch --help-all\" but not\nthe manual or \"git branch -h\".\n\nHow about adding it to the man page so people can look up this option\nafter encountering it in the wild?\n\nSigned-off-by: Jonathan Nieder \n---\n Documentation/git-branch.txt | 1 +\n 1 files changed, 1 insertions(+), 0 deletions(-)\n\ndiff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt\nindex 1940256..f479e2f 100644\n--- a/Documentation/git-branch.txt\n+++ b/Documentation/git-branch.txt\n@@ -142,6 +142,7 @@ start-point is either a local or remote branch.\n \tbranch points to is not changed.\n \n --contains ::\n+--with ::\n \tOnly list branches which contain the specified commit.\n \n --merged []::\n-- \n1.7.2.3\n"},{"id":"150203","messageId":"AANLkTin9j9LEF=zaZnso+0E0S_eTy1q6FM5d1h0q92jq@mail.gmail.com","threadId":"24992","inReplyTo":"20100907055209.GT1182@burratino","subject":"Re: [PATCH] Documentation: explain \"git branch --with\"","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-09-07T10:51:22Z","receivedAt":"2010-09-07T10:51:22Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Tue, Sep 7, 2010 at 05:52, Jonathan Nieder wrote:\n> How about adding it to the man page so people can look up this option\n> after encountering it in the wild?\n\nMuch better, thanks.\n"},{"id":"150213","messageId":"AANLkTimhucSrdQ6GKEDkWXuZkF+oCJbGkP_ZxgR3FdVg@mail.gmail.com","threadId":"24992","inReplyTo":"7v39tmtpci.fsf@alter.siamese.dyndns.org","subject":"Re: Determining commit reachability","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2010-09-07T13:04:56Z","receivedAt":"2010-09-07T13:04:56Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Sep 7, 2010 at 9:38 AM, Junio C Hamano wrote:\n> Somehow people wanted to see an option with a longer name, but by that\n> time my fingers were well trained, so I kept \"--with\" but didn't bother\n> advertising duplicated options.\n\nBut do you object a document patch for that option? I ask because I\nfound another undocumented option, --clear-resolve-undo in\nupdate-index and was wondering if it's worth a patch.\n-- \nDuy\n"},{"id":"150214","messageId":"AANLkTimzSV-M_ed8-vK+P_3-QpC3THdEpMQZbuM1Q-Sp@mail.gmail.com","threadId":"24992","inReplyTo":"AANLkTimhucSrdQ6GKEDkWXuZkF+oCJbGkP_ZxgR3FdVg@mail.gmail.com","subject":"Re: Determining commit reachability","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2010-09-07T13:07:07Z","receivedAt":"2010-09-07T13:07:07Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Sep 7, 2010 at 11:04 PM, Nguyen Thai Ngoc Duy wrote:\n> On Tue, Sep 7, 2010 at 9:38 AM, Junio C Hamano wrote:\n>> Somehow people wanted to see an option with a longer name, but by that\n>> time my fingers were well trained, so I kept \"--with\" but didn't bother\n>> advertising duplicated options.\n>\n> But do you object a document patch for that option? I ask because I\n> found another undocumented option, --clear-resolve-undo in\n> update-index and was wondering if it's worth a patch.\n\nHmm.. just saw Jonathan's patch. I guess I just go ahead and make a patch then.\n-- \nDuy\n"},{"id":"150417","messageId":"7vhbhyleo6.fsf@alter.siamese.dyndns.org","threadId":"24992","inReplyTo":"20100907055209.GT1182@burratino","subject":"Re: [PATCH] Documentation: explain \"git branch --with\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-09-09T22:45:13Z","receivedAt":"2010-09-09T22:45:13Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder writes:\n\n> More precisely, it is advertised by \"git branch --help-all\" but not\n> the manual or \"git branch -h\".\n\nSorry, but I don't understand what you are trying to say here. Isn't it\nthe whole point of distinction between --help-all vs -h (aka\nPARSE_OPT_HIDDEN)?\n\nSome interesting findings after a quick \"grep\" to see which ones are\nhidden (potential bugs below might be good for janitors).\n\n* apply --allow-binary-replacement, --binary\n\n These are always on, and are no-op (even --no-binary is a no-op);\n documented.\n\n* archive -[2-8]\n\n git-archive manual page mentions -0 thru -9 can be used as \"zip backend\n option\", while explicitly describing -0 and -9. \"git archive -h\" gives\n special description for -1 as well. Perhaps we should be consistent and\n document -1 in the manual page.\n \n* checkout --[no-]guess\n\n Controls the \"dwim 'git checkout x' to 'git checkout -b x remote/x' when\n 'x' cannot possibly name anything other than a branch that we copied\n from a remote repository uniquely\"; since the dwimming is on by default,\n the only use case is to say --no-guess; not documented.\n\n* clone --naked\n\n An old name used during the development for the current --bare option;\n not documented.\n\n* commit --allow-empty --allow-empty-message\n\n Documented; hidden primarily to discourage their uses and also to keep\n output from 'commit -h' short.\n\n* fmt-merge-msg --summary\n\n An old name used during the development for the current --log option;\n documented.\n\n* grep --help-all, show-ref --help-all\n\n I do not know why an entry for this needs to be in the struct option []\n for the command. It is not (and should not be) documented in the manual\n page of the individual commands.\n\n* show-ref -h\n\n \"-h\" was meant to be a historical synonym for \"--head\" (i.e. tells the\n command include HEAD in the output not just under refs/ hierarchy), but\n it seems that we broke it somewhere between v1.6.5 and v1.7.0; it now\n shows the help text.\n\n* write-tree --ignore-cache-tree\n\n A debugging aid; not documented.\n\n\nIt seems that our use of OPT_HIDDEN or if a hidden option is documented\nare not entirely consistent. The \"--with\" under discussion is similar to\n\"clone --naked\" and \"fmt-merge-msg --summary\".\n\nI am Ok with a policy to document historical synonyms that are hidden, but\nif we were to document them, I suspect that we would need to explicitly\nstate they are synonyms. Otherwise, somebody who saw this...\n\n> --contains ::\n> +--with ::\n> \tOnly list branches which contain the specified commit.\n\n... for the first time is bound to ask what the differences are between\nthe two.\n"}]}