What if you maintained two branches in your fork.
One for your changes against the snapshot from two weeks back and one
which you regularly merge the trunk/master and your own changes to
test for compatibility. Then when it comes time for review they can
look at both branches separately?
---
Dylan Jay
Technical Solutions Manager
PretaWeb: reducing duplication in the government web.
P: +612 80819071 | M: +61421477460 | twitter.com/djay75 | linkedin.com/
in/djay75
On 11/05/2011, at 11:29 AM, Erik de Castro Lopo wrote:
Hi all,
I am not a newcomer to revision control (currently use bzr, darcs
and svn regularly, started using DVCSs with GNU Arch in 2004) but
I'm still having trouble coming to grips with git and github.
On github, I have forked a repo and then cloned it locally. I am
now setting out to add a feature to this project. This is going
to take me a while and upstream is changing quite rapidly so I'm
going to need to constantly pull in upstream changes.
When I'm done adding my feature, I'd like to send the upstream
maintainer a clean github merge request. In particular, I would
prefer that it doesn't contain two weeks worth of daily 'merge
from upstream' commits.
Yes, there is acres of git documentation out there but although
I've spent 10 times as much time reading git documentation as I
have reading either bzr or darcs documentation, I still find bzr
and darcs an order of magnitude easier to use.
A simple recipe of how to do this without burning my fingers
would be appreciated.
Cheers,
Erik
--
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/
_______________________________________________
coders mailing list
coders@slug.org.au
http://lists.slug.org.au/listinfo/coders
_______________________________________________
coders mailing list
coders@slug.org.au
http://lists.slug.org.au/listinfo/coders
