geda-developers team mailing list archive

[Markus Hitter <mah@xxxxxxxxxxx>]

Am 30.08.2013 um 14:18 schrieb Peter TB Brett:

> [ Taking this off gEDA-user --> gEDA-developers ]
>
> The idea that one should assume that a git branch's history *doesn't*
> describe the history of that branch is pretty bloody stupid.

Why are you so keen on the history of branches? You don't keep that  
for yourself, either. What matters is the history of the master  
branch, the history of the release branches and the changes, compared  
to master, a development branch brings in.

Merging master into a development branch is obfuscation, just like  
all the commits in a development branch which are unrelated to the  
development target.

> > > 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.
>
> 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;

First, parallel development and parallel histories are two different  
things. You can easily develop in parallel and keep a single history.

Second, the most important advantage of Git over traditional SCMs is  
cherry-picking and rebasing. Git developers came up with virtually  
hundreds of examples on how to use these two to the advantage of  
developing with few conflicts. That's what allows you to develop on  
something new, while following other developments with this new  
thing, too.

Rebasing is also the thing allowing painless merges, if you're still  
keen on merging, because you don't have to wrestle with one big  
change between the branch point and current master, but can rebase  
commit by commit, making neccessary adjustments as small and clear as  
possible.


> 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.

Unless two people work on the very same branch at the very same time,  
they do have the same history.


>   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.

1. One has to actually know these repos. Until just now I wasn't  
aware "pcjc2" exists, and I'm following pcb development for quite a  
while.

2. These repos don't fit the public repo, like you -assumedly- can't  
apply a bunch of commits from there to here. So they're actually a  
distinct project. An interested devloper would end up with something  
like a dozen different pcb installations. With all in one repo,  
changing the version of an installation would be just a checkout &&  
make away.

3. Moving changes between these repos is burdensome, even if Git has  
functions for it. Mapping which repo has which changes quickly  
becomes a mess. In one repo, you simply cherry-pick or rebase.

4. All repos but the central one are disconnected from the bug tracker.

5. Having so many distinct repos is pretty much like asking for  
trouble, because changes here aren't seen there. And non-trivial  
changes almost always have impact on other non-trivial changes. Like  
this outline handling, for example, which has changed in the main  
repo, too.

> Would it make you happier if we started hosting personal git repos  
> on geda-project.org?

This would solve 1. at best. If you could simply move your work as a  
branch into the main repo, other developers would see a lot more,  
could pick up details, the public would see there are people actually  
working on pcb, ... many many reasons to use the central repo.


> 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.

Somehow I get the impression you can't distinguish between rebasing  
development branches and rewriting history. If you rebase a branch,  
you don't change history of the master branch or any other branch at  
all! Accordingly there's zero reason to keep experimental code hidden  
in distinct repos. Accordingly you're well advised to rebase a branch  
to master before cherry-picking -make bisecting easier - or merging  
it -the apparently usual strategy for some pcb developers- over to  
master.

> Would it be helpful if I was to document this?

Sorry, no. Your propsed/practiced strategy doesn't work. Other than  
bug fixing branches -which get rebased-, only miniscule changes over  
the last year in the main repo, tons of valueable code untouched and  
unseen in some hidden places, many people in the public consider pcb  
to be dead or unmaintained. We need a strategy with less maintenance  
costs, actually working collaboration and most important, more  
visibility.


Cheers,
Markus

- - - - - - - - - - - - - - - - - - -
Dipl. Ing. (FH) Markus Hitter
http://www.jump-ing.de/