Re: [oll-user] Call for initial feedback

[Urs L. <ul...@op...>]

Am 22.03.2013 11:23, schrieb Urs Liska:
> ...
>>      AFAICS it is a working repository, although history isn't all too
>>      nice (e.g. in such a combined repo I would prefix each commit
>>      message with a label (like oll, xmp) which I obviously haven't
>>      done in the past).
>>
>>
>> You should be able to do this now using git filter-branch (of course
>> this will change history, but maybe it's worth it).  Some info for
>> example here:
>> http://mm0hai.net/blog/2011/03/10/rewriting-git-commit-message-history.html
> I'll look into that (and read the "rewriting history" chapter of the
> main book). History rewriting is surely not an issue in this case, as I
> think I can assume the repository sort of private, I can't imagine
> anybody actually has based some work on it yet).
> And if I can manage to make the history look cleaner (as a kind of
> initial state) I'd appreciate it - but only if that doesn't mean I have
> to inspect the 536 commits individually ;-)
Hm, having read the link you provided, "Rewriting History" from ProGit 
and the manual entry for git-filter-branch
I still don't see at all how I could proceed to clean up the history.
Any filter-branch approach would only make sense if I could somehow 
reword the commit message automatically - and I don't see how that 
should be possible.
What probably would be necessary would be a complete interactive rebase 
- which isn't a nice perspective with that number of commits.

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


###########
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.
Branches master and develop are the ones I have created from scratch, 
oldmaster is what the name suggests ;-) and the other branches are 
temporary ones that I use(d) to rip partial branches off oldmaster.
The relation of master and develop is how I intended it (although the 
SourceForge graph displays the chronological relation differently), but 
develop isn't as clean as I would have liked it. Probably it is possible 
to make that better, but either with unreasonable effort or by loosing 
too much detail in the history. Basically develop contains way too many 
intermediate commits that should have been made in feature branches and 
squashed before merging back to develop.
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 ...
Beside the problem of sheer amount of time I have more disturbing 
problems when I encounter rebase conflicts, because I actually don't 
really know if I make damages when resolving them manually - because I 
now don't know anymore which of the conflicting versions is 'better' and 
especially the one leading to the final state. I don't want to think 
about the option that I introduce changes that pass through all later 
merges but cause the final result to be different from what it should be ...


To make that perfectly clear: I DON'T EXPECT ANYBODY TO GO INTO THAT IN 
DETAIL because I know this might take some time. I'd be happy about any 
assistance, but I'm ready to find my way through it on my own.

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'?


Best
Urs

> Best
> Urs
>> best,
>> janek
> -------------- next part --------------
> An HTML attachment was scrubbed...
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> _______________________________________________
> openlilylib-user mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openlilylib-user

-------------- next part --------------
An HTML attachment was scrubbed...