On Fri, Jul 22, 2016 at 12:38:44PM -0400, myglc2 wrote:
l...@gnu.org (Ludovic Courtès) writes:Hi Roel, Roel Janssen <r...@gnu.org> skribis:[...]One thing that really helped me in reducing the time to contribute changes to the upstream distribution, is to have a good workflow. I ended up doing the following: 1. Make the changes. 2. Commit the changes. 3 git format-patch -1 --no-attach 4. git reset --hard <latest commit on origin/master> 5. Submit the patch to the mailing list 6. Wait for response and probably go back to 1. I made all of my changes on a GNU Guix git checkout. So, not writing package definitions on a separate repository.Do you think it would help to add this as a section in the manual?This is a great idea!
This reminds me: https://cdn.meme.am/instances/500x/69604641.jpg I ended with using topic branches or queues instead, all on top of master. wip - not yet finished changes review - sent to ML and waiting for review lvm, kernel, ... - branches with some topic changes cherry-picking from wip to review and sending from there as described above. `git pull --rebase' will identify when they have been merged. S_W
signature.asc
Description: Digital signature
