# Determining commit reachability 13 messages from 2010-09-05 to 2010-09-09. Participants: Artur Skawina, Jeff King, Junio C Hamano, Sverre Rabbelier, Ævar Arnfjörð Bjarmason, Jonathan Nieder, Nguyen Thai Ngoc Duy. Thread: https://gitlist.dev/t/24992 ## Artur Skawina, 2010-09-05 20:34 Subject: Determining commit reachability Message-ID: <4C83FEC3.3040101@gmail.com> URL: https://gitlist.dev/e/4C83FEC3.3040101%40gmail.com ``` Given commit C, refs (branches) R, S and T what would be the best way to test whether 'C' is reachable from any of the heads? Checking if `git rev-list -n1 O ^R ^S ^T` produces any output is what i came up with; is there a better (ie faster) solution? artur ``` ## Jeff King, 2010-09-06 03:17 Subject: Re: Determining commit reachability Message-ID: <20100906031700.GA25012@sigill.intra.peff.net> URL: https://gitlist.dev/e/20100906031700.GA25012%40sigill.intra.peff.net In-Reply-To: <4C83FEC3.3040101@gmail.com> ``` On Sun, Sep 05, 2010 at 10:34:11PM +0200, Artur Skawina wrote: > Given commit C, refs (branches) R, S and T what would be the best way > to test whether 'C' is reachable from any of the heads? > > Checking if `git rev-list -n1 O ^R ^S ^T` produces any output is what > i came up with; is there a better (ie faster) solution? I think that is about as fast as you will get. You could try something with git-merge-base, but it should be about the same speed. Note that neither will tell you _which_ head the target was reachable from. For that, given the current interface you have to test each head individually. If you write some C code, you can do it all in a single traversal. See this thread for some discussion of how "git tag --contains" can be sped up: http://article.gmane.org/gmane.comp.version-control.git/150039 -Peff ``` ## Artur Skawina, 2010-09-06 05:04 Subject: Re: Determining commit reachability Message-ID: <4C847661.3020800@gmail.com> URL: https://gitlist.dev/e/4C847661.3020800%40gmail.com In-Reply-To: <20100906031700.GA25012@sigill.intra.peff.net> ``` On 09/06/10 05:17, Jeff King wrote: > On Sun, Sep 05, 2010 at 10:34:11PM +0200, Artur Skawina wrote: > >> Given commit C, refs (branches) R, S and T what would be the best way >> to test whether 'C' is reachable from any of the heads? >> >> Checking if `git rev-list -n1 O ^R ^S ^T` produces any output is what >> i came up with; is there a better (ie faster) solution? > > I think that is about as fast as you will get. You could try something > with git-merge-base, but it should be about the same speed. > > Note that neither will tell you _which_ head the target was reachable > from. For that, given the current interface you have to test each head As i think i'll only need this to prevent leaking (private) commits that wouldn't be reachable from the (public) heads, just catching the unreachable ones should be enough. $ time git rev-list -n1 v2.6.12 ^v33 ^v35 0m2.333s user 0m0.040s system 0m2.379s elapsed 99.77% CPU $ time git rev-list -n1 v2.6.36-rc2 ^v33 ^v35 76be97c1fc945db08aae1f1b746012662d643e97 0m0.500s user 0m0.010s system 0m0.514s elapsed 99.13% CPU A bit expensive, but I guess should it become a problem I could cache the result and/or blacklist the client. Thanks, artur ``` ## Junio C Hamano, 2010-09-06 06:47 Subject: Re: Determining commit reachability Message-ID: <7viq2jv05c.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7viq2jv05c.fsf%40alter.siamese.dyndns.org In-Reply-To: <4C83FEC3.3040101@gmail.com> ``` Artur Skawina writes: > Given commit C, refs (branches) R, S and T what would be the best way > to test whether 'C' is reachable from any of the heads? Depends on the definition of "best", but I often find myself typing git branch --with C where C often is somewhere between 'master' and 'ko/master' (the 'master' branch everybody else has already seen on k.org). When I have second thoughts sometime after applying a patch directly on top of 'master', I need to see if I have built a new topic branch forking from the faulty commit before rewinding it, as such a topic branch also needs to be rewound. ``` ## Sverre Rabbelier, 2010-09-06 20:45 Subject: Re: Determining commit reachability Message-ID: URL: https://gitlist.dev/e/AANLkTinDfCkkY_D6F7VepvuNAN1g1hC9UgnqRUjZn88y%40mail.gmail.com In-Reply-To: <7viq2jv05c.fsf@alter.siamese.dyndns.org> ``` Heya, On Mon, Sep 6, 2010 at 01:47, Junio C Hamano wrote: > Depends on the definition of "best", but I often find myself typing > >    git branch --with C In case anyone else is wondering, '--with' is a hidden alias for '--contains'. -- Cheers, Sverre Rabbelier ``` ## Ævar Arnfjörð Bjarmason, 2010-09-06 20:53 Subject: Re: Determining commit reachability Message-ID: URL: https://gitlist.dev/e/AANLkTim4kxpQj_UFOBcwCaVmBFCHun4T9t3O9Zvq3w49%40mail.gmail.com In-Reply-To: ``` On Mon, Sep 6, 2010 at 20:45, Sverre Rabbelier wrote: > Heya, > > On Mon, Sep 6, 2010 at 01:47, Junio C Hamano wrote: >> Depends on the definition of "best", but I often find myself typing >> >>    git branch --with C > > In case anyone else is wondering, '--with' is a hidden alias for '--contains'. Maybe it should be documented? ``` ## Sverre Rabbelier, 2010-09-06 21:05 Subject: Re: Determining commit reachability Message-ID: URL: https://gitlist.dev/e/AANLkTinPDUeL2jaY3P17TiA959WH8eOQZ4%3DCeaHOYuq2%40mail.gmail.com In-Reply-To: ``` Heya, On Mon, Sep 6, 2010 at 15:53, Ævar Arnfjörð Bjarmason wrote: > On Mon, Sep 6, 2010 at 20:45, Sverre Rabbelier wrote: >> In case anyone else is wondering, '--with' is a hidden alias for '--contains'. > > Maybe it should be documented? Junio added it that way back in "git-branch --contains=commit" v1.5.3.6-879-g694a577 (Nov 7 2007) when the feature was added. Junio, do you remember why you added "--with" as a hidden alias? -- Cheers, Sverre Rabbelier ``` ## Junio C Hamano, 2010-09-06 23:38 Subject: Re: Determining commit reachability Message-ID: <7v39tmtpci.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7v39tmtpci.fsf%40alter.siamese.dyndns.org In-Reply-To: ``` Sverre Rabbelier writes: > On Mon, Sep 6, 2010 at 15:53, Ævar Arnfjörð Bjarmason wrote: >> On Mon, Sep 6, 2010 at 20:45, Sverre Rabbelier wrote: >>> In case anyone else is wondering, '--with' is a hidden alias for '--contains'. >> >> Maybe it should be documented? > > Junio added it that way back in "git-branch --contains=commit" > v1.5.3.6-879-g694a577 (Nov 7 2007) when the feature was added. Junio, > do you remember why you added "--with" as a hidden alias? It was originally called --with. I wrote it to help me in the exact use case in this thread, and the option was naturally named --with, as the request I wanted to make was "Give me branches _with_ this commit, so that I know which ones I need to rewind before reintegrating and publishing". Somehow people wanted to see an option with a longer name, but by that time my fingers were well trained, so I kept "--with" but didn't bother advertising duplicated options. ``` ## Jonathan Nieder, 2010-09-07 05:52 Subject: [PATCH] Documentation: explain "git branch --with" Message-ID: <20100907055209.GT1182@burratino> URL: https://gitlist.dev/e/20100907055209.GT1182%40burratino In-Reply-To: <7v39tmtpci.fsf@alter.siamese.dyndns.org> ``` Junio C Hamano wrote: > It was originally called --with. I wrote it to help me in the exact use > case in this thread, and the option was naturally named --with, as the > request I wanted to make was "Give me branches _with_ this commit, so that > I know which ones I need to rewind before reintegrating and publishing". > > Somehow people wanted to see an option with a longer name, but by that > time my fingers were well trained, so I kept "--with" but didn't bother > advertising duplicated options. More precisely, it is advertised by "git branch --help-all" but not the manual or "git branch -h". How about adding it to the man page so people can look up this option after encountering it in the wild? Signed-off-by: Jonathan Nieder --- Documentation/git-branch.txt | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt index 1940256..f479e2f 100644 --- a/Documentation/git-branch.txt +++ b/Documentation/git-branch.txt @@ -142,6 +142,7 @@ start-point is either a local or remote branch. branch points to is not changed. --contains :: +--with :: Only list branches which contain the specified commit. --merged []:: -- 1.7.2.3 ``` ## Ævar Arnfjörð Bjarmason, 2010-09-07 10:51 Subject: Re: [PATCH] Documentation: explain "git branch --with" Message-ID: URL: https://gitlist.dev/e/AANLkTin9j9LEF%3DzaZnso%2B0E0S_eTy1q6FM5d1h0q92jq%40mail.gmail.com In-Reply-To: <20100907055209.GT1182@burratino> ``` On Tue, Sep 7, 2010 at 05:52, Jonathan Nieder wrote: > How about adding it to the man page so people can look up this option > after encountering it in the wild? Much better, thanks. ``` ## Nguyen Thai Ngoc Duy, 2010-09-07 13:04 Subject: Re: Determining commit reachability Message-ID: URL: https://gitlist.dev/e/AANLkTimhucSrdQ6GKEDkWXuZkF%2BoCJbGkP_ZxgR3FdVg%40mail.gmail.com In-Reply-To: <7v39tmtpci.fsf@alter.siamese.dyndns.org> ``` On Tue, Sep 7, 2010 at 9:38 AM, Junio C Hamano wrote: > Somehow people wanted to see an option with a longer name, but by that > time my fingers were well trained, so I kept "--with" but didn't bother > advertising duplicated options. But do you object a document patch for that option? I ask because I found another undocumented option, --clear-resolve-undo in update-index and was wondering if it's worth a patch. -- Duy ``` ## Nguyen Thai Ngoc Duy, 2010-09-07 13:07 Subject: Re: Determining commit reachability Message-ID: URL: https://gitlist.dev/e/AANLkTimzSV-M_ed8-vK%2BP_3-QpC3THdEpMQZbuM1Q-Sp%40mail.gmail.com In-Reply-To: ``` On Tue, Sep 7, 2010 at 11:04 PM, Nguyen Thai Ngoc Duy wrote: > On Tue, Sep 7, 2010 at 9:38 AM, Junio C Hamano wrote: >> Somehow people wanted to see an option with a longer name, but by that >> time my fingers were well trained, so I kept "--with" but didn't bother >> advertising duplicated options. > > But do you object a document patch for that option? I ask because I > found another undocumented option, --clear-resolve-undo in > update-index and was wondering if it's worth a patch. Hmm.. just saw Jonathan's patch. I guess I just go ahead and make a patch then. -- Duy ``` ## Junio C Hamano, 2010-09-09 22:45 Subject: Re: [PATCH] Documentation: explain "git branch --with" Message-ID: <7vhbhyleo6.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7vhbhyleo6.fsf%40alter.siamese.dyndns.org In-Reply-To: <20100907055209.GT1182@burratino> ``` Jonathan Nieder writes: > More precisely, it is advertised by "git branch --help-all" but not > the manual or "git branch -h". Sorry, but I don't understand what you are trying to say here. Isn't it the whole point of distinction between --help-all vs -h (aka PARSE_OPT_HIDDEN)? Some interesting findings after a quick "grep" to see which ones are hidden (potential bugs below might be good for janitors). * apply --allow-binary-replacement, --binary These are always on, and are no-op (even --no-binary is a no-op); documented. * archive -[2-8] git-archive manual page mentions -0 thru -9 can be used as "zip backend option", while explicitly describing -0 and -9. "git archive -h" gives special description for -1 as well. Perhaps we should be consistent and document -1 in the manual page. * checkout --[no-]guess Controls the "dwim 'git checkout x' to 'git checkout -b x remote/x' when 'x' cannot possibly name anything other than a branch that we copied from a remote repository uniquely"; since the dwimming is on by default, the only use case is to say --no-guess; not documented. * clone --naked An old name used during the development for the current --bare option; not documented. * commit --allow-empty --allow-empty-message Documented; hidden primarily to discourage their uses and also to keep output from 'commit -h' short. * fmt-merge-msg --summary An old name used during the development for the current --log option; documented. * grep --help-all, show-ref --help-all I do not know why an entry for this needs to be in the struct option [] for the command. It is not (and should not be) documented in the manual page of the individual commands. * show-ref -h "-h" was meant to be a historical synonym for "--head" (i.e. tells the command include HEAD in the output not just under refs/ hierarchy), but it seems that we broke it somewhere between v1.6.5 and v1.7.0; it now shows the help text. * write-tree --ignore-cache-tree A debugging aid; not documented. It seems that our use of OPT_HIDDEN or if a hidden option is documented are not entirely consistent. The "--with" under discussion is similar to "clone --naked" and "fmt-merge-msg --summary". I am Ok with a policy to document historical synonyms that are hidden, but if we were to document them, I suspect that we would need to explicitly state they are synonyms. Otherwise, somebody who saw this... > --contains :: > +--with :: > Only list branches which contain the specified commit. ... for the first time is bound to ask what the differences are between the two. ```