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

[Graeme Russ]

Hi Mike,

On Wed, Nov 30, 2011 at 10:35 AM, Mike Frysinger <vapier at 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