Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] Quick start instructions for Gerrit

From: Roland Knall <rknall@xxxxxxxxx>
Date: Fri, 31 Jan 2014 11:22:24 +0100
On Fri, Jan 31, 2014 at 10:40 AM, Guy Harris <guy@xxxxxxxxxxxx> wrote:
> ...and I use multiple sheets of paper for multiple ideas.
>
> I.e., it sounded as if you were talking about using a *single* checked-out tree for *multiple independent* projects, which I would no more do than would I use a single window for multiple Web pages.
>
> If you're talking about using separate trees (i.e., separate directory hierarchies) for those projects, I'm not sure why they need to be branches.

Various projects yes, but within the same master-project. It often
happens, that some changes are merged into on patch, but they should
be accepted as separate, so that it can be easier tracked, when a
modification leads to a faulty behaviour. It is just a different way
of viewing things, and I by no mean would suggest, that my solution is
better than someone elses, it is just the way our company has been
working with gerrit for the past 2 1/2 years. For us (developing
embedded fw and protocols for automotive components) it works great,
but it might not work for other scnearios.

But one clarification. You do not check-out a project with git. This
is a misconception. You clone the complete repository of wireshark
into a local copy. From that point forward you are completely on your
own. For instance your commid ids and the commit ids for patches you
submitted to the master repo, most certainly won't match.  And from
this situation (you have a local copy of a remote system) comes the
idea, that the master branch is being kept clean. So to allways
symbolize, where the remote copy is positioned at.

As said before, whatever works, will work. This is one of the great
things about open-source. In my pov, keeping the master clean is just
easier, especially if the projects get larger and blaming (see
git-blame) changes is a regular necessity.

regards,
Roland