[U-Boot] Attn Maintainers: git advise needed (how to fix messed up repo)

[Graeme Russ]

Hi Mike,

On Tue, Nov 29, 2011 at 3:01 PM, Mike Frysinger <vapier at 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