git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Duy Nguyen <pclouds@gmail.com>
To: Jakub Narebski <jnareb@gmail.com>
Cc: Git Mailing List <git@vger.kernel.org>,
	Junio C Hamano <gitster@pobox.com>, Kyle Meyer <kyle@kyleam.com>,
	"Boettger, Heiko" <Heiko.Boettger@karlstorz.com>,
	"brian m. carlson" <sandals@crustytoothpaste.net>
Subject: Re: [PATCH/RFC] get_oid: new extended SHA-1 syntax to control resolution process
Date: Mon, 1 Jul 2019 07:30:40 +0700	[thread overview]
Message-ID: <CACsJy8AQ=kiG4jH5WSujefoCQ2yCG4=dV7UUdVh-Gextoa_T7A@mail.gmail.com> (raw)
In-Reply-To: <86a7dz4e06.fsf@gmail.com>

On Sun, Jun 30, 2019 at 4:30 PM Jakub Narebski <jnareb@gmail.com> wrote:
>
> Bikeshed painting ahead.
>
> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> [...]
> > The problem is we try every possible way to resolve a rev. Let's have
> > some annotation to express that we only want to resolve a rev in a
> > certain way:
> >
> > - <hash>@{hash} only accepts a full hash or a short hash. If it's a
> >   short hash, it cannot be ambiguous.
> >
> > - <ref>@{literal} only accepts full ref. No turning "master" into
> >   "refs/heads/master".
> >
> > - <output>@{describe} interprets <output> as git-describe output
> >   only, not an object name or a reference.
> >
> > This gives scripts much better control over get_oid(), which
> > translates to rev-parse and a bunch other commands.
> >
> > PS. The new syntax can stack with existing ones. E.g. you could write
> > refs/heads/master@{literal}@{yesterday} or <hash>@{hash}^{tree}.
> > Perhaps I should allow these tags at the end too, so you can enforce a
> > variable like "$REV"@{literal} where $REV could be even HEAD~123
>
> I think it would be better to use <hash>^{hash} instead of
> <hash>@{hash}.
>
> The <ref-ish>@{<something>} is used currently for information that is
> outside the DAG, like @{<date>}, @{<n>}, @{-<n>} uses information from
> reflog, and @{upstream} and @{push} uses information from the config.
>
> On the other hand ^{<type>}, ^{/<search text>}, and the future
> ^{<hashalgo>} all use DAG-only information.

I wasn't aware of ^{<hashalgo>}. hash-function-transition.txt is a bit
light on the exact behavior, but maybe we can just define it like
<hash>@{hash} in this thread (then we don't even need to introduce
@{hash})?

That is, if <hash>^{<hashalgo>} fails to find a matching object, the
get_oid() result is "not found", there will be no further attempt to
interpret the given revision in a different way (e.g. try to see if
the same ref exists...). It also means <hash>^{<hashalgo>} will remain
supported even after the sha-512 transition period.

@{describe} might go  the same way as @{hash} (that is, becoming
^{describe}). I think it's just a slightly different way to write
hashes.

> Though one could argue that refs information _is_ outside the DAG...

Refs info is outside DAG. But that's mostly for <ref>@{literal} and it
allows something like <ref>@{literal}@{upstream}. But hash (or object
name) is already used inside DAG (to link between commits, trees and
blobs). Though one might still argue that's only true for full hash,
not short ones.
-- 
Duy

      reply	other threads:[~2019-07-01  0:31 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-20 14:32 specifying revision - how to enforce matching a tag/branch-name or revision only Boettger, Heiko
2019-06-20 22:54 ` Kyle Meyer
2019-06-21 15:16   ` Junio C Hamano
2019-06-25 11:43     ` Duy Nguyen
2019-06-25 14:35       ` AW: " Boettger, Heiko
2019-06-26  8:41 ` [PATCH/RFC] get_oid: new extended SHA-1 syntax to control resolution process Nguyễn Thái Ngọc Duy
2019-06-26 18:51   ` Junio C Hamano
2019-06-27  2:52     ` Duy Nguyen
2019-06-27 16:47       ` Junio C Hamano
2019-06-30  9:30   ` Jakub Narebski
2019-07-01  0:30     ` Duy Nguyen [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CACsJy8AQ=kiG4jH5WSujefoCQ2yCG4=dV7UUdVh-Gextoa_T7A@mail.gmail.com' \
    --to=pclouds@gmail.com \
    --cc=Heiko.Boettger@karlstorz.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jnareb@gmail.com \
    --cc=kyle@kyleam.com \
    --cc=sandals@crustytoothpaste.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).