On 11/29/2014 05:15 PM, Chris Angelico wrote: > On Sun, Nov 30, 2014 at 11:37 AM, Donald Stufft <donald at stufft.io> wrote: >> I also don’t know how to do this. When I’m doing multiple things for CPython >> my “branching” strategy is essentially using hg diff to create a patch file >> with my “branch” name (``hg diff > my-branch.patch``), then revert all of my >> changes (``hg revert —all —no-backup``), then either work on a new “branch” >> or switch to an old “branch” by applying the corresponding patch >> (``patch -p1 < other-branch.patch``). > > IMO, this is missing out on part of the benefit of a DVCS. When your > patches are always done purely on the basis of files, and have to be > managed separately, everything will be manual; and your edits won't > (normally) contain commit messages, authorship headers, date/time > stamps, and all the other things that a commit will normally have. > Using GitHub automatically makes all that available; when someone > forks the project and adds a commit, that commit will exist and have > its full identity, metadata, etc, and if/when it gets merged into > trunk, all that will be carried through automatically. There is no reason to make this `hg diff` dance (but ignorance). - You can make plain commit with your changes. - You can export commit content using `hg export` - You can change you patch content will all kind of tools (amend, rebase, etc) - You can have multiple branches without any issue to handle concurrent workflow. We (Mercurial developer) will be again sprinting at Pycon 2015. We can probably arrange some workflow discussion//training there. -- Pierre-Yves David
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4