初始化一个本地git / gerrit仓库 - 做这件事的最佳方法是什么? [英] Initializing a local git/gerrit repository - what's the optimal way to do this?

查看:455
本文介绍了初始化一个本地git / gerrit仓库 - 做这件事的最佳方法是什么?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

最近我问了一个问题关于镜像到gerrit的机制,但我开始认为这可能不是一个理想的事情(有用于知道,但可能不是这个用例)。这个问题建立在这个问题上。



我们希望在github上有一个项目,我们希望看到分支机构。我们会用gerrit来管理这个。我想查看分支(和标签),但我不想直接在远程分支上查看......我们将拥有自己的本地分支和标签。



目前我可以将这样的repo镜像到gerrit中,使其看起来完全像存储库的克隆,并具有分支和标记(例如,分支foobar保持本地foobar,而不是 origin / foobar 遥控器/原点/ foobar )。然而,似乎让远程引用留在 origin / foobar 或者可能是更好的(并且更符合通常的做法)。



因此,是否将某个外部项目镜像到本地gerrit(比如上面)中,而不是以允许其远程分支保持远程的方式进行克隆?如果我们永远不想直接在这些远程分支上检查,是否让远程引用指向 origin / foobar 而不是 foobar 很重要?最后,我希望在非镜像克隆上看到 origin / foobar ,我看到 remotes / origin / foobar ...我可能会做错什么那里? (我也失去了使用克隆进行裸镜像的好处,因此无论如何,这看起来都不太合适)。一个裸露的本地回购(我在原始问题中充实了详细过程,作为使用--mirror的替代方案)。



我会补充说我现在是了解相关问题。也许我特别反思了遥控的东西,但镜像或克隆的问题仍然存在 - 人们将基于标签和本地,唯一命名的分支而不是遥控器工作。我希望尽量避免可能出现的内部命名冲突,因此了解如何以最佳方式做到这一点不仅仅是学术性的。

解决方案

希望其他人可以参加。

最简单的解决方案似乎不是反映,而是简单地创建一个新的本地克隆,然后将其推送到gerrit,添加 refs / *:refs / *添加到push命令的末尾,以确保远程引用以gerrit的回购结束。



在这一点上,您可以看到远程引用如果你看看gerrit git repo本身(但不是在Web UI中,这很好......我们不想直接在这个工作中合并到它们)。

然后,开发人员可以从gerrit(或其克隆的副本)中克隆回购工作。为了看到远程分支引用,他们需要额外的步骤来获取引用,例如:
$ b $ pre $ g $ git getch fetch origin refs / remotes / *:refs / remotes / *

然后他们可以看到遥控器以及其他的东西。



如果您通过以镜像开头来完成所有这些工作,则外部引用将按原样引入(而不是作为远程引用)外部分支出现在gerrit网络用户界面中,就好像您将它们放在那里一样。这有它自己的用途,但是对于我所做的事情,这不会有帮助。


I asked a question recently about the mechanism for mirroring into gerrit, but I'm starting to think that perhaps that's not an ideal thing to do (useful to know but maybe not for this use case). This question builds upon that one.

There's a project on github we'd like to work on, and we'd like to see the branches for. We'd manage this with gerrit. I want to see the branches (and tags) but I don't want to check out directly on the remote branches... we'll have our own local branches and tags.

Currently I can mirror such a repo into gerrit, such that it appears exactly like a clone of the repository, with branches and tags in place (e.g., branch foobar remains foobar locally, not origin/foobar or remotes/origin/foobar). However, it appears that having the remote refs stay origin/foobar or such might be preferable (and more in line with how this is generally done).

So, is mirroring an external project into a local gerrit (such as above) in any way preferable to cloning it in a way that allows its remote branches to stay "remote"? Does having the remote refs pointing to origin/foobar instead of foobar matter, if we're never wanting to check out directly on those remote branches? Finally, where I'd expect to see origin/foobar on a non-mirror clone I'm seeing remotes/origin/foobar... what might I be doing wrong there? (I also lose the benefits of bare mirroring with clone, so that seems a poor option regardless.)

Note: the suggestion to use fetch is helpful as a way to populate a bare local repo (I fleshed out the detailed process in my original question, as an alternative to using --mirror).

I'll add that I'm now aware of a related question. Perhaps I'm overthinking the "remotes" thing in particular, but the question of mirror or clone remains - people will be working based on tags and local, uniquely named branches, not remotes. I'd like to strenuously avoid naming conflicts that could arise internally as well, so knowing how to do this optimally is not simply academic.

解决方案

Hopefully others chime in.

The simplest solution to this seems to be NOT to mirror but to simply make a new local clone, then push it to gerrit adding "refs/*:refs/*" to the end of the push command, so as to ensure the remote refs end up in gerrit's repo.

At that point you can see the remote refs if you look at the gerrit git repo itself (but not in the web UI, which is fine... we don't want to directly merge to them in this effort).

A developer can then clone the repo from gerrit (or a clone of it) to do work. TO see the remote branch refs though, they need to take the extra step of fetching the refs, thus:

git fetch origin refs/remotes/*:refs/remotes/*

Then they can see the remotes as well as everything else.

If you do all this by starting with a mirror, the external refs are brought in as-is (not as remotes), and the external branches appear in the gerrit web UI as if you put them there. That has its own uses, but for what I'm doing it would not be helpful.

这篇关于初始化一个本地git / gerrit仓库 - 做这件事的最佳方法是什么?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆