Tags or label like p4

[Arun Kumar Bevara]

Is there a way in git to tag a bunch of gerrits or codebase to a certain poitn with a something like a label or name or version etc. This would be helpful for us to identify exactly our point of verification.

[Magnus Bäck]

On Friday, May 03, 2013 at 11:05 EDT,

Not sure what you mean by "a bunch of gerrits", but Git's tags allow you
to label commits (representing the full state of the source code) with
an (almost) arbitrary string. Note that the commit SHA-1 is unique in
itself (similar to a changelist number in Perforce), so as opposed to
some other version control systems you don't need tags/label just to
identify the source code state.

--
Magnus Bäck
ba...@google.com

[Phil Hord]

Arun,

See 'git help tag' for tagging options. If you need to tag multiple
projects or submodules, you can do that in each project. You will need
to create the tags locally on your workspace and then push the tags to
Gerrit for posterity.

Phil

> --
> --
> To unsubscribe, email repo-discuss...@googlegroups.com
> More info at http://groups.google.com/group/repo-discuss?hl=en
>
> ---
> You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Rich Schmitt]

A related question.  I'm not convinced tagging through gerrit is useable.  For instance, I created a commit and tagged that commit and pushed it into gerrit.  Since our repo is set up as 'cherry-pick' merge strategy, when the tag ultimately got merged, it was no longer pointing to where we wanted.  Besides, when tagging something through gerrit, there is no real way of knowing where that will end up in the target repo.

So, my conclusion is that tags should be placed directly on the target repo and shouldn't be pushed through gerrit.  Would others agree?

Rich

[Magnus Bäck]

On Monday, May 06, 2013 at 10:57 EDT,

Rich Schmitt <blue6...@gmail.com> wrote:

> A related question. I'm not convinced tagging through gerrit is
> useable.
> For instance, I created a commit and tagged that commit and pushed
> it into gerrit. Since our repo is set up as 'cherry-pick' merge
> strategy, when the tag ultimately got merged, it was no longer
> pointing to where we wanted.
> Besides, when tagging something through gerrit, there is no real way
> of knowing where that will end up in the target repo.
>
> So, my conclusion is that tags should be placed directly on the target
> repo and shouldn't be pushed through gerrit. Would others agree?

What's discouraged is tagging commits that won't end up on a branch.
Doing so is, as you've discovered, not useful. Giving tag push
permissions to users that don't have approval and submit permissions
could actually be a security problem.

However, tagging already submitted commits or commits that you know will
end up as part of a branch and push them through Gerrit is perfectly
fine. It's equivalent to applying the tag in the backing repository on
the server.

--
Magnus Bäck
ba...@google.com

[Arun Kumar Bevara]

Thanks all, for the info. To provide more granularity about the request, we have various levels of Build & Integration teams and here is the scenario in P4 that we are looking to emulate in Git\Gerrit

Integration team1 works on module 1 and verifies the sanity of a day's check-ins from developer by building and testing. Once determined good, they label it and pass it on to the next team

Team 2 gets such deliveries (labels) from various sub integration teams and builds everything together to verify all modules together work well and create their own label and pass it on to the next integration team.

In P4 this is straightforward since a label can be used to tag what was tested and built and pass on to the next team.

Is there any way to do this using Gerrit?

[Magnus Bäck]

On Monday, May 06, 2013 at 20:57 EDT,

Arun Kumar Bevara <arun....@gmail.com> wrote:

> Thanks all, for the info. To provide more granularity about the
> request, we have various levels of Build & Integration teams and here
> is the scenario in P4 that we are looking to emulate in Git\Gerrit
>
> Integration team1 works on module 1 and verifies the sanity of a day's
> check-ins from developer by building and testing. Once determined
> good, they label it and pass it on to the next team
> Team 2 gets such deliveries (labels) from various sub integration
> teams and builds everything together to verify all modules together
> work well and create their own label and pass it on to the next
> integration team.
>
> In P4 this is straightforward since a label can be used to tag what
> was tested and built and pass on to the next team.
>
> Is there any way to do this using Gerrit?

As we've said, use Git tags for this.

http://git-scm.com/book/en/Git-Basics-Tagging

I don't know your particular situation, but instead of replicating your
Perforce setup in Git, see if you can optimize it by removing the integration
teams or at least limiting the scope of what they need to do. I'm sure
a lot of what they're going could be replaced by automated tests run on
every commit (preferably before they're even submitted). I've worked
like what you're describing and it's inefficient, doesn't scale, and
leads to people not taking responsibility for what they're doing.

Such a change in how you work doesn't really have much to do with Git
or Gerrit (although it might be easier to implement than with Perforce),
but if you're going to make such a major disruptive change anyway it
might be easier to slip in other changes at the same time.

--
Magnus Bäck
ba...@google.com