Op 15-3-2012 10:57, Pavel Sanda schreef:
Vincent van Ravesteijn wrote:
Fine. If I understand correctly the shift "stage"->"devel" stable can help
you to rewrite history (e.g. by merging fix of fix commits). So then we
would have 2 incompatible histories in two repos.
No, the staging repo has no own fixed history.
So if I commit fix for bug 1234 in stage and put changeset:xxxx pointer into
trac there is no guarantee I find it again?
Yes. If the commit-id changes later on, this must mean that the commit
has been corrected and thus you'd have to update trac anyway (also in
svn). I guess you don't want to point at a faulty commit.
There are other options as well. We can add a line in the commit log or
use 'git notes' to indicate which bug is fixed by a commit. For example:
git notes add -m 'trac:#1234'
When merging with the stable lyx repo, we could automatically add a note
to the bug report using a post-***-hook.
Now, you plan to to replace "stage" after main release by "devel" tree and
start from there again development, now with clearer history? What commit
checksum is primary for the pruposes of trac for example then?
Whenever a feature gets into the official repo, it will not change anymore,
and the sha1 will be definite.
So your plan is to play with stage history (eg merge commits) and from time
to time push such repaired history into official? From that time no changes
will be done to those commits in stage as well?
Yes, the staging repo will always be based on the stable repo.
Statistics on the commits to the master repo:
1 whitespace change
3 commits that fix a previous commit/series
2 commits that duplicate changes from 2.0.x branch
2 commits with bug fixes that could use some correction
Vincent
