Btw, take a look at https://wiki.openstack.org/wiki/GitCommitMessages
to see more clear what I mean with commiting changes separately. They
have a very good discussion about what differs good commits from bad
ones, not necessarily applying to only git.
regards,
Roland
On Fri, Jan 31, 2014 at 11:22 AM, Roland Knall <rknall@xxxxxxxxx> wrote:
> 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
