Re: Patch mgmt workflow proposal

2011-08-02 Thread martin f krafft
also sprach Ben Finney bignose+hates-s...@benfinney.id.au [2011.08.02.0223 +0200]: This comes about ¾ of the way to the history pollution done by TopGit. I consider it very useful information, when needed. It's only pollution if you let it be so. That is a very wise statement, and I agree.

Re: Patch mgmt workflow proposal

2011-08-02 Thread martin f krafft
also sprach Ben Finney bignose+hates-s...@benfinney.id.au [2011.08.02.0229 +0200]: 1. you develop your features on branches, but you do not push the branch heads; Right. The feature branches stay only with the people who are interested; usually the people actually working on each

Re: Patch mgmt workflow proposal

2011-08-02 Thread Thomas Koch
Thomas Koch: I had some time on my way back to think about patch bases. Is it right, that it isn't actually necessary to save the commit sha-1s of patch bases? It is my understanding that you could calculate them: 1. $CANDIDATE=$(git merge-base --octopus $DEPENDENCY_NAMES) 2. for each

Re: Patch mgmt workflow proposal

2011-08-02 Thread martin f krafft
also sprach Thomas Koch tho...@koch.ro [2011.08.02.1732 +0200]: the above algorithm is completly wrong, written in a hurry. The idea however was to merge all dependencies in a commit and to merge this commit in the patch branch. This is exactly what TopGit does: a top-base is the merge of a