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

Mike Frysinger vapier at gentoo.org
Wed Nov 30 17:41:02 CET 2011


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20111130/9f560f21/attachment.pgp>


More information about the U-Boot mailing list