From: Johan Herland <johan@herland.net>
To: "Santi Béjar" <santi@agolina.net>
Cc: git@vger.kernel.org, Sverre Rabbelier <srabbelier@gmail.com>,
Jeff King <peff@peff.net>,
Nguyen Thai Ngoc Duy <pclouds@gmail.com>,
Nicolas Pitre <nico@fluxnic.net>,
johan@herland.net
Subject: Re: [1.8.0] Provide proper remote ref namespaces
Date: Wed, 2 Feb 2011 16:51:21 +0100 [thread overview]
Message-ID: <201102021651.21669.johan@herland.net> (raw)
In-Reply-To: <AANLkTimqQtLB--7pwwTALmcchnNCX0nm4Rfx8w1gp74T@mail.gmail.com>
On Wednesday 02 February 2011, Santi Béjar wrote:
> On Wednesday 02 February 2011, Johan Herland wrote:
> > Proposal:
> >
> > Currently, git stores remote refs in the local repo by default as
> > follows:
> >
> > Remote repo -> Local repo
> > ---------------------------------------------------------
> > HEAD refs/remotes/$remote/HEAD (implicit)
> > refs/heads/* refs/remotes/$remote/*
> > refs/tags/* refs/tags/* (implicit, autofollow)
> > refs/replace/* (TBD)
> > refs/notes/* (TBD)
> >
> > Instead, we should change the default ref mappings into the
> > following:
> >
> > Remote repo -> Local repo
> > --------------------------------------------------
> > HEAD refs/remotes/$remote/HEAD
> > refs/heads/* refs/remotes/$remote/heads/*
> > refs/tags/* refs/remotes/$remote/tags/*
> > refs/replace/* refs/remotes/$remote/replace/*
> > refs/notes/* refs/remotes/$remote/notes/*
>
> [...]
>
> > - We might want to generalize the handling of "$remote/$head" into
> > allowing shorthands like "$remote/$tag", "$remote/$replace" and
> > "$remote/$note" as well (provided, of course, that they match
> > unambiguously).
>
> [...]
>
> > [2]: When looking up a shorthand tag name (e.g. v1.7.4): If a local
> > tag (refs/tags/v1.7.4) is found, then we have an unambiguous match.
> > If no local tag is found, we look up the tag name in all configured
> > remotes (using the method described in [1]). If the tag name exists
> > in one or more remotes, and those remotes all agree on its ultimate
> > object name (after applying e.g. ^{commit} or whatever is
> > appropriate in the context of the lookup), then we also have an
> > unambiguous match. However, if the tag name exists in multiple
> > remotes, and they do NOT all agree on its ultimate object name,
> > then the shorthand tag name is ambiguous and the lookup fails. The
> > user can always resolve this ambiguity by creating a local tag
> > (refs/tags/v1.7.4) pointing to the desired object.
>
> And the other way around. What would be the output of "git name-rev"
> , "git describe", "--decorate", and such? $remote/tags/$tag?
> $remote/$tag? $tag?
>
> I would say $remote/$tag for "git name-rev" and "--decorate" but $tag
> for "git describe" as it is usually used to create files, i.e.
> git-1.7.4.261.g705f.tar.gz. And I think many people, me included, do
> not expect to have an / in the "git describe" output, at least in the
> default output (in contrast with the --all flag).
Thanks for raising an important point.
I don't buy the file name creation argument, as 'describe' is used from
many different contexts, and file name creation is nowhere documented
as one of its primary objectives.
Still, the objective of 'describe' is to create a human-readable string
that tries to say something meaningful about a commit in relation to
its preceding history, while at the same time uniquely identifying the
commit. The "uniquely identifying" part is taken care of by
the "-g<SHA1>" part of the output, while the initial "<tagname>-<n>"
part makes it human-friendly. Therefore, we only care that the
<tagname> is fairly unambiguous in the mind of the reader. From this
perspective, which of the alternatives makes more sense? I would
disqualify "$remote/$tag" and "$remote/tags/$tag", since the $remote
name is repo-specific, and 'describe' output is often passed around
between multiple developers/repos. Hence, I think that "$tag" is a good
choice for 'describe'. If "$tag" is ambiguous in the current repo, then
an "ambiguous tag" tag warning can be printed, but I would still
use "$tag".
When it comes to 'name-rev' and '--decorate', those are (AFAICS) much
more repo-specific, and seldom passed between users. Also, they don't
have the "-g<SHA1>" part from the 'describe' output. Hence, in this
case, I consider unique identification (unambiguity) much more
important than not displaying $remote names. Therefore, I'd propose
using the shortest unambiguous alternative.
> Another point to consider is if we want a default remote for tags, a
> config tags.defaultRemote (TBD), defaulting to origin, specifying the
> default remote for tags. There would be a hierarchy: local tags,
> default remote tags, remote tags. With this if one tag is on multiple
> remote the tag from the default remote always wins.
>
> In this way all the tag related input/output would no change much.
> For example all the decoration would be $tag instead of origin/tag.
Agreed, tags.defaultRemote (or tags.preferredRemote if I'm allowed to
bikeshed) may be a valuable addition. Another way to achieve this would
be to explicitly copy tags from the preferred remote (e.g. origin)
directly into refs/tags. I.e. in addition to the (new) default tag
refspec
+refs/tags/*:refs/remotes/origin/tags/*
you could add an _additional_ refspec
refs/tags/*:refs/tags/*
that would also copy all of origin's tags directly into your local tag
namespace.
Thanks for the feedback! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
next prev parent reply other threads:[~2011-02-02 15:51 UTC|newest]
Thread overview: 105+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-01 10:44 [1.8.0] Remote tag namespace Nguyen Thai Ngoc Duy
2011-02-01 14:10 ` Leo Razoumov
2011-02-01 15:07 ` Marc Branchaud
2011-02-01 15:35 ` Nguyen Thai Ngoc Duy
2011-02-02 19:38 ` Marc Branchaud
2011-02-01 18:14 ` Jeff King
2011-02-01 23:14 ` Sverre Rabbelier
2011-02-02 2:21 ` [1.8.0] Provide proper remote ref namespaces Johan Herland
2011-02-02 13:27 ` Santi Béjar
2011-02-02 15:51 ` Johan Herland [this message]
2011-02-02 16:19 ` Santi Béjar
2011-02-03 5:33 ` Nguyen Thai Ngoc Duy
2011-02-03 8:46 ` Johan Herland
2011-02-03 11:35 ` Nguyen Thai Ngoc Duy
2011-02-03 13:10 ` Johan Herland
2011-02-03 14:10 ` Santi Béjar
2011-02-03 15:48 ` Nguyen Thai Ngoc Duy
2011-02-04 22:39 ` Junio C Hamano
2011-02-05 1:18 ` Johan Herland
2011-02-05 18:00 ` Kevin P. Fleming
2011-02-05 21:40 ` Dmitry Potapov
2011-02-06 0:04 ` Johan Herland
2011-02-06 12:03 ` Dmitry Potapov
2011-02-06 14:09 ` Nicolas Pitre
2011-02-06 15:17 ` Dmitry Potapov
2011-02-06 16:11 ` Johan Herland
2011-02-06 17:28 ` Dmitry Potapov
2011-02-06 22:12 ` Johan Herland
2011-02-07 0:07 ` Dmitry Potapov
[not found] ` <201102070429.05033.johan@herland.net>
2011-02-07 3:47 ` Nicolas Pitre
2011-02-08 1:06 ` Dmitry Potapov
2011-02-08 8:15 ` Johan Herland
2011-02-08 19:11 ` Enrico Weigelt
2011-02-08 23:13 ` Junio C Hamano
2011-02-09 1:24 ` Johan Herland
2011-02-07 19:05 ` Bernhard R. Link
2011-02-08 1:20 ` Dmitry Potapov
2011-02-06 20:28 ` Matthieu Moy
2011-02-06 23:22 ` Johan Herland
2011-02-06 23:51 ` Matthieu Moy
2011-02-07 3:51 ` Johan Herland
2011-02-07 5:11 ` Jeff King
2011-02-07 8:58 ` Johan Herland
2011-02-07 9:01 ` Sverre Rabbelier
2011-02-07 10:06 ` Johan Herland
2011-02-07 10:22 ` Nguyen Thai Ngoc Duy
2011-02-07 20:19 ` Jeff King
2011-02-08 0:59 ` Johan Herland
2011-02-11 15:13 ` Jakub Narebski
2011-02-13 23:36 ` Johan Herland
2011-02-14 7:35 ` Junio C Hamano
2011-02-14 9:18 ` Johan Herland
2011-02-14 9:59 ` Jakub Narebski
2011-02-14 17:30 ` Junio C Hamano
2011-02-14 18:06 ` Re* " Junio C Hamano
2011-02-14 18:53 ` Jay Soffian
2011-02-14 19:44 ` Sverre Rabbelier
2011-02-14 19:50 ` Jay Soffian
2011-02-14 21:21 ` [1.8.0 RFC] push: start warning upcoming default change for push.default Jonathan Nieder
2011-02-14 21:41 ` Jay Soffian
2011-02-14 21:55 ` Jonathan Nieder
2011-02-14 21:57 ` Re* [1.8.0] Provide proper remote ref namespaces Matthieu Moy
2011-02-14 22:35 ` Jeff King
2011-02-14 22:38 ` Sverre Rabbelier
2011-02-14 23:36 ` [1.8.0 RFC] push: start warning upcoming default change for push.default Jonathan Nieder
2011-02-14 23:45 ` Re* [1.8.0] Provide proper remote ref namespaces Junio C Hamano
2011-02-14 23:05 ` Junio C Hamano
2011-02-15 15:06 ` Johan Herland
2011-02-15 18:06 ` Junio C Hamano
2011-02-16 0:54 ` [PATCH] push.default: Rename 'tracking' to 'upstream' Johan Herland
2011-02-16 6:35 ` Junio C Hamano
2011-02-16 8:55 ` Matthieu Moy
2011-02-16 9:42 ` Martin von Zweigbergk
2011-02-16 10:08 ` Jakub Narebski
2011-02-16 10:26 ` Matthieu Moy
2011-02-16 10:27 ` Sverre Rabbelier
2011-02-16 17:56 ` Junio C Hamano
2011-02-16 18:08 ` Sverre Rabbelier
2011-02-16 18:37 ` Junio C Hamano
2011-02-18 0:51 ` Martin von Zweigbergk
2011-02-18 0:57 ` Martin von Zweigbergk
2011-02-16 10:54 ` Bernhard R. Link
2011-02-14 9:40 ` [1.8.0] Provide proper remote ref namespaces Jakub Narebski
2011-02-14 15:45 ` Marc Branchaud
2011-02-14 19:35 ` Nicolas Pitre
2011-02-14 18:30 ` Junio C Hamano
2011-02-14 19:06 ` Nicolas Pitre
2011-02-14 19:46 ` Sverre Rabbelier
2011-02-07 6:54 ` Matthieu Moy
2011-02-07 0:14 ` Dmitry Potapov
2011-02-05 18:39 ` Nicolas Pitre
2011-02-05 19:37 ` Jeff King
2011-02-05 19:55 ` Nicolas Pitre
2011-02-05 23:39 ` Johan Herland
2011-02-06 20:04 ` Junio C Hamano
2011-02-07 16:10 ` Marc Branchaud
2011-02-07 19:40 ` Junio C Hamano
2011-02-07 20:37 ` Nicolas Pitre
2011-02-07 5:18 ` Jeff King
2011-02-07 14:53 ` Nicolas Pitre
2011-02-07 20:25 ` Jeff King
2011-02-07 20:51 ` Nicolas Pitre
2011-02-07 20:56 ` Jeff King
2011-02-01 23:15 ` [1.8.0] Remote tag namespace Johan Herland
-- strict thread matches above, loose matches on Subject: below --
2011-02-07 3:35 [1.8.0] Provide proper remote ref namespaces Johan Herland
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=201102021651.21669.johan@herland.net \
--to=johan@herland.net \
--cc=git@vger.kernel.org \
--cc=nico@fluxnic.net \
--cc=pclouds@gmail.com \
--cc=peff@peff.net \
--cc=santi@agolina.net \
--cc=srabbelier@gmail.com \
/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).