When we're working on various changes, it's typical to include pull request
for discrete commits for each; yet, creating separate forks and cloning said
forks to our local machines is really a drain on disk space. Or are we
expected to batch up a bunch of commits in a pull request that may or may
not be related? The problem is that until the pull request is committed to
the master repo, we basically either need to wait (if building on those
changes), create a new fork and clone, or stash changes and deal with the
merge later.
I admit I'm much more familiar with Git than Hg, but I really haven't seen
how this is supposed to work in Hg:
1. git checkout -b fix1
2. (edit)
3. git commit -a -m "Fix #1"
4. git push origin fix1:fix1
5. git checkout -b fix2 develop
6. (edit)
7. git commit -a -m "Fix #2"
8. git push origin fix2:fix2
9. (send separate pull requests for fix1 and fix2)
10. If a change is needed in fix1, checkout that branch, commit the fix,
push, and resend the pull request.
Branches in Hg are heavyweight and results in a larger repo (or multiple
repos) than lightweight branches in Git. Lightweight branches are just
pointers to different commit trees so it's easy to branch code, push, and
send pull requests for discreet changes (or sets of changes).
Heath Stewart
VS Pro Deployment Experience, Microsoft
<http://blogs.msdn.com/heaths> http://blogs.msdn.com/heaths
------------------------------------------------------------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
endpoint security space. For insight on selecting the right partner to
tackle endpoint security challenges, access the full report.
http://p.sf.net/sfu/symantec-dev2dev
_______________________________________________
WiX-devs mailing list
WiX-devs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-devs
