Re: [PATCH 2/2] checkout: introduce "--to-branch" option

> > +-w::
> > +--to-branch::
> > +     Rather than checking out a commit to work on it, checkout out
> > +     to the unique branch on it. If there are multiple branches on
> > +     the commit, the checkout will fail.
> > +
>
> So basically what this option implements is something that could be done
> as a shellscript of:
>
>         git_checkout_branch_from_oid () {
>                 rev=$1
>                 git for-each-ref --format='%(refname:strip=2)' --points-at $rev >/tmp/found
>                 if test $(wc -l </tmp/found) -ne 1
>                 then
>                         echo "Goldilocks error in finding $rev: $(cat /tmp/found)"
>                         return 1
>                 fi
>                 git checkout $found
>         }
>

> Which is not to say that it isn't useful, but that I think adding this
> to "git checkout" specifically is adding this to the wrong level. Isn't
> this useful to most things that parse revisions? I.e. wouldn't a better
> interface be via the peel syntax?
>
>     oid=$(git rev-parse HEAD)
>     git checkout $oid^{tobranch}
>
> Doing it that way would allow any arbitrary command that takes revisions
> now access to that, and we could have e.g. "^{tobranches}" too, so you
> could do:
>
>     git for-each-ref --format='%(refname:strip=2)' $oid^{tobranches}
>
> Or:
>
>     git log $oid^{tobranches}
>

> I think implementing that is a bit harder. It's peel_onion() in
> object-name.c. I think parse_branchname_arg() via get_oid_mb() is now
> only capable of filling in an OID for a given name, and then checking
> out that name comes as a separate step, and you can't just return
> e.g. "master".
>
> But I don't think anything stops us from adjusting those functions a bit
> so that get_oid_with_context(() and friends could pass down say an
> optional "struct string_list *", and the "peel" could then be expanded
> to that.
>