| Message ID | CALButCJ6+F3DwinMWzU+HJkxNP9J+Mnas_133wZQa4AnJz5SWA@mail.gmail.com |
|---|---|
| State | Not Applicable |
| Headers | show |
On Monday 28 November 2011 17:31:19 Graeme Russ wrote: > error: refs/tags/2009.01-rc2 does not point to a valid object! this tag seems to have bled into some people's repos ... i'd suggest you punt it locally: git tag -d 2009.01-rc2 and then punt it remotely: git push <remote_uri> :2009.01-rc2 > $ git fetch u-boot > ... > $ git rebase u-boot/master > ... > $ git push ssh://gu-x86@git.denx.de/u-boot-x86 > ... > To ssh://gu-x86@git.denx.de/u-boot-x86 > ! [rejected] master -> master (non-fast-forward) well, you did a rebase, so this is kind of par for the course. use --force to rewrite the published branch. -mike
Hi Mike, On Tue, Nov 29, 2011 at 10:02 AM, Mike Frysinger <vapier@gentoo.org> wrote: > On Monday 28 November 2011 17:31:19 Graeme Russ wrote: >> error: refs/tags/2009.01-rc2 does not point to a valid object! > > this tag seems to have bled into some people's repos ... i'd suggest you punt > it locally: > git tag -d 2009.01-rc2 > and then punt it remotely: > git push <remote_uri> :2009.01-rc2 Ah, thanks > >> $ git fetch u-boot >> ... >> $ git rebase u-boot/master >> ... >> $ git push ssh://gu-x86@git.denx.de/u-boot-x86 >> ... >> To ssh://gu-x86@git.denx.de/u-boot-x86 >> ! [rejected] master -> master (non-fast-forward) > > well, you did a rebase, so this is kind of par for the course. use --force to > rewrite the published branch. So how do you keep the sub-repo up-to-date with u-boot/master without doing forced pushes? Regards, Graeme
On Monday 28 November 2011 18:05:00 Graeme Russ wrote: > On Tue, Nov 29, 2011 at 10:02 AM, Mike Frysinger wrote: > > On Monday 28 November 2011 17:31:19 Graeme Russ wrote: > >> $ git fetch u-boot > >> ... > >> $ git rebase u-boot/master > >> ... > >> $ git push ssh://gu-x86@git.denx.de/u-boot-x86 > >> ... > >> To ssh://gu-x86@git.denx.de/u-boot-x86 > >> ! [rejected] master -> master (non-fast-forward) > > > > well, you did a rebase, so this is kind of par for the course. use > > --force to rewrite the published branch. > > So how do you keep the sub-repo up-to-date with u-boot/master without > doing forced pushes? you don't :). the way *i* work is to keep my changes in my own branch that i rewrite, and then once i want to send that to Wolfgang, i publish the updated master branch for him to pull from. i think the u-boot wiki has a "suggested maintainer workflow", but i haven't looked too hard at that as i like (logically) how i do things now. -mike
On Mon, Nov 28, 2011 at 5:13 PM, Mike Frysinger <vapier@gentoo.org> wrote: > On Monday 28 November 2011 18:05:00 Graeme Russ wrote: >> On Tue, Nov 29, 2011 at 10:02 AM, Mike Frysinger wrote: >> > On Monday 28 November 2011 17:31:19 Graeme Russ wrote: >> >> $ git fetch u-boot >> >> ... >> >> $ git rebase u-boot/master >> >> ... >> >> $ git push ssh://gu-x86@git.denx.de/u-boot-x86 >> >> ... >> >> To ssh://gu-x86@git.denx.de/u-boot-x86 >> >> ! [rejected] master -> master (non-fast-forward) >> > >> > well, you did a rebase, so this is kind of par for the course. use >> > --force to rewrite the published branch. >> >> So how do you keep the sub-repo up-to-date with u-boot/master without >> doing forced pushes? > > you don't :). the way *i* work is to keep my changes in my own branch that i > rewrite, and then once i want to send that to Wolfgang, i publish the updated > master branch for him to pull from. > > i think the u-boot wiki has a "suggested maintainer workflow", but i haven't > looked too hard at that as i like (logically) how i do things now. Yes, I only push up changes that I don't intend will ever be changed. Unless I forget. If your tree contains changes that aren't yet in Wolfgang's tree, but *are* published in your upstream tree, then you can try: git merge u-boot/master. It should work, as long as your patches can still be pulled into his tree, cleanly. Andy
On Tue, Nov 29, 2011 at 10:16 AM, Andy Fleming <afleming@gmail.com> wrote: > On Mon, Nov 28, 2011 at 5:13 PM, Mike Frysinger <vapier@gentoo.org> wrote: >> On Monday 28 November 2011 18:05:00 Graeme Russ wrote: >>> On Tue, Nov 29, 2011 at 10:02 AM, Mike Frysinger wrote: >>> > On Monday 28 November 2011 17:31:19 Graeme Russ wrote: >>> >> $ git fetch u-boot >>> >> ... >>> >> $ git rebase u-boot/master >>> >> ... >>> >> $ git push ssh://gu-x86@git.denx.de/u-boot-x86 >>> >> ... >>> >> To ssh://gu-x86@git.denx.de/u-boot-x86 >>> >> ! [rejected] master -> master (non-fast-forward) >>> > >>> > well, you did a rebase, so this is kind of par for the course. use >>> > --force to rewrite the published branch. >>> >>> So how do you keep the sub-repo up-to-date with u-boot/master without >>> doing forced pushes? >> >> you don't :). the way *i* work is to keep my changes in my own branch that i >> rewrite, and then once i want to send that to Wolfgang, i publish the updated >> master branch for him to pull from. >> >> i think the u-boot wiki has a "suggested maintainer workflow", but i haven't >> looked too hard at that as i like (logically) how i do things now. > > Yes, I only push up changes that I don't intend will ever be changed. Well, that is my intent too :) > Unless I forget. > > If your tree contains changes that aren't yet in Wolfgang's tree, but > *are* published in your upstream tree, then you can try: > > git merge u-boot/master. So is that in lieu of rebase? > It should work, as long as your patches can still be pulled into his > tree, cleanly. Well they should (this time) - They are all very isolated to x86, and nobody else has touch that recently Regards, Graeme
On Monday 28 November 2011 18:20:51 Graeme Russ wrote: > On Tue, Nov 29, 2011 at 10:16 AM, Andy Fleming wrote: > > On Mon, Nov 28, 2011 at 5:13 PM, Mike Frysinger wrote: > >> On Monday 28 November 2011 18:05:00 Graeme Russ wrote: > >>> On Tue, Nov 29, 2011 at 10:02 AM, Mike Frysinger wrote: > >>> > On Monday 28 November 2011 17:31:19 Graeme Russ wrote: > >>> >> $ git fetch u-boot > >>> >> ... > >>> >> $ git rebase u-boot/master > >>> >> ... > >>> >> $ git push ssh://gu-x86@git.denx.de/u-boot-x86 > >>> >> ... > >>> >> To ssh://gu-x86@git.denx.de/u-boot-x86 > >>> >> ! [rejected] master -> master (non-fast-forward) > >>> > > >>> > well, you did a rebase, so this is kind of par for the course. use > >>> > --force to rewrite the published branch. > >>> > >>> So how do you keep the sub-repo up-to-date with u-boot/master without > >>> doing forced pushes? > >> > >> you don't :). the way *i* work is to keep my changes in my own branch > >> that i rewrite, and then once i want to send that to Wolfgang, i > >> publish the updated master branch for him to pull from. > >> > >> i think the u-boot wiki has a "suggested maintainer workflow", but i > >> haven't looked too hard at that as i like (logically) how i do things > >> now. > > > > Yes, I only push up changes that I don't intend will ever be changed. > > Well, that is my intent too :) you can never rebase+publish that branch then > > Unless I forget. > > > > If your tree contains changes that aren't yet in Wolfgang's tree, but > > *are* published in your upstream tree, then you can try: > > > > git merge u-boot/master. > > So is that in lieu of rebase? yes, if you want to get updates from mainline before asking Wolfgang to do a pull request on your branch note: you don't have to publish the merge/rebasing work. let's say you have 3 patches in your x86 master (published). locally, you get Wolfgang's updated master, verify things still work, and then send a pull request for the already published branch (not for your local work which includes a merge commit). once Wolfgang pulls & pushes that update, you can fetch Wolfgang's master and then rebase on top of that. in this case, the only thing being thrown away is your local merge commits because Wolfgang included your other changes. this can be a bit confusing as it delves deeply into distributed scm subtleties, so if you want, i can clarify points from above ... -mike
Hi Mike, On Tue, Nov 29, 2011 at 10:43 AM, Mike Frysinger <vapier@gentoo.org> wrote: > On Monday 28 November 2011 18:20:51 Graeme Russ wrote: >> On Tue, Nov 29, 2011 at 10:16 AM, Andy Fleming wrote: >> > On Mon, Nov 28, 2011 at 5:13 PM, Mike Frysinger wrote: >> >> On Monday 28 November 2011 18:05:00 Graeme Russ wrote: >> >>> On Tue, Nov 29, 2011 at 10:02 AM, Mike Frysinger wrote: >> >>> > On Monday 28 November 2011 17:31:19 Graeme Russ wrote: >> >>> >> $ git fetch u-boot >> >>> >> ... >> >>> >> $ git rebase u-boot/master >> >>> >> ... >> >>> >> $ git push ssh://gu-x86@git.denx.de/u-boot-x86 >> >>> >> ... >> >>> >> To ssh://gu-x86@git.denx.de/u-boot-x86 >> >>> >> ! [rejected] master -> master (non-fast-forward) >> >>> > >> >>> > well, you did a rebase, so this is kind of par for the course. use >> >>> > --force to rewrite the published branch. >> >>> >> >>> So how do you keep the sub-repo up-to-date with u-boot/master without >> >>> doing forced pushes? >> >> >> >> you don't :). the way *i* work is to keep my changes in my own branch >> >> that i rewrite, and then once i want to send that to Wolfgang, i >> >> publish the updated master branch for him to pull from. >> >> >> >> i think the u-boot wiki has a "suggested maintainer workflow", but i >> >> haven't looked too hard at that as i like (logically) how i do things >> >> now. >> > >> > Yes, I only push up changes that I don't intend will ever be changed. >> >> Well, that is my intent too :) > > you can never rebase+publish that branch then > >> > Unless I forget. >> > >> > If your tree contains changes that aren't yet in Wolfgang's tree, but >> > *are* published in your upstream tree, then you can try: >> > >> > git merge u-boot/master. >> >> So is that in lieu of rebase? > > yes, if you want to get updates from mainline before asking Wolfgang to do a > pull request on your branch > > note: you don't have to publish the merge/rebasing work. let's say you have 3 > patches in your x86 master (published). locally, you get Wolfgang's updated > master, verify things still work, and then send a pull request for the already > published branch (not for your local work which includes a merge commit). > once Wolfgang pulls & pushes that update, you can fetch Wolfgang's master and > then rebase on top of that. in this case, the only thing being thrown away is > your local merge commits because Wolfgang included your other changes. > > this can be a bit confusing as it delves deeply into distributed scm You are correct - I am totally confused by all of this :( > subtleties, so if you want, i can clarify points from above ... Yes, that would be nice :) I think a few concrete examples with git commands to illustrate would be helpful. What I am thinking of doing is something along the lines of: > cd Source/U-Boot/x86 (my local version of the u-boot-x86 repo) > git fetch u-boot (as per the 'new' methodology of not having a seperate u-boot branch) > git checkout master > git rebase u-boot/master > git push ssh://gu-x86@git.denx.de/u-boot-x86 > git checkout next > git rebase master > git push ssh://gu-x86@git.denx.de/u-boot-x86 Do the above periodically so anyone working off u-boot-x86 can keep up-to-date And when I'm happy with a patchwork patch, do the above and then: > git am <patches downloaded from patchwork only> > git push ssh://gu-x86@git.denx.de/u-boot-x86 My local u-boot-x86/master branch will only ever contains patches that are ready to be pulled by Wolfgang And for my day-to-day development: > git checkout dev > git rebase master > stg new/pop/push/delete/squash etc... My local u-boot-x86/dev branch has lots of rubbish - usually an stg stack a mile long of various experimental stuff - I actually have multiple dev branches. I like to pull the patches ready for upstreaming into those branches first just to see what I am up against when the new patches go live. But this seems to cause the 'must force the push' problem... Regards, Graeme
On Monday 28 November 2011 19:02:20 Graeme Russ wrote: > > cd Source/U-Boot/x86 (my local version of the u-boot-x86 repo) > > git fetch u-boot (as per the 'new' methodology of not having a seperate > > u-boot branch) > > git checkout master > > git rebase u-boot/master > > git push ssh://gu-x86@git.denx.de/u-boot-x86 > > git checkout next > > git rebase master > > git push ssh://gu-x86@git.denx.de/u-boot-x86 ok, i've read the official recommended workflow [1]. it seems to contradict itself. for example, it starts with: Philosophy of custodian trees ... it is the custodian's responsibility to provide a permanently accessible, consistent view of his repository to users. i read that as saying "no rewriting of published history". but later on it says to do just that: Tips for maintaining custodian trees - Keep in sync with the upstream repository by pulling it. - Rebase the master, testing and any "work in progress" branches to the ${upstream}/master remote branch. - Push the appropriate branch(es) to the denx.de repo: - Pushing the testing and/or rebased master branches often requires the -f force flag. This is because the state/content/order of the patches in the branch changed due to the rebase operations. so i guess your example workflow is fine, you just need to use the --force flag. and you should specify the branches to push rather than leaving that to be implicit. so change: git push ssh://gu-x86@git.denx.de/u-boot-x86 to: git push --force ssh://gu-x86@git.denx.de/u-boot-x86 next git push --force ssh://gu-x86@git.denx.de/u-boot-x86 master > Do the above periodically so anyone working off u-boot-x86 can keep > up-to-date 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 not a consumer of any of these trees except Wolfgang's, i'm not going to argue over it. so your x86 users have to do (assuming they've cloned your tree): git fetch git rebase origin/master instead of the more normal: git pull -mike [1] http://www.denx.de/wiki/U-Boot/CustodianGitTrees
Hi Mike, On Tue, Nov 29, 2011 at 2:31 PM, Mike Frysinger <vapier@gentoo.org> wrote: > On Monday 28 November 2011 19:02:20 Graeme Russ wrote: >> > cd Source/U-Boot/x86 (my local version of the u-boot-x86 repo) >> > git fetch u-boot (as per the 'new' methodology of not having a seperate >> > u-boot branch) >> > git checkout master >> > git rebase u-boot/master >> > git push ssh://gu-x86@git.denx.de/u-boot-x86 >> > git checkout next >> > git rebase master >> > git push ssh://gu-x86@git.denx.de/u-boot-x86 > > ok, i've read the official recommended workflow [1]. it seems to contradict > itself. for example, it starts with: > Philosophy of custodian trees > ... it is the custodian's responsibility to provide a permanently > accessible, consistent view of his repository to users. > > i read that as saying "no rewriting of published history". but later on it > says to do just that: > Tips for maintaining custodian trees > - Keep in sync with the upstream repository by pulling it. > - Rebase the master, testing and any "work in progress" branches to the > ${upstream}/master remote branch. > - Push the appropriate branch(es) to the denx.de repo: > - Pushing the testing and/or rebased master branches often requires > the -f force flag. This is because the state/content/order of the > patches in the branch changed due to the rebase operations. > > so i guess your example workflow is fine, you just need to use the --force flag. > and you should specify the branches to push rather than leaving that to be > implicit. so change: > git push ssh://gu-x86@git.denx.de/u-boot-x86 > to: > git push --force ssh://gu-x86@git.denx.de/u-boot-x86 next > git push --force ssh://gu-x86@git.denx.de/u-boot-x86 master > >> Do the above periodically so anyone working off u-boot-x86 can keep >> up-to-date > > 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? > not a consumer of any of these trees except Wolfgang's, i'm not going to argue > over it. so your x86 users have to do (assuming they've cloned your tree): > git fetch > git rebase origin/master > > instead of the more normal: > git pull Ah, actually I think git pull is preferable... And just quickly back to the problem at hand - How do I fix the 'duplicate commits' problem I already have? Regards, Graeme
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. 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 > 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 - 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 -mike
Hi Mike, On Tue, Nov 29, 2011 at 3:01 PM, Mike Frysinger <vapier@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
On Monday 28 November 2011 23:17:47 Graeme Russ wrote: > My development is done using stacked git on development branches (I'm even > considering using an entirely independent local git repo 'just in case') that's fine. it's just a matter of how often you want to publish patches to the wider world. i publish all my bleeding edge stuff, but it's in a "next" style branch. > 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' for the published branch, you'll have to have merge commits in it. some people don't want any merge commits (keep everything linear), while others don't think really any are bad. i'm kind of in between ... i don't mind merging of "good" branches. any ways, if you want to publish your local changes with Wolfgang's latest changes without having Wolfgang pull it first, then you'd do: $ git checkout master $ git fetch <upstream uri> $ git merge u-boot/master $ git push <x86 uri> master you shouldn't do this too often though otherwise you'll get a whole lot of merge commits cluttering up your history. look at Wolfgang's tree starting around commit f9342e2c3e81d62. that's fine for Wolfgang (since he's merging many trees), but imo, custodian trees shouldn't be gathering merge commits which are then sent to Wolfgang for merging. i'd draw some ascii diagrams of the commit history, but i'm not sure it would help. instead, run `gitk` and look at the tree on the left around the merge commits. hopefully that'll clear things up. > > - 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... oh, you've already published the bum history ? i thought it was only local. then you'll have to do: $ git checkout master $ git rebase u-boot/master $ git push --force <remote uri> master -mike
Hi Mike, On Tue, Nov 29, 2011 at 3:49 PM, Mike Frysinger <vapier@gentoo.org> wrote: > On Monday 28 November 2011 23:17:47 Graeme Russ wrote: >> My development is done using stacked git on development branches (I'm even >> considering using an entirely independent local git repo 'just in case') > > that's fine. it's just a matter of how often you want to publish patches to > the wider world. i publish all my bleeding edge stuff, but it's in a "next" > style branch. > >> 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' > > for the published branch, you'll have to have merge commits in it. some > people don't want any merge commits (keep everything linear), while others > don't think really any are bad. i'm kind of in between ... i don't mind > merging of "good" branches. > > any ways, if you want to publish your local changes with Wolfgang's latest > changes without having Wolfgang pull it first, then you'd do: > $ git checkout master > $ git fetch <upstream uri> > $ git merge u-boot/master > $ git push <x86 uri> master > you shouldn't do this too often though otherwise you'll get a whole lot of > merge commits cluttering up your history. look at Wolfgang's tree starting > around commit f9342e2c3e81d62. that's fine for Wolfgang (since he's merging > many trees), but imo, custodian trees shouldn't be gathering merge commits > which are then sent to Wolfgang for merging. Ah, now I get it - Perhaps the wiki should be changed (it has a rebase instead of a merge). And I think this is where it all went pear-shaped for me - I had been rebasing, but then I threw a merge into the mix I think I need to do some reading up on 'rebase' versus 'merge' in git So then the question becomes - what about developers doing x86 work - I may have patches published in u-boot-x86/master which have not been pulled by Wolfgang, but u-boot/master may also contain patches that are needed Can you merge a local repo with multiple remotes? So could developer 'x': $ git checkout local_dev_branch_for_feature_x $ git fetch u-boot $ git fetch u-boot-x86 $ git merge u-boot/master $ git merge u-boot-x86/master $ code...code...code $ git format-patch $ git send-email > i'd draw some ascii diagrams of the commit history, but i'm not sure it would > help. instead, run `gitk` and look at the tree on the left around the merge > commits. hopefully that'll clear things up. > >> > - 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... > > oh, you've already published the bum history ? i thought it was only local. > then you'll have to do: > $ git checkout master > $ git rebase u-boot/master > $ git push --force <remote uri> master Hmm, I don't think this will, in and of itself, help - The duplicate commits are all local to u-boot-x86/master (they are all x86 patches, not u-boot patches) but I'll give it a go first... Failing that: $ git checkout master $ git reset --hard <parent of initial instance of first duplicate commit> $ git push --force <remote uri> master $ git fetch u-boot $ git merge u-boot/master $ git am <patchwork patches> $ git push <remote uri> master Regards, Graeme
Ignoring most of the context for the moment, I think fixing your problem requires: Start in your current, broken branch: 1) git branch save_broken_branch #just in case 2) git rebase -i u-boot/master Interactive rebase will show you a long list of commits that aren't yet in the mainline, even the duplicates. Delete all the commits which are duplicates. Hopefully, it completes without conflicts. 3) git diff save_broken_branch..HEAD # Should return nothing Hope this helps. If there is a difference, then there's a chance that somehow the merging ran into issues which it resolved in odd ways. It's possible some of those commits are empty? Try git log -p to see what's actually in all of those commits. Andy
On Tuesday 29 November 2011 00:04:12 Graeme Russ wrote: > I think I need to do some reading up on 'rebase' versus 'merge' in git rebase: rewrites the history by taking all of your local changes and placing them on top of the commit you've specified. this ultimately produces a much more linear and "clean" history for people to review, but can lose information (the exact code base a patch was written against) and be hard to work with downstream. merge: stitches together two related trees that have diverged. adds a "merge commit" to the point where the two histories get stitched together. things are not linear at all :). > So then the question becomes - what about developers doing x86 work - I > may have patches published in u-boot-x86/master which have not been pulled > by Wolfgang, but u-boot/master may also contain patches that are needed if that's the case, then i think doing a merge with Wolfgang's is acceptable if you don't just want to have Wolfgang pull your tree as is > Can you merge a local repo with multiple remotes? So could developer 'x': certainly. that's the great thing about git -- every single git repo is on "equal" footing in terms of what can be done regardless of who it is (you, me, Wolfgang, random-person-who-has-never-posted-to-the-u-boot-list). the *only* thing preventing changes being published on denx.de are ssh credentials. > > then you'll have to do: > > $ git checkout master > > $ git rebase u-boot/master > > $ git push --force <remote uri> master > > Hmm, I don't think this will, in and of itself, help - The duplicate > commits are all local to u-boot-x86/master (they are all x86 patches, not > u-boot patches) but I'll give it a go first... rebase should automatically discard changesets that are empty/already applied. if it doesn't, use the interactive flag: $ git rebase -i u-boot/master then delete any duplicate lines in the text file that pops up -mike
On 29/11/11 10:02, Mike Frysinger wrote: > On Monday 28 November 2011 17:31:19 Graeme Russ wrote: >> error: refs/tags/2009.01-rc2 does not point to a valid object! > > this tag seems to have bled into some people's repos ... i'd suggest you punt > it locally: > git tag -d 2009.01-rc2 > and then punt it remotely: > git push <remote_uri> :2009.01-rc2 > graeme@helios:~/Source/U-Boot/x86$ git tag -d 2009.01-rc2 error: tag '2009.01-rc2' not found. graeme@helios:~/Source/U-Boot/x86$ git push ssh://gu-x86@git.denx.de/u-boot-x86/master :2009.01-rc2 error: refs/tags/2009.01-rc2 does not point to a valid object! error: unable to push to unqualified destination: 2009.01-rc2 The destination refspec neither matches an existing ref on the remote nor begins with refs/, and we are unable to guess a prefix based on the source ref. error: failed to push some refs to 'ssh://gu-x86@git.denx.de/u-boot-x86/master' Expected? Regards, Graeme
On 29/11/11 16:36, Mike Frysinger wrote: > On Tuesday 29 November 2011 00:04:12 Graeme Russ wrote: >> I think I need to do some reading up on 'rebase' versus 'merge' in git [snip] >>> then you'll have to do: >>> $ git checkout master >>> $ git rebase u-boot/master >>> $ git push --force <remote uri> master >> >> Hmm, I don't think this will, in and of itself, help - The duplicate >> commits are all local to u-boot-x86/master (they are all x86 patches, not >> u-boot patches) but I'll give it a go first... > > rebase should automatically discard changesets that are empty/already applied. > if it doesn't, use the interactive flag: > $ git rebase -i u-boot/master > then delete any duplicate lines in the text file that pops up Well, I had already done a git reset --hard back to a point where there were no x86 patches applied since last pull anyway, so the rebase threw them all out I went back into patchwork and downloaded all the patches and git am'd them all. I was tempted to fix up a few that broke the build and had to be fixed with a little fixup patch but I decided that I had tempted fate enough already :) So it's all fixed - Thanks for your help However, I still get: error: refs/tags/2009.01-rc2 does not point to a valid object! Regards, Graeme
On Tuesday 29 November 2011 05:51:52 Graeme Russ wrote: > However, I still get: > > error: refs/tags/2009.01-rc2 does not point to a valid object! if `git tag -d 2009.01-rc2` doesn't fix things, then try: rm .git/refs/tags/2009.01-rc2 sed -i /tags.2009.01-rc2/d .git/packed-refs -mike
Hi Andy, Mike,
Thanks for all your help. I've managed to clean-up the x86 repo, but I
still have a few lingering thoughts if you can spare a few more moments...
I understand why a published (i.e. pushed onto the denx server) branch
should never be altered and should, therefore, never require a forced push.
But I can think of two (probably the same) problematic scenarios:
1) ${upstream}/master merges in multiple conflicting ${sub-repo}/master
and the order that they get pulled results in a conflict
2) ${sub-repo}/master has been published but not pulled before more
patches have been added to ${upstream}/master - If ${sub-repo}/master
does a fetch/pull of ${upstream}/master, there will be a conflict
Now ${upstream}/master is always the 'gold standard', so what does the
conflicted sub-repo dpo with the already published patches?
Mike, you were saying that you don't keep your ${sub-repo}/master sync'd
with ${upstream}/master - I understand how that works when nothing in
that you are responsible for ever changes in ${upstream}/master without
going through your ${sub-repo}/master, but what about when that is not the
case. For example, with some of the major architectural changes being made
to create more common code, how to you ensure the patches in your
${sub-repo}/master do not conflict?
I had a look at u-boot-blackfin and I noticed that there are non-blackfin
patches. u-boot-x86 also has the latest u-boot patches but there is no
merge commit in u-boot-x86 - So how do the u-boot patches get into
${sub-repo}/master without a merge?
Lastly, is there any real difference between a sub-repo and a branch? It
seems to me the principles of pull, merge, rebase etc are about the same
between the two.
Sorry if these questions are 'assumed knowledge' but I really don't want
to get x86 messed up again
Also, I know there are some good git tutorials out there (and I've read
a few) but I find it so much easier when referencing the U-Boot dev
cycle because a) it's what I'm working on and b) as an example, it seems
to be a good balance between 'fairly simple git workflow' and 'insanely
complicated git workflow'
Thanks and Regards,
Graeme
On Tuesday 29 November 2011 17:57:39 Graeme Russ wrote: > 1) ${upstream}/master merges in multiple conflicting ${sub-repo}/master > and the order that they get pulled results in a conflict when a merge is done and a conflict is thrown up, it's up to the guy doing the merge to resolve that conflict and commit the result. this is considered "normal" in the git workflow. just search the git log for "Conflicts:" to see this in action. > 2) ${sub-repo}/master has been published but not pulled before more > patches have been added to ${upstream}/master - If ${sub-repo}/master > does a fetch/pull of ${upstream}/master, there will be a conflict there will only be a conflict, if there's a conflict (i.e. two patches changing the same file in the same place). simply having different changesets in the repos is normal git workflow. this is why we have "merge commits" in the git log. these show up all the time when Wolfgang merges branches. > Now ${upstream}/master is always the 'gold standard', so what does the > conflicted sub-repo dpo with the already published patches? there are merge commits and sometimes conflicts in those merges. it depends on the conflict type as to what Wolfgang will do: tell you to rebase onto his master and thus it's your problem to resolve the conflict, or he'll fix it up locally. > Mike, you were saying that you don't keep your ${sub-repo}/master sync'd > with ${upstream}/master - I understand how that works when nothing in > that you are responsible for ever changes in ${upstream}/master without > going through your ${sub-repo}/master, but what about when that is not the > case. For example, with some of the major architectural changes being made > to create more common code, how to you ensure the patches in your > ${sub-repo}/master do not conflict? i keep them in a topic branch and ask Wolfgang to pull those, and i rewrite those branches since they're "development" ones most common example with my repo i think is the "sf" branch where i merge spi flash related changes > I had a look at u-boot-blackfin and I noticed that there are non-blackfin > patches. u-boot-x86 also has the latest u-boot patches but there is no > merge commit in u-boot-x86 - So how do the u-boot patches get into > ${sub-repo}/master without a merge? i pull Wolfgang's master, put my Blackfin patches on top, and then publish it and ask for a pull request. i don't pull newer updates from Wolfgang until he's merged my changes. or at least, i don't publish the updates. > Lastly, is there any real difference between a sub-repo and a branch? from git's pov, not really. a sub-repo is just to keep things more cleanly separated and to grants ACLs on a simpler basis. we could just as easily have all sub-repos be in Wolfgang's tree in namespaced branches: master x86/master blackfin/master arm/master arm/ti/master arm/tegra/master .......... but then things can get "noisy" as you see all the pushes/changes made by other people. *shrug*. -mike
Hi Mike, On Wed, Nov 30, 2011 at 10:35 AM, Mike Frysinger <vapier@gentoo.org> wrote: > On Tuesday 29 November 2011 17:57:39 Graeme Russ wrote: >> 1) ${upstream}/master merges in multiple conflicting ${sub-repo}/master >> and the order that they get pulled results in a conflict > > when a merge is done and a conflict is thrown up, it's up to the guy doing the > merge to resolve that conflict and commit the result. this is considered > "normal" in the git workflow. just search the git log for "Conflicts:" to see > this in action. > >> 2) ${sub-repo}/master has been published but not pulled before more >> patches have been added to ${upstream}/master - If ${sub-repo}/master >> does a fetch/pull of ${upstream}/master, there will be a conflict > > there will only be a conflict, if there's a conflict (i.e. two patches changing > the same file in the same place). simply having different changesets in the Ah yes, that's what I meant > repos is normal git workflow. this is why we have "merge commits" in the git > log. these show up all the time when Wolfgang merges branches. >> Now ${upstream}/master is always the 'gold standard', so what does the >> conflicted sub-repo dpo with the already published patches? > > there are merge commits and sometimes conflicts in those merges. it depends on > the conflict type as to what Wolfgang will do: tell you to rebase onto his > master and thus it's your problem to resolve the conflict, or he'll fix it up > locally. At this point, how do you make the merge 'conflict free' without re-writing the sub-repo? Or is this one of those rare occassions where you have to do what you have to do? >> Mike, you were saying that you don't keep your ${sub-repo}/master sync'd >> with ${upstream}/master - I understand how that works when nothing in >> that you are responsible for ever changes in ${upstream}/master without >> going through your ${sub-repo}/master, but what about when that is not the >> case. For example, with some of the major architectural changes being made >> to create more common code, how to you ensure the patches in your >> ${sub-repo}/master do not conflict? > > i keep them in a topic branch and ask Wolfgang to pull those, and i rewrite > those branches since they're "development" ones > > most common example with my repo i think is the "sf" branch where i merge spi > flash related changes > >> I had a look at u-boot-blackfin and I noticed that there are non-blackfin >> patches. u-boot-x86 also has the latest u-boot patches but there is no >> merge commit in u-boot-x86 - So how do the u-boot patches get into >> ${sub-repo}/master without a merge? > > i pull Wolfgang's master, put my Blackfin patches on top, and then publish it > and ask for a pull request. i don't pull newer updates from Wolfgang until > he's merged my changes. or at least, i don't publish the updates. So you pull u-boot/master straight into u-boot-blackfin/master? From what I gather, this is the same as fetch/merge. So if you merge branch 'A' into branch 'B' you get a merge commit, and if you then merge 'B' into 'A' there is no second merge commit because the merge is already done? >> Lastly, is there any real difference between a sub-repo and a branch? > > from git's pov, not really. a sub-repo is just to keep things more cleanly > separated and to grants ACLs on a simpler basis. we could just as easily have > all sub-repos be in Wolfgang's tree in namespaced branches: > master > x86/master > blackfin/master > arm/master > arm/ti/master > arm/tegra/master > .......... > > but then things can get "noisy" as you see all the pushes/changes made by > other people. *shrug*. I thought that was the case Regards, Graeme
On Tuesday 29 November 2011 18:48:08 Graeme Russ wrote: > On Wed, Nov 30, 2011 at 10:35 AM, Mike Frysinger wrote: > > On Tuesday 29 November 2011 17:57:39 Graeme Russ wrote: > >> Now ${upstream}/master is always the 'gold standard', so what does the > >> conflicted sub-repo dpo with the already published patches? > > > > there are merge commits and sometimes conflicts in those merges. it > > depends on the conflict type as to what Wolfgang will do: tell you to > > rebase onto his master and thus it's your problem to resolve the > > conflict, or he'll fix it up locally. > > At this point, how do you make the merge 'conflict free' without re-writing > the sub-repo? you can't. but the counter point is: why is this a problem ? if one patch is tweaking the style, but other is deleting the code block altogether, you get a conflict, but it's easy to resolve and commit the result. not the best example, but many conflicts are trivial to resolve. this is considered part of the git workflow as well -- people working in parallel on the same tree are bound to touch the same code. rather than rebasing, do a merge, get a conflict, and then fix the conflict and commit it as part of the merge commit. it's happened at least 65 times since we switched to git: $ git log | grep -c Conflicts: 65 > >> I had a look at u-boot-blackfin and I noticed that there are > >> non-blackfin patches. u-boot-x86 also has the latest u-boot patches but > >> there is no merge commit in u-boot-x86 - So how do the u-boot patches > >> get into ${sub-repo}/master without a merge? > > > > i pull Wolfgang's master, put my Blackfin patches on top, and then > > publish it and ask for a pull request. i don't pull newer updates from > > Wolfgang until he's merged my changes. or at least, i don't publish the > > updates. > > So you pull u-boot/master straight into u-boot-blackfin/master? From what > I gather, this is the same as fetch/merge. So if you merge branch 'A' into > branch 'B' you get a merge commit, and if you then merge 'B' into 'A' there > is no second merge commit because the merge is already done? correct. so when Wolfgang pulls my branch, he either fast forwards because he hasn't done any new work, or he gets a merge commit. in either case, when i pull his branch, mine is always a fast forward (since his tree has everything mine does already). -mike
Hi Mike, On Wed, Nov 30, 2011 at 2:52 PM, Mike Frysinger <vapier@gentoo.org> wrote: > On Tuesday 29 November 2011 18:48:08 Graeme Russ wrote: >> On Wed, Nov 30, 2011 at 10:35 AM, Mike Frysinger wrote: >> > On Tuesday 29 November 2011 17:57:39 Graeme Russ wrote: >> >> Now ${upstream}/master is always the 'gold standard', so what does the >> >> conflicted sub-repo dpo with the already published patches? >> > >> > there are merge commits and sometimes conflicts in those merges. it >> > depends on the conflict type as to what Wolfgang will do: tell you to >> > rebase onto his master and thus it's your problem to resolve the >> > conflict, or he'll fix it up locally. >> >> At this point, how do you make the merge 'conflict free' without re-writing >> the sub-repo? > > you can't. but the counter point is: why is this a problem ? if one patch is > tweaking the style, but other is deleting the code block altogether, you get a > conflict, but it's easy to resolve and commit the result. not the best > example, but many conflicts are trivial to resolve. this is considered part of > the git workflow as well -- people working in parallel on the same tree are > bound to touch the same code. rather than rebasing, do a merge, get a > conflict, and then fix the conflict and commit it as part of the merge commit. > > it's happened at least 65 times since we switched to git: > $ git log | grep -c Conflicts: > 65 Not that many, all things considered. I think one of the big positive side- effects of using a distributed SCM is that the more structure you apply to your code, grouping code components together in logical groups, the less likely you will get conflicts when two people work on two different features. And such a design facilitates maintaining multiple 'stable' branches and appliying the same bug fix across each branch - So a good distributed SCM actively promotes good software design and actively causes distress when you start hitting those 'less-than-perfect' parts of the code which encourages (forces) us to refactor and improve. > >> >> I had a look at u-boot-blackfin and I noticed that there are >> >> non-blackfin patches. u-boot-x86 also has the latest u-boot patches but >> >> there is no merge commit in u-boot-x86 - So how do the u-boot patches >> >> get into ${sub-repo}/master without a merge? >> > >> > i pull Wolfgang's master, put my Blackfin patches on top, and then >> > publish it and ask for a pull request. i don't pull newer updates from >> > Wolfgang until he's merged my changes. or at least, i don't publish the >> > updates. >> >> So you pull u-boot/master straight into u-boot-blackfin/master? From what >> I gather, this is the same as fetch/merge. So if you merge branch 'A' into >> branch 'B' you get a merge commit, and if you then merge 'B' into 'A' there >> is no second merge commit because the merge is already done? > > correct. so when Wolfgang pulls my branch, he either fast forwards because he > hasn't done any new work, or he gets a merge commit. in either case, when i > pull his branch, mine is always a fast forward (since his tree has everything > mine does already). OK, it sounds like I have it figured out now - I think I can say to anyone wanting a 'cutting edge' local x86 repo to pull u-boot/master and then fetch/merge u-boot-x86/master if they need x86 patches that have not yet been pulled. If they want 'bleeding edge' they can additionally fetch/merge u-boot-x86/next as well Thanks for taking the time to explain Regards, Graeme
On Tuesday 29 November 2011 23:12:02 Graeme Russ wrote: > On Wed, Nov 30, 2011 at 2:52 PM, Mike Frysinger wrote: > > On Tuesday 29 November 2011 18:48:08 Graeme Russ wrote: > >> At this point, how do you make the merge 'conflict free' without > >> re-writing the sub-repo? > > > > you can't. but the counter point is: why is this a problem ? if one > > patch is tweaking the style, but other is deleting the code block > > altogether, you get a conflict, but it's easy to resolve and commit the > > result. not the best example, but many conflicts are trivial to > > resolve. this is considered part of the git workflow as well -- people > > working in parallel on the same tree are bound to touch the same code. > > rather than rebasing, do a merge, get a conflict, and then fix the > > conflict and commit it as part of the merge commit. > > > > it's happened at least 65 times since we switched to git: > > $ git log | grep -c Conflicts: > > 65 > > Not that many, all things considered. I think one of the big positive side- > effects of using a distributed SCM is that the more structure you apply > to your code, grouping code components together in logical groups, the > less likely you will get conflicts when two people work on two different > features. And such a design facilitates maintaining multiple 'stable' > branches and appliying the same bug fix across each branch - So a good > distributed SCM actively promotes good software design and actively causes > distress when you start hitting those 'less-than-perfect' parts of the code > which encourages (forces) us to refactor and improve. right ... i think our current development style contributes to the low number of conflicts. we've got maintainers for specific subdirs, and cross commits are uncommon. add to that Wolfgang's normal route of applying patches from the ml with `git am`, so when a conflict occurs, he just tells the person to rebase/resubmit that one patch. but the ml gates the "downstream" aspect for the most part so that person's local rebase doesn't propagate. -mike
Hi All, I've asked Wolfgang the following, but it looks like he's just too snowed under at the moment... Somehow I've managed to do something 'interesting' to the u-boot-x86 repository - It has duplicate patches. He's the sequence of events leading up to the problem $ git fetch u-boot remote: Counting objects: 2330, done. remote: Compressing objects: 100% (483/483), done. remote: Total 1820 (delta 1383), reused 1735 (delta 1305) Receiving objects: 100% (1820/1820), 450.98 KiB | 32 KiB/s, done. Resolving deltas: 100% (1383/1383), completed with 390 local objects. From git://git.denx.de/u-boot 5721385..fdbe8b9 master -> u-boot/master $ git rebase u-boot/master First, rewinding head to replay your work on top of it... Applying: x86: Call hang() on unrecoverable exception Applying: cosmetic: checkpatch cleanup of arch/x86/cpu/*.c Applying: cosmetic: checkpatch cleanup of arch/x86/cpu/sc520/*.c Applying: cosmetic: checkpatch cleanup of arch/x86/lib/*.c Applying: cosmetic: checkpatch cleanup of board/eNET/*.c Applying: x86: Punt cold- and warm-boot flags Applying: sc520: Create arch asm-offsets Applying: x86: Add multiboot header Applying: x86: Provide more configuration granularity Applying: x86: Ensure IDT and GDT remain 16-byte aligned post relocation Applying: x86: Misc PCI touchups Applying: x86: Misc cleanups Applying: x86: Change printf to puts to avoid a buffer overflow Applying: x86: Fix how the location of the realmode and bios blobs are calculated Applying: x86: Don't relocate symbols which point to things that aren't relocated Applying: x86: Fix a few recently added bugs Applying: x86: Make the i8042 driver checkpatch clean Applying: x86: Fix some bugs in the i8402 driver when no controller is present Applying: x86: Import the glibc memset implementation Applying: x86: Wrap small helper functions from libgcc to avoid an ABI mismatch $ git push ssh://gu-x86@git.denx.de/u-boot-x86 error: refs/tags/2009.01-rc2 does not point to a valid object! To ssh://gu-x86@git.denx.de/u-boot-x86 ! [rejected] master -> master (non-fast-forward) error: failed to push some refs to 'ssh://gu-x86@git.denx.de/u-boot-x86' To prevent you from losing history, non-fast-forward updates were rejected Merge the remote changes (e.g. 'git pull') before pushing again. See the 'Note about fast-forwards' section of 'git push --help' for details. So I tried to pull... $ git pull git://git.denx.de/u-boot-x86 From git://git.denx.de/u-boot-x86 * branch HEAD -> FETCH_HEAD Auto-merging arch/x86/lib/Makefile CONFLICT (content): Merge conflict in arch/x86/lib/Makefile Auto-merging arch/x86/lib/board.c CONFLICT (content): Merge conflict in arch/x86/lib/board.c Automatic merge failed; fix conflicts and then commit the result. So I figured I'd just reset my local repo, pull in the denx version and start again $ git reset --hard 68d94e3f1476d26dd2512fd6c4c129865ba32fba $ git pull git://git.denx.de/u-boot-x86 From git://git.denx.de/u-boot-x86 * branch HEAD -> FETCH_HEAD Merge made by recursive. I then reapplied the patchwork patches and pushed but now I have two copies of every patch between the last merge and the new patches as per the following pull request: $ git request-pull u-boot/master git://git.denx.de/u-boot-x86.git master The following changes since commit fdbe8b9a2d1858ba35dd6214315563ad44d4a0e3: Merge branch 'hs@denx.de' of git://git.denx.de/u-boot-staging (2011-11-23 21:23:45 +0100) are available in the git repository at: git://git.denx.de/u-boot-x86.git master Gabe Black (11): x86: Change printf to puts to avoid a buffer overflow x86: Fix how the location of the realmode and bios blobs are calculated x86: Don't relocate symbols which point to things that aren't relocated x86: Change printf to puts to avoid a buffer overflow x86: Fix how the location of the realmode and bios blobs are calculated x86: Don't relocate symbols which point to things that aren't relocated x86: Fix a few recently added bugs x86: Make the i8042 driver checkpatch clean x86: Fix some bugs in the i8402 driver when no controller is present x86: Import the glibc memset implementation x86: Wrap small helper functions from libgcc to avoid an ABI mismatch Graeme Russ (25): x86: Call hang() on unrecoverable exception cosmetic: checkpatch cleanup of arch/x86/cpu/*.c cosmetic: checkpatch cleanup of arch/x86/cpu/sc520/*.c cosmetic: checkpatch cleanup of arch/x86/lib/*.c cosmetic: checkpatch cleanup of board/eNET/*.c x86: Punt cold- and warm-boot flags sc520: Create arch asm-offsets x86: Add multiboot header x86: Provide more configuration granularity x86: Ensure IDT and GDT remain 16-byte aligned post relocation x86: Misc PCI touchups x86: Misc cleanups x86: Call hang() on unrecoverable exception cosmetic: checkpatch cleanup of arch/x86/cpu/*.c cosmetic: checkpatch cleanup of arch/x86/cpu/sc520/*.c cosmetic: checkpatch cleanup of arch/x86/lib/*.c cosmetic: checkpatch cleanup of board/eNET/*.c x86: Punt cold- and warm-boot flags sc520: Create arch asm-offsets x86: Add multiboot header x86: Provide more configuration granularity x86: Ensure IDT and GDT remain 16-byte aligned post relocation x86: Misc PCI touchups x86: Misc cleanups Merge git://git.denx.de/u-boot-x86 The 'error: refs/tags/2009.01-rc2 does not point to a valid object!' issue has been posted about before, and I did issue the git commands to purge this tag back then but it has not appeared to have stuck and now I can't find the email with the git command This should have been a trivial push - All the changes are restricted to arch/x86 or board/eNET except for the i8042 patch. There have been no other edits to any of these files by anyone else so there should never have been any conflicts. I've seen 'non-fast-forward updates were rejected' before but I really don't undetstand what the problem is - The only thing I can think of is that stg (stacked git) may be the cause. I think once this is sorted I'll setup my local copy of the denx u-boot-x86 repo completely independent of my development repo. This has the added benifit that since I 'git am' from patches downloaded from patchwork anyway, it make it impossible for rogue patches to sneak in. But in the meantime, how can I safely fix the denx u-boot-x86 repo so I can safely send a pull request? I'm thinking: > git reset -hard 5721385b187b3154c7768e6c182501022f4e2e45 > git push -f ssh://gu-x86@git.denx.de/u-boot-x86 > git fetch u-boot > git rebase u-boot/master > git push ssh://gu-x86@git.denx.de/u-boot-x86 > git am <all of the outstanding x86 patches> > git push ssh://gu-x86@git.denx.de/u-boot-x86 Note: 5721385b187b3154c7768e6c182501022f4e2e45 is the parent of the first duplicate patch "x86: Call hang() on unrecoverable exception" Thoughts? Regards, Graeme