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

[Graeme Russ]

Hi Mike,

On Wed, Nov 30, 2011 at 2:52 PM, Mike Frysinger <vapier at 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