Hi Mike,
On Wed, Nov 30, 2011 at 10:35 AM, Mike Frysinger <vap...@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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
