geda-developers team mailing list archive

[Peter TB Brett <peter@xxxxxxxxxxxxx>]

[ Taking this off gEDA-user --> gEDA-developers ]

On Fri, 30 Aug 2013 13:49:17 +0200, Markus Hitter <mah@xxxxxxxxxxx> wrote:
> Am 30.08.2013 07:38, schrieb Peter TB Brett:
>> One of the things that (I thought) all of the gEDA projects were
>> pretty clear about, when we transitioned to git back in 2007, was
>> that the main repositories should provide reliable history.
> 
> Not that I'm aware of this to be written down somewhere, there _is_ a
> reliable history. Where it counts: on the master branch and on the
> release branches.

The idea that one should assume that a git branch's history *doesn't*
describe the history of that branch is pretty bloody stupid.

>> If you want to mess around with rebasing, use a private repo.  In
>> the main gEDA repositories, merges should be used to show how
>> other developments are incorporated into branches.  Since git makes
>> merges *really easy* I don't feel like it's too much to ask.
> 
> With merging you actually obfuscate the history, because you create
> multiple parallel histories; making well known procedures like
> bisecting more difficult or even impossible. If we'd create a distinct
> history for every tiny bugfix-branch, we'd end up in a pretty mess.
> This are the reasons why I hope the idea of merging goes away, once
> people get used to Git.

I'm sorry, but you're entirely mistaken.  Unlike almost all other version
control systems, Git is *specifically designed* for extremely parallel
development with large numbers of branches and merges; tools such as "git
bisect" work perfectly happily on that kind of repository.  Look at the
Linux kernel git repository!

If you rewrite history with "git rebase" or stgit in the official
repository, then it breaks one of the most important principles of using
git for collaboration -- the idea that everyone has a copy of the same
history, and that a series of changes based on a particular HEAD commit can
easily be shared and applied by anybody else.  There's a *reason* why both
pcjc2 and I make a point of specifically noting that our work-in-progress
repos have unreliable history.

> Private repos are exactly the thing I try to overcome, because they
> pretty much prohibit collaboration.

How do private repositories prohibit collaboration?  All of my code and
work in progress is at http://github.com/peter-b/geda-gaf : anyone is free
to pull from it, but unlike the official repo I do not make any guarantees
about stability of history.  Similarly pcjc2 publishes his work in progress
git repos.  Would it make you happier if we started hosting personal git
repos on geda-project.org?

> I did quite a number of rebases in
> the central repo and so far I'm not aware of a single conflict caused
> by this.

DO NOT DO THIS.  Pushing to the official geda repositories with +<branch>
or --force is for EMERGENCIES ONLY.

When the git migration was carried out in 2007, this was discussed in great
detail with all of the current developers.  The consensus was that any
developer should feel free to do whatever they want to in their personal
responsibility, but that any patches they created should be finalised
*before* pushing them into the official repository.  Rather than rewriting
the repository history with git push --force, the right way to correct
commits made to the official repos has always been to *make another
commit*.  If your code is not yet ready for the main repository's master
branch, there are two options: 1) put it in your personal repository, or 2)
create a branch in the central repository, add commits to that branch until
it is ready, and then merge it back to master.

Would it be helpful if I was to document this?

Peter

-- 
Dr Peter Brett
http://peter-b.co.uk/