Re: Local tag killer

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Sep 29, 2013 at 6:29 AM, Michael Haggerty <mhagger@xxxxxxxxxxxx> wrote:
> I wonder whether remotes.group could sensibly be used to group remotes
> into logical groups for value lookups:
>
>     [remotes]
>             gitk = gitk-origin
>             gitk = second-gitk-repo
>
> Then DWIM could be taught to seek "gitk/foo" under
> "refs/remotes/gitk-origin/tags/foo" and
> "refs/remotes/second-gitk-repo/tags/foo" in addition to
> "refs/tags/gitk/foo" (insisting, of course, that if more than one of
> these are present that they are all consistent).

This is an interesting idea. AFAICS, remotes.<group> is currently only
used by "git remote update" and "git fetch". According to git-remote(1)
it's used like this:

    [git remote] update
        Fetch updates for a named set of remotes in the repository
        as defined by remotes.<group>. If a named group is not
        specified on the command line, the configuration parameter
        remotes.default will be used; if remotes.default is not
        defined, all remotes which do not have the configuration
        parameter remote.<name>.skipDefaultUpdate set to true will
        be updated. (See git-config(1)).

I believe this would work well when extended to ref lookup as well:

 - Defining remotes.$group allows you to lookup refs across the grouped
   remotes by using the "$group/<ref>" syntax, as you describe above.

 - If remotes.default is defined, ref lookup happens by default across
   only those remotes, i.e. "$tag" will be sought under refs/tags/$tag
   and then refs/remotes/$remote/tags/$tag for each $remote in
   remotes.default.

 - If remotes.default is not defined, ref lookup happens across all
   remotes. This is analogous to what happens with tags today; they
   are all dumped into refs/tags/* and lookup considers all of them.

> Remote groups might also be used to configure the remotes that describe
> considers when describing a commit:
>
>     [remotes]
>             describe = junio
>             describe = jrn
>
> or maybe (using the above config)
>
>     git describe --remote-group=gitk

Hmm. I'd like to apply the same rules here, to stay consistent:

 - "git describe --from=$remote1 --from=$remote2" considers tags
   from refs/remotes/$remote1/tags/* and refs/remotes/$remote2/tags/*

 - "git describe --from=$group" considers tags from
   refs/remotes/$remote/tags/* for each $remote in $group

 - "git describe" considers tags from all remotes mentioned in
   remotes.default, or _all_ remotes is remotes.default is unset.

Additionally:

 - "git describe" (without --from) also considers (and prefers?) local
   tags.

 - "git describe --from=foo" does NOT consider local tags, but will
   also consider them if "--from=." is used.


...Johan

--
Johan Herland, <johan@xxxxxxxxxxx>
www.herland.net
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]