Re: [oll-user] Call for initial feedback

[Janek W. <lem...@gm...>]

2013/3/23 Urs Liska <ul...@op...>

> On the other hand, I'm quite tempted to redesign the history from
> scratch because it is really quite messy IMO (partly because of the fact
> that it's a merged history (there are three 'initial commits' for
> example) and partly because of me only learning all this stuff. And if I
> did that it would probably reduce the number of commits through numerous
> squashes anyway.
>

I know that temptation.
https://github.com/janek-warchol/eja-mater-demonstration is an example of
possible results.  Was it worth it?  Well, only if it'll be used for
analyzing LilyPond performance (another Report article maybe) and/or
demonstrating lily+git workflow to potential "employers".


> What I would like to have (after reading several documents with
> work-flow suggestions) would be:
> - a master branch which only has 'stable' commits, e.g. one commit for
> each tag,
> - a develop branch which also only has stable commits, but more, i.e.
> one commit for each completed feature branch, sth like
>
> master
>    develop
> *    release OLLib v0.2
> |\
> | * oll: add \displayControlPoints
> | * oll: add someFeature
> * |  release Tutorial Gervasoni
> |\
> | * tut: finish tutorial Gervasoni
> | * xmp: fix #11 - odd/even-sided examples
> | * tut:
>

looks nice.


> ###########
> One day later:
> ###########
>
> Yesterday I started such a redesign (after making a copy with git clone
> of course - I have put quite some effort in the existing state, and I
> won't start the merge from the beginning again ...).
> And it seems to work basically, but (and that's a big but) it seems to
> mean that I have to effectively review each single commit, and the
> perspective is quite discouraging.
> If you want to have a look at the current state, you may go to
> http://sourceforge.net/p/openlilylib/rebase-repo/ and browse commits
> there or clone into it.
>

I get a 404 error "We're sorry but we weren't able to process this request"


> I _could_ proceed that way, but I have the impression this would take me
> about a week, and I'm not sure if that's worth it. Although I assume
> (hope) this repo will live for years ...
>

I don't know if it's not too late for such advice, but i'd advise not to do
this.  I think that most projects have a messy history at the beginning,
and anyway if everything will be ok we hope that browsing very old history
won't be necessary.

>
> Maybe a few final questions that can be answered with a plain opinion
> statement:
>
>   * If you look at the history in
>     http://sourceforge.net/p/openlilylib/rebase-repo/commit_browser (the
>     upper part down to the first "initial commit"), would you think
>     that's good design? Or could I go this way but squash the commits in
>     'develop' more radically, i.e. leaving only commits like 'add
>     commands', 'update manual' or 'fix several bugs'
>   * Or if you look at the history in
>     http://sourceforge.net/p/openlilylib/mergerepos/commit_browser (the
>     state after merging the repos: Would it be acceptable (i.e. the
>     better way because it is considerably easier) to leave that history
>     as it is (towards the end it is quite linear actually) and only
>     start to adhere to the strategy described above from now on. I.e.
>     consider the history up to now as the somewhat messy and voluminous
>     'initial state'?
>

These two also return 404 errors, so i assume i'm too late.  Sorry :(
Janek
-------------- next part --------------
An HTML attachment was scrubbed...