Hi Mike, On Tue, Nov 29, 2011 at 3:01 PM, Mike Frysinger <vap...@gentoo.org> wrote: > On Monday 28 November 2011 22:35:24 Graeme Russ wrote: >> On Tue, Nov 29, 2011 at 2:31 PM, Mike Frysinger wrote: >> > the expected behavior of downstream users is apparently to always >> > fetch+rebase rather than fetch+merge (what "pull" normally does). this >> > is pretty unusual (and in most git circles, unforgivable as the >> > "default" workflow). but as i'm >> >> OK, so what would be a more acceptable workflow? > > never rebase anything you want other people to be working off of :). the > downside is that any commit you've published cannot be modified.
I don't see this as a downside - I always wanted to simply: - Sync u-boot-x86/master with u-boot/master - Apply patches which a 'good to go' - Send a pull request I've never (intentionally) wanted to meddle with the history of u-boot-x86 (neither master or next) - I did it once deliberately to tweak a commit message that I messed up and I have to do it now that I've fouled it up > one way around this is to have three branches: > - one that tracks mainline, and you only add stuff when you're going to send > a > pull request to Wolfgang > - one that keeps all your "clean" patches and gets rewritten constantly (and > needs --force to publish) > - one that gets all the incremental fixes that people can pull from and > always > have a consistent history, and gets merge commits > > it's more work to be sure, so it's up to you how you want to develop It's not so much how I want to 'develop' but how a want to 'maintain' u-boot-x86. My development is done using stacked git on development branches (I'm even considering using an entirely independent local git repo 'just in case') With respect to u-boot-x86 - I simply want to keep it up-to-date with mainline and 'git am' patches I've saved from patchwork So how do I do this - Sorry, but I'm just not getting it - To me, it looks like your assuming I want to stick to my existing (flawed) workflow. I actually want to go back to square one and 'get it right' >> And just quickly back to the problem at hand - How do I fix the 'duplicate >> commits' problem I already have? > > you can either use the --force flag to push your rewritten history (in which > case everyone downstream from you also needs to rewrite their history), or fix > your history locally before pushing the update: > - fetch *your* current remote master, *not* Wolfgang's master > - normally your repo is listed as "origin" ... but you'd have to read > .git/config to find out exactly what it is ... > - save any patches you care about (git format-patch/etc...) > - reset your local master to your current remote master > $ git checkout master > $ git reset --hard origin/master I don't think this will work - The remote master (i.e. u-boot-x86/master on the denx server) has the duplicate commits already... > - apply any new changes you wanted to publish > $ git cherry-pick <sha1> > $ git am -3 *.patch > ...whatever... > - push out your new local master branch that only has new changes compared to > the already published version I think I need to, as I had in my earlier post: $ git reset --hard <parent of first duplicat commit> $ git push (using --force) At this point, I want to sync the remote u-boot-x86/master to mainline, apply the dozen or so patches and push back into the remote u-boot-x86/master But I'm getting lost around the whole 'how do I keep u-boot-x86/master in sync with u-boot/master' and I'm beginning to think the answer is closer to 'you don't - there's git magic which does wonderful things that I as a mere mortal do not need to know' ;) Regards, Graeme _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
