Vincent van Ravesteijn wrote:
>> 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.
And because stable is not going to change its history, there will
be always some boundary in stage from which earlier commits stay
as they are if I understand correctly.
...
To sum up:
>From overall reactions I could see that
- 3 devs asked for staying on SVN way of working until we get more used to git
- 3 devs generally agreed on workflow #2
I don't expect much is going to change in the nearby time, so I would
propose the following:
In case you or some automatic script is responsible for stage->offic
repo merges then normal developer shouldn't recognize that some offic
repo even exist, so we can use since it makes you happy.
As Georg I'm not particularly happy about stage history rewrites,
on the other hand I recognize its your main weapon for the clean
history crusade, the more we want use stage in worflow #2 way, so
lets try it.
Opinions?
In case you agree we could create git usage page with the current structure:
Developer Git Usage
1. Howto get repo for trunk (aka stage); how to get repo for branch.
A. Simple minded scenario (aka SVN)
- for 1&2 in workflow #2
i) howto update (git pull?)
ii) howto commit (git commit && git push?)
B. Feature scenario
- for 2&3 in workflow #2 (some people would prefer do branching even in case
2 and this group will probably increase as get used more to git)
i) branches
ii) branches
iii) branches :)
... (I dont even know how to call these)
Anonymous User/Tester guide -> this section shall be copied to official web as
well
1. Howto get trunk (I guess you mean this would be trunk-stable, not stage?)
Howto get branch
2. Howto update
Pavel
